1. 11
  1. 4

    It is a good guide. I do have some suggestions:

    I fully agree with what @ane says about line-numbers. Line numbers are for machines not humans. In every editor I know you can jump to the path+line number in one mouse key or keystroke (in vim it is gf f/e).

    Besides that, adding /usr/local/bin/ to the exec-path in your Emacs’ init file is a half measure. A better, more comprehensive solution would be to add it to the system-wide $PATHS by adding it to /etc/paths.d/.

    Finally rainbow delimiters is not worth it. I used it for some years and it look nice, but besides highlighting the matching matching paren, which the built-in show-paren-mode already does, coloring each paren differently only adds noise.

    1. 2

      A better, more comprehensive solution would be to add it to the system-wide $PATHS by adding it to /etc/paths.d/

      Doesn’t that not work inside Emacs anyway? IIRC, you need to jump through an extra hoop to make Emacs use the environment PATH.

      1. 2

        IIRC, you need to jump through an extra hoop to make Emacs use the environment PATH.

        You don’t need to jump through any extra hoops. Emacs is a normal process.

        The issue people often run in Mac OS is the following. The place where developers tend to modify their path is in ~/.bashrc or ~/.profile. The problem with that those files are only run when you open a terminal. So everything works ok when you are running programs inside the terminal, including emacs (You can for example start the GUI version of Emacs from the terminal on the background $ emacs & and it will pick up your augmented $PATH).

        However when you start a program from spotlight, finder or the dock bar your path won’t be augmented by any code you wrote in ~/.bashrc/~/.profile. This is not specific to emacs. By adding the path to /etc/paths.d all the programs in your system will have /usr/local/bin in their $PATH.

        1. 2

          @ragnese is right. Adding /usr/local/bin to /etc/paths.d does not help Emacs to locate SBCL. In fact, /usr/local/bin is already in /etc/paths of macOS anyway, so adding it again to /etc/paths.d is redundant. Despite /usr/local/bin being present in both /etc/path and /etc/paths.d, Emacs exec-path still does not contain /usr/local/bin.

          1. 1

            I haven’t used Mac OS for a couple of years, but that I’ve never had to add anything into the exec-path. Especially when it is already in $PATH. /usr/loca/bin/ was not in /etc/paths when I did.

            Emacs exec-path still does not contain /usr/local/bin.

            Given that the default value from exec-path is initialized from $PATH I would find this surprising. Just to double check, If you run M-: (getenv "PATH") you see /usr/local/bin there?

    2. 3

      I think this guide is otherwise good, but I think it should start at the package-initialize section, anything else before that are just matters of taste and are tangential to the point of the guide, i.e. configuring a Common Lisp editing environment. Not to mention it refers the user to enable displaying line numbers, which is an Emacs anti-pattern.

      I bet people are going to ask why it is an anti-pattern, so here goes. Disclaimer: I know many people are used to have line numbers visible in other editors, and such a preference is usually deeply personal, so I’m trying my best to not sound patronizing here.

      In Emacs, you usually shouldn’t need to navigate by line number, because Emacs should be able to take you to those places automatically. For instance, compilation errors, Emacs has the built-in compile-mode which will automatically create a global keybinding to next-error (which would be M-g g), and that takes you directly to the offending line. Similarly, if you’re used to jumping to a function you see at a point before the position of the cursor, you should use functions like beginning-of-defun (bound to C-M-a). See the relevant section in the GNU Emacs FAQ.

      Besides, line numbers can occupy significant horizontal space. So by not using them, you gain lots of needed horizontal space, and can keep more buffers open side-by-side.

      1. 1

        Plus, at least last time I used them, line numbers slow Emacs down significantly. That’s what made me originally stop using them and before long I didn’t miss them at all.

        1. 1

          Sorry, the keybinding for next-error is actually M-g M-n. M-g g is goto-line.

        2. 3

          Never warmed up to paredit. The ordinary Lisp mode structured commands are useful enough, and sometimes it’s easier to edit things “unstructured”.

          1. 2

            This really isn’t minimal, a lot of these aren’t related to CL, and it’s a little silly, IMO, to imply personal preferences like themes and disabling scrollbars have anything to do with CL development.

            Minimal Slime setup would be something like:

            (add-to-list 'load-path "~/src/lisp/slime/")
            (load "slime-autoloads")
            (setq inferior-lisp-program "/usr/local/bin/sbcl --noinform")
            

            Or, if Slime is installed via the package manager, it might even just be:

            (setq inferior-lisp-program "/usr/local/bin/sbcl --noinform")
            

            Don’t get me wrong, it’s a nice setup, but it shouldn’t misrepresent what it is - the author’s preferred config.

            1. 4

              Removed “minimal” from the heading because you are right that this really isn’t minimal. Thanks for the feedback.

            2. 2

              A minimal set-up would be to install Portacle

              1. 1

                do you have any idea for how i can set up a portable portacle-like setup but on my own? for the life of me i can’t find where the configs all are.

                1. 2

                  I am afraid not, though Portacle is entirely open source, so you should be able to find the information somewhere on GitHub.

                  1. 1

                    I’ll keep digging, thanks :)