?!? Wtf does this mean and how did vi come up

Everything mostly worked out of the box.

> It's roughly equivalent to trying to discover all of our scientific knowledge yourself from scratch vs taking "for granted" the knowledge discovered by your forebears.

The author do have another config with all the bells and whistles. But Emacs does come with a lot of packages and tweaking them isn't that much work compared to building a full suite like Helm, especially with the awesome documentation system. Getting a v0.x of anything can be a matter of minutes. And then you wake up one day and you've built a whole OS for your workflows.

I don't think the post implied that this package writing activity was a write-only activity where reading and learning is strictly forbidden.

> You can find open source licensed packages, read them to understand them, and then copy them into your config. Doing everything from scratch is a waste of time unless you enjoy the process (in which case go nuts).

The post clearly indicates the relatively large set of open source packages they looked at and understood before doing their own packages. The author graciously acknowledges them and their influence on the work:

"Emacs Solo doesn't install external packages, it is deeply influenced by them. diff-hl, ace-window, olivetti, doom-modeline, exec-path-from-shell, eldoc-box, rainbow-delimiters, sudo-edit, and many others showed me what was possible and set the bar for what a good Emacs experience looks like. Where specific credit is due, it's noted in the source code itself."

I think of it more like building stuff out of Lego without following any instructions.

It seems pretty clear that the "why" is "because it's there"

You can think of Emacs as a kind of software Lisp machine with an emphasis on editing. Although that analogy only works well if you squint or if you don't know a lot about Lisp machines.

As someone who first learned Lisp through Emacs Lisp, I found it fun, well-documented, and powerful. Once you grok the basics of how the system is dynamically glued together, infinitely hackable, and self-documenting it's kind of mind-blowing.

purely for text editing? No. But that's not what distinguishes Emacs, it's famously very mediocre at it. The point of Emacs is to be a fully transparent, inspectable, dynamic and changeable environment. In spirit similar to Smalltalk systems like Pharo. And for that a Lisp is not the only choice but a very good one.

There's very few languages and environments that facilitate jumping into any place, making a change, compiling or evaluating a block of code or treating it as data and continuing seamlessly.

Still, the reason for choosing a language for whatever are always more social and path-dependent than technical (reason 1: initial developer of whatever really likes the language, reason 2: language is seen as hip within some crowd, reason 3 (later in the game): management feels language is safe). Technical reasons for choosing a language typically tend to be post-hoc rationalizations. (I mean, no sane person would choose Javascript for an editor based on technical reasons alone, yet here we are.)

[0] https://lem-project.github.io/ [1] https://www.lispworks.com/products/lispworks.html

BTW emacs is written in C.

Yes, they are pretty good. I have set up GPTel (an excellent Emacs package for interacting with LLMs) with some tools allowing it to run Elisp, inspect files (Elisp functions know what file they were defined in, so it's easy to find stuff) and read Emacs documentation. LLMs use this to good effect, and iterate on my config very nicely.

What was the Apple Dev account needed for? Previously I remember it was only needed for submitting apps to the App Store, not running Dev builds locally.

I don't think this is really possible. The thing that makes it special is that there are key binds for all the 100s of things you could want to do. So it becomes sort of like playing a instrument where you use your muscle memory instead of thinking specifically about the keys. If you make a bunch of menus and buttons to do the things it would be a mess and probably not very nice to use. Emacs actually has buttons and GUI controls for lots of the functionality, but it kind of sucks to use it that way.

These setups are impressive specifically because the creator has put in the time and effort to become an expert at using their editor. There is just no way to hand that over to someone else as-is without any investment from the recipient in skill development.

You do have that somewhat with packages like which-key that will show you a menu of options every time you press a key. You then learn the keybinds that you use the most. You can also search for them by name and see the keybind like you do with VS Code etc..

Here's what doom-emacs looks like when I press space and then space-t:

https://files.catbox.moe/szfcif.png

https://files.catbox.moe/2kgrai.png

Sadly, "these days" is a low bar. The days of consistent platform-specific "Human Interface Guidelines" are over, it's all just a browser wrapped in a top-level window or something that simulates that, with most interaction patterns being a cargo cult of how it's remembered from the 90s. So "GUI" means that some unique overlays can be drawn without a fixed width character grid and that you might get the original file requester now and then.

When opening a freshly installed emacs, there should be a "Emacs Tutorial" link that can be clicked; also the keyboard shortcut `C-h t` (which is «Control + `h`, then `t`»).

There is a similar feature in `neovim`, when opened type `:Tutor` (which is «`:` to open the command prompt, with command `Tutor`»).

    (setq backup-directory-alist '(("." . ".~")))

First thing I do any time I install emacs.

Note that tramp will kvetch if you do this, but it still works fine.

Without this I had to be careful not to acciddentally commit stuff like ".#filename.txt".

  ;; Makes any xref buffer "exportable" to a grep buffer with "E" so you can edit it with "e".
    (defun emacs-solo/xref-to-grep-compilation ()
      "Export the current Xref results to a grep-like buffer (Emacs 30+)."
      (interactive)
      (unless (derived-mode-p 'xref--xref-buffer-mode)
        (user-error "Not in an Xref buffer"))

      (let* ((items (and (boundp 'xref--fetcher)
                         (funcall xref--fetcher)))
             (buf-name "*xref→grep*")
             (grep-buf (get-buffer-create buf-name)))
        (unless items
          (user-error "No xref items found"))

        (with-current-buffer grep-buf
          (let ((inhibit-read-only t))
            (erase-buffer)
            (insert (format "-*- mode: grep; default-directory: %S -*-\n\n"
                            default-directory))
            (dolist (item items)
              (let* ((loc (xref-item-location item))
                     (file (xref-file-location-file loc))
                     (line (xref-file-location-line loc))
                     (summary (xref-item-summary item)))
                (insert (format "%s:%d:%s\n" file line summary)))))
          (grep-mode))
        (pop-to-buffer grep-buf)))
    (with-eval-after-load 'xref
      (define-key xref--xref-buffer-mode-map (kbd "E")
                  #'emacs-solo/xref-to-grep-compilation))