jonpalmisc

Any chance you can share that Ruby script? (It can be just the script if the source isn’t shareable.) I’ve wanted to explore something like this for a while and having a reference would be nice.

HN crowd might have some interesting takes on this: what is your preferred archive (and/or compression) format, and why?

I’ve been using .tar.xz for archiving, but haven’t looked into what the “best” option really is.

Another vouch for Eglot here. Seems smoother and just nicer overall compared to lsp-mode, not to mention better integration with Emacs. I switched to Eglot a while back and haven’t looked back.

I used it avidly for years. It’s still fun to see pretty LaTeX documents, but my patience for working with it—despite being rather fluent with it—has grown too slim.

I also have a love & hate relationship with LaTeX. I think it really boils down to the following:

LaTeX will work excellently for you, so long as your use case was envisioned by the original authors.

I can't say that the original authors of LaTeX didn't envision using it for creating slideshows/presentations, but I can say that making a beamer theme is uniquely complicated. I wish that LaTeX had something as flexible as CSS for styling documents rather than the awkward commands, etc. used now—so much so that I attempted to replace LaTeX with a HTML & CSS -> PDF workflow in the past [0]. It is still an idea I want to revisit someday when I have more time.

[0] https://github.com/jonpalmisc/pmt (no longer actively maintained)

I’d like to see something like this but for speeding up Emacs at runtime. I have a 0.25s startup time with packages but my Emacs struggles when using lsp-mode or eglot in large C++ projects. I’ve been using Sublime Text lately but would like to get back to Emacs.

Probably going to catch hate for this, but the Python package/environment management debacle is one of the things that causes me to avoid the language in my own personal projects.

All of the following are real tools for Python package/environment management: virtualenv; pipenv; venv; pyenv; poetry; pyenv-virtualenv; and pip-tools. There are probably more. Which one is "best" varies by who you ask and with time. If you do a bunch of Python work, you'll probably need most of them installed since different projects use different tools.

The messiness of the whole situation just takes the fun out of it for me. I don't hate Python, but when I code in my free time, I'd simply prefer to use a language that doesn't have those problems.

In general, variable fonts work by defining multiple "masters" that can be interpolated between. While I'm not sure if Glyphs was used to create this font in particular, this page from Glyphs' documentation summarizes how the process works:

https://glyphsapp.com/learn/creating-a-variable-font

If you are unfamiliar with font technology/design, it is hard to emphasize just how much work must have went into producing this font. Take a look at all the different variable axes Roboto Flex supports [1]. I have never seen so many axes in a variable font.

I cannot imagine how much effort went into developing and testing this font; this is incredible work by Font Bureau.

[1] https://fonts.google.com/specimen/Roboto+Flex?query=roboto#t...

Do you have any examples of the “perfectly safe code the Rust compiler will nag you about”? Not trying to start language wars, just genuinely curious as someone who writes Rust on occasion.

If this stuff (typography, punctuation, etc.) interests you, definitely check out Butterick’s Practical Typography [1]. Great resource and easy to follow.

[1] https://practicaltypography.com/

Surprised to see this is the second result when googling “cdecl” despite its naming collision with the calling convention.

There are others who would know more about this than I do, but a few reasons come to mind:

1. NSO almost certainly has more than one exploit chain at a time. While this would burn one of their exploits, it wouldn’t put them out of business or eliminate the ability for them to get RCE on phones in general.

2. Vendors already have bug bounty programs with established award ceilings. These exploits are almost always far more valuable than the vendor is willing to pay via their bug bounty program. Why would the vendor pay more in this instance?

3. Given (1), how long would this go on for? NSO—who is aware of how many exploit chains they have—likely wouldn’t sell all of their exploits to a single buyer and risk them all getting burned.

TL;DR: It wouldn’t be practical.

Can’t speak about the others, but Rust’s C interop is nothing like Zig’s, not to mention that Zig can also compile C.

I think Zig’s compatibility with C is such a valuable feature.

I also wish we could rewrite everything in a modern language, but the reality is that we can’t and that if we could, it would take a LONG time. The ability to start new projects, or extend existing ones, with a modern and more ergonomic language—Zig—and be able to seamlessly work with C is incredible.

I look forward to the self-hosted compiler being complete, and hopefully a package manager in the future. I’d really like to start using Zig for more projects.

I haven't heard of S7 before—it looks like a great project as well. Thanks!

3 days ago.

https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...

Thanks for sharing this, I've bookmarked it to check out more later, but from the links you provided, it looks like Chicken Scheme is pretty friendly to use.

It’s pretty minimal right now as I’m in the process of porting over a larger config. Here’s what I have, although you might find it might be a bit underwhelming:

https://github.com/jonpalmisc/dotfiles/blob/master/hammerspo...

Fennel is really cool, and the fact that it builds on Lua—an already-popular language—is a huge win; Fennel gets access to the entire Lua ecosystem.

Importantly, Lua is pretty easy to embed in native applications. I haven’t found a Lisp or Scheme as easily-embeddable as Lua(+Fennel).

It’s also a good drop-in replacement for Lua. I write my Hammerspoon config in Fennel, and hopefully my Neovim config soon as well.

Likely controversial opinion: Parser combinators are fun but feel a little too magic for me.

Maybe I’m being stubborn, but I prefer to write lexers and parsers by hand. Although, I would like to get around to writing a “common lexer and parser utility library” one day to abstract away some common patterns while simultaneously not forcing design decisions. Perhaps I’ll end up with a parser combinator library by the time I’m done and I’ll have to eat my words.

It’s easy to argue that all cross platform C++ GUI libraries suck, but Qt definitely sucks the least.

Yes, sometimes it can be awkward to use, and yes, there are longstanding bugs in Qt itself that remain unfixed. In my opinion, it is still the best C++ GUI library out there. For basic to intermediate GUI apps, it just works, and for advanced use cases, with some effort you can make it do whatever you need.

I write Qt software now and I’d be happy to keep doing so.

Clang, swiftc, etc. would like a word with you... :)

(It bothers me too.)

The cohesion and interoperability of Emacs packages is hard to find elsewhere. When I tried Neovim recently, it was blatantly obvious and I was quickly turned off by how each plugin creates psuedo-TUI elements and prompts for input slightly differently.

I use it at my current job in which I work in a large C++ codebase. I formerly used CLion.

Whether Emacs is an IDE or not depends how you define IDE. I use Eglot [0] for LSP integration; this gives me IDE-like features like "jump-to-definition", syntax error highlights, warnings, etc. and integrates with company-mode [1] for code completion. This handles most of my needs for writing code.

As for other things like a file tree, I've found that the built in `project-find-file` command combined with `vertico` [2] and `orderless` [3] makes finding files and navigating around projects easier; that pair behaves similarly to CMD+P in Sublime Text or VS Code. There are file tree packages out there, but I've found that I don't really need a file tree in practice and that I prefer navigating around projects with fuzzy file search and grep.

[0] https://github.com/joaotavora/eglot [1] https://github.com/company-mode/company-mode [2] https://github.com/minad/vertico [3] https://github.com/oantolin/orderless

One of the best parts is the bindings! They are present in most shells/terminals, GNU readline-based programs, and even native macOS text field. If you're in a terminal or using a terminal-based program, there's a good chance pressing any of the core Emacs keybindings does what you expect it to.

You might want to check out straight.el [0] in replacement of package.el; it can pin package versions, etc. It is used by the very popular Doom Emacs [1] to lock package versions for reproducible config reasons.

[0] https://github.com/raxod502/straight.el [1] https://github.com/hlissner/doom-emacs

I like to tinker and hack on things, so I enjoy maintaining my Emacs config to an extent.

However, I draw the line at "text editor" with Emacs. I have no desire to read my email, paint pictures, or compose music inside Emacs—there are better tools for that.

What parts did you find difficult?

When I first started, I found the keybindings odd, but now I love them since the core set of shortcuts—C-a, C-e, C-f, etc.—work "everywhere" from the terminal, to GNU readline-based programs, to even native macOS text boxes. If you don't like the default keybindings, you can change them or use the Evil package [0] for Vim bindings.

If you want to get up and running quickly, I'd check out Doom Emacs [1] which is easier to configure and takes care of a lot of configuration for you. I personally use a reasonably-minimal config I wrote myself [2]. If you like to tinker, I'd recommend writing your own config, as it will also teach you a lot about Emacs.

If you have any questions feel free to reach out—contact info in my profile.

[0] https://github.com/emacs-evil/evil [1] https://github.com/hlissner/doom-emacs [2] https://github.com/jonpalmisc/.emacs.d/blob/master/init.el

I almost wish I never tried Emacs. Ignorance is bliss, and Emacs ruined all other text editors for me.

There are absolutely areas that others do better, but the self-documenting “living program” nature is too much to give up; everything you ever need to know or do is a few keystrokes away.