Andrey Listopadov

Limiting Horizontal Scroll In Emacs

Wed, 20 Jul 2022 00:00:00 +0000

I use Emacs mainly for programming, but I also write a lot of non-code in it, either for this blog, documentation for my projects, or just when I take notes. And I do it with a git-friendly style of formatting with a single sentence per line. And because of that, I enable line truncation, to avoid wrapping text, because when the text is written this way, the wrapped version looks like a mess, in my opinion. This also helps with code, that has long lines - the formatting is preserved and unexpected multi-line expressions don’t mess me up.

But because lines get truncated when exceeding window width, it means that I have to use horizontal scrolling. I rarely actually use scrolling, because this is a very good indication of a very long sentence, that should be rephrased into smaller ones, but still. However, when I do have to scroll, there’s a problem - Emacs doesn’t limit horizontal scrolling properly.

If you open some other editor, like Gedit, and disable line wrapping, you’ll see that the most amount of horizontal scrolling you can get is basically such that the last character of the longest line is at the right border of the window. In Emacs, however, it’s not limited like that, and you can scroll past the last character of the longest line, and basically overshoot. This can be handy when you want to have some empty space to the right, for comfortable writing, but I don’t need that. Instead, I would like to get the behavior of editors like Gedit.

Turns out, if you enable horizontal-scroll-bar-mode, Emacs will show the scroll-bar at the bottom, which will not allow you to over-scroll text, like in Gedit. But if you use a touchpad, or manually call scroll-left it will continue scrolling. So let’s fix this.

The first thing we’ll need is a custom predicate, that will check if any line in the buffer exceeds buffer width. There are some corner cases to be aware of, like if the buffer’s font size is changed via text-scale-adjust, or if the line numbers are displayed, so this predicate should account for that too. I wrote such predicate like this:

(defun truncated-lines-p ()
  "Non-nil if any line is longer than `window-width' + `window-hscroll'.

Returns t if any line exceeds the right border of the window.
Used for stopping scroll from going beyond the longest line.
Based on `so-long-detected-long-line-p'."
  (save-excursion
    (goto-char (point-min))
    (let* ((window-width
            ;; This computes a more accurate width rather than `window-width', and
            ;; respects `text-scale-mode' font width.
            (/ (window-body-width nil t) (window-font-width)))
           (hscroll-offset
            ;; `window-hscroll' returns columns that are not affected by
            ;; `text-scale-mode'.  Because of that, we have to recompute the correct
            ;; `window-hscroll' by multiplying it with a non-scaled value and
            ;; dividing it with a scaled width value, rounding it to the upper
            ;; boundary.  Since there's no way to get unscaled value, we have to get
            ;; a width of a face that is not scaled by `text-scale-mode', such as
            ;; `window-divider' face.
            (ceiling (/ (* (window-hscroll) (window-font-width nil 'window-divider))
                        (float (window-font-width)))))
           (line-number-width
            ;; Compensate for line number width.  Add support for
            ;; other modes if you use any, like `linum-mode'.
            (if (bound-and-true-p display-line-numbers-mode)
                (- display-line-numbers-width)
              0))
           (threshold (+ window-width hscroll-offset line-number-width
                         -2))) ; -2 to compensate rounding during calculation
      (catch 'excessive
        (while (not (eobp))
          (let ((start (point)))
            (save-restriction
              (narrow-to-region start (min (+ start 1 threshold)
                                           (point-max)))
              (forward-line 1))
            (unless (or (bolp)
                        (and (eobp) (<= (- (point) start)
                                        threshold)))
              (throw 'excessive t))))))))

To illustrate what it does, here’s a screenshot of the Emacs window with this blog post, as I edit it:

I’ve made the frame smaller and enabled the horizontal-scroll-bar-mode to better show what I mean. In the echo area t is displayed because I’ve called truncated-lines-p, and it shows that some line exceeds the width of the window. You can see that lines go beyond the right border (though there’s no arrow in the fringe, as I disabled these), and if I scroll with the scroll-bar, Emacs stops scrolling at about this position:

Now nil is displayed in the echo area because I’ve called truncated-lines-p again, which means that the predicate works, since there’s no need to scroll anymore, all lines are not truncated by the right border. However, I can continue scrolling if I use the touchpad:

Note, that the handle in the scroll bar changed its width. Emacs calculates the width of the handle based on the longest line currently visible in the window, meaning that it will change depending on the position in the buffer. And perhaps scroll-bar width limited for what you’re seeing is a performance optimization. My function does it for the whole buffer, and there is a lot of code for calculating text width with respect to the horizontal scroll. Thus, the calculation process may not seem very optimal, but benchmarking this function seems to have decent performance on my 1603 lines init.el file:

;; some lines exceed the width
(benchmark 1000 '(truncated-lines-p)) ; Elapsed time: 0.597171s
;; no lines exceed the width
(benchmark 1000 '(truncated-lines-p)) ; Elapsed time: 1.247346s

In practice, I never feel any slowdown from it. The only thing left is to make sroll-left to actually use it:

(define-advice scroll-left (:before-while (&rest _) prevent-overscroll)
  (and truncate-lines
       (not (memq major-mode '(vterm-mode term-mode)))
       (truncated-lines-p)))

I use a before-while advice, which acts like a predicate on its own and doesn’t run function if the result is nil. As can be seen, it does an additional check for truncate-lines to be on, since if lines are not truncated there’s no reason to ever scroll left. I also would like to prevent this from working in certain major modes, like terminals, since these automatically wrap lines themselves.

Hope this is useful for someone, and if anybody knows a more robust way to calculate text width with the respect to the zoom level feel free to suggest improvements.

Comment via email

Project.el enhancements

Sat, 16 Jul 2022 12:37:00 +0300

After publishing the last post I thought why won’t I post such things here occasionally? I have a few pieces of Emacs Lisp in my configuration that I wrote for myself some time ago to fix some annoyances or improve a certain workflow. Previously I’ve used a literate approach for my Emacs configuration which listed all these notes, but it was tedious to maintain, so I’ve opted out for a simpler init.el. But I still would like to share some pieces in a more elaborated form. Moreover, I’ve already done it before, and now, since I don’t use these packages, it’s easier to find these in a more organized place, than search in the commit history.

One such thing that I’d like to share is a configuration of the inbuilt project.el, which makes it a bit more pleasant to work with.

Finding project root based on specific root-markers

Long ago I added a function that searches for a project root a bit differently from how project.el does it by default. It does so by searching for specific files, that I’ve specified like this:

(defcustom project-root-markers
  '("Cargo.toml" "compile_commands.json" "compile_flags.txt"
    "project.clj" ".git" "deps.edn" "shadow-cljs.edn")
  "Files or directories that indicate the root of a project."
  :type '(repeat string)
  :group 'project)

You may wonder why I’ve included .git as a project marker, but I often work with submodules, and I want such submodules to be treated as separate projects. The default project-try-vc treats submodules as part of a bigger project, which is logical, I guess, but I want it to act a bit differently. And since not all of my submodules have one of the specified markers, it’s easy to search for the git directory and be done with it.

Next, we need a function that checks if a given path has any of these markers:

(defun project-root-p (path)
  "Check if the current PATH has any of the project root markers."
  (catch 'found
    (dolist (marker project-root-markers)
      (when (file-exists-p (concat path marker))
        (throw 'found marker)))))

Nothing fancy, just a linear search for any of the markers under the current directory. The search terminates as soon as one of the files is found.

The main piece here is the project-find-root function:

(defun project-find-root (path)
  "Search up the PATH for `project-root-markers'."
  (let ((path (expand-file-name path)))
    (catch 'found
      (while (not (equal "/" path))
        (if (not (project-root-p path))
            (setq path (file-name-directory (directory-file-name path)))
          (throw 'found (cons 'transient path)))))))
(add-to-list 'project-find-functions #'project-find-root)

As can be seen, this function is added to the list of project-find-functions, and all it does is simply look for a marker file in the current directory, and if it is not found it goes up the directory. If file is found, it returns a (transient . "path/to/root") that project.el expects. In practice, with this function early enough in the list, project-try-vc is never called, and I get very predictable project roots.

Update:

A suggestion came from another Emacs user, that there’s a function that can search up from the current directory, called locate-dominating-file. It accepts a path as its first argument, and a file to search for as a second argument. It may not seem useful in this use case, since we need to search for multiple files, but instead of a file, this function also can accept a predicate, that will tell if a given file exists. Thus, the project-find-root function can be rewritten as:
(defun project-find-root (path)
  "Search up the PATH for `project-root-markers'."
  (when-let ((root (locate-dominating-file path #'project-root-p)))
    (cons 'transient (expand-file-name root))))
This is why I love Emacs! It has a lot of functions ready to be used, and a passionate community, that suggests improvements and makes the experience even better.

Saving only project buffers before compilation

I often use project’s commands, defined under the project-prefix-map. One of these is project-compile, which I use for all sorts of things, from running tests to deploying. However, it has an annoying habit to ask whether I want to save some buffers before I run any command. Why yes, I want to save some buffers, but only if they belong to the current project! So let’s fix this:

(defun project-save-some-buffers (&optional arg)
  "Save some modified file-visiting buffers in the current project.

Optional argument ARG (interactively, prefix argument) non-nil
means save all with no questions."
  (interactive "P")
  (let* ((project-buffers (project-buffers (project-current)))
         (pred (lambda () (memq (current-buffer) project-buffers))))
    (funcall-interactively #'save-some-buffers arg pred)))

Just a simple function that obtains the current project, queries all project buffers, and creates a custom predicate for the save-some-buffers function. I’m not sure why project.el doesn’t do it by itself, but we can always advise things:

(define-advice project-compile (:around (fn) save-project-buffers)
  "Only ask to save project-related buffers."
  (let* ((project-buffers (project-buffers (project-current)))
         (compilation-save-buffers-predicate
          (lambda () (memq (current-buffer) project-buffers))))
    (funcall fn)))

This fixes only half of the problem, however.

Imagine, you’re running tests by calling project-compile and one of the tests fails. You look in the *compilation* buffer why it failed and fix it. Then you go to the *compilation* buffer once again and hit the g key to re-run tests. But instead of running tests, you’re being asked if you want to save some buffers, even though you’ve saved all buffers in the project beforehand. Turns out, that g simply calls the recompile function, which knows nothing about the project, and will prompt you to save buffers, that aren’t in the project and are unsaved. This, once again, can be fixed with a piece of advice:

(define-advice recompile (:around (fn &optional edit-command) save-project-buffers)
  "Only ask to save project-related buffers if inside a project."
  (if (project-current)
      (let* ((project-buffers (project-buffers (project-current)))
             (compilation-save-buffers-predicate
              (lambda () (memq (current-buffer) project-buffers))))
        (funcall fn edit-command))
    (funcall fn edit-command)))

We simply check if current *compilation* buffer is a part of a project, since and do the same trick, setting compilation-save-buffers-predicate to our custom predicate that is aware of the project. This, however, works best when you customize the project-compilation-buffer-name-function to use project-prefixed-buffer-name, so you can compile multiple projects, and it won’t be confusing when to save what buffers.

Comment via email

Automatic refreshing of package archives for Emacs

Fri, 15 Jul 2022 09:27:00 +0300

I was going through my git commit history in my public dotfiles repository and noticed that prior to using straight.el I’ve, like many, used an inbuilt solution for managing packages, called package.el. However, there was one thing that bothered me, and one of the reasons that made me think about switching to straight was the fact, that a lot of times when I wanted to update or install packages, I couldn’t, due to an outdated package cache. So I’ve fixed this, but since I’ve moved to straight I no longer needed this piece of code, and hence I’ve deleted it. But it might be useful for people who use package.el, so I’ve decided to share it here.

The first thing needed is a custom variable to store the last refresh date. I’ve chosen Custom because it is persisted on disk, which allows me to use customize-save-variable later to make the value persist across sessions, and be easily reset via the customization interface:

(defcustom package-last-refresh-date nil
  "Date and time when package lists have been refreshed.

  This variable is then used to check whether
  `package-refresh-contents' call is needed before calling
  `package-install'. The value of this variable is updated when
  `package-refresh-contents' is called.

  See `package-refresh-hour-threshold' for the amount of time needed to
  trigger a refresh."
  :type 'string
  :group 'package)

This variable is useful on its own, but we also need another one, that will specify how much time needs to pass since the last refresh to trigger package refreshing again. I’ve chosen to store a number of hours since you don’t need to refresh package contents really often, but it may be a personal preference. For example, if you update or install packages once a week, it doesn’t really matter, but if you, like me often tried cool packages that people share over the internet, the refresh rate may be set a bit lower than that.

(defcustom package-automatic-refresh-threshold 24
  "Amount of hours since last `package-refresh-contents' call
  needed to trigger automatic refresh before calling `package-install'."
  :type 'number
  :group 'package)

With these two helper variables we can start “patching” package.el so it would use it. We don’t need to modify code, thanks to the advanced advice system:

(define-advice package-install (:before (&rest _) package-refresh-contents-maybe)
  (when (or (null package-last-refresh-date)
            (> (/ (float-time
                   (time-subtract (date-to-time (format-time-string "%Y-%m-%dT%H:%M"))
                                  (date-to-time package-last-refresh-date)))
                  3600)
               package-automatic-refresh-threshold))
    (package-refresh-contents)))

(define-advice package-refresh-contents (:after (&rest _) update-package-refresh-date)
  (customize-save-variable 'package-last-refresh-date
                           (format-time-string "%Y-%m-%dT%H:%M")))

The first advice ensures that before installing a package we’ll refresh package contents if enough time has passed since the last refresh, that is. The second one simply updates the last refresh time, and stores it in the custom file, which I, personally, changed to custom.el in my Emacs directory, like this:

(use-package cus-edit
  :custom (custom-file (expand-file-name "custom.el" user-emacs-directory))
  :init (load custom-file :noerror))

This file is not a part of my version control system and hosts a lot of machine local configuration, so it was natural to store the last refresh date in it too. Of course, it is possible to store it in an arbitrary file, since it’s just a string, and read it inside the package-install advice, but customize makes it seamless, and worked for me quite well.

Hope this was a useful tip!

Comment via email

Why is Paredit is so un-Emacsy?

Thu, 30 Sep 2021 23:40:00 +0300

Here’s a quick rant, kinda.

I’ve become a huge fan of structural editing recently. My structural editing journey was maybe a bit unusual, but I’ve finally settled on Smartparens for quite some time. Originally I was introduced to structural editing by Parinfer mode which had some Paredit functionality, so it got me interested. Then I have been using Parinfer-rust for some time, but when I got the job in Clojure, I realized that it has a major problem of generating too much noise in the Git in commits because it needs to reformat the whole buffer to work, which is way too aggressive, especially when working with multiple people. I’ve already written a small article about parentheses, and various structural editing solutions in this blog, but I’ve actually changed my mind regarding Paredit style editing since that time. Learning some additional shortcuts and chords was not as bad as I thought it would be.

So I switched to Paredit, but it had some bugs related to Clojure, and I’ve replaced it with Smartparens with Paredit keybindings, and I was basically (mostly) satisfied ever since. But recently I’ve read Mastering Emacs (a great book) and decided to greatly simplify my Emacs config. I was tempted to replace Smartparens with Paredit because it felt simpler and more focused, but I’ve figured out that it breaks the tempo¹. I’ve tried to fix most shortcomings of Paredit, but it felt too clunky, and I’ve dropped the idea, since Smartparens doesn’t have such problems, so I’ve returned to it. Funnily enough, the sole reason I wanted to replace Smartparens with Paredit was that I felt that the configuration is way too complicated, but in the end, with all these fixes, Paredit’s configuration was even longer than the one I had for Smartparens.

So here are some problems with Paredit that I’ve noticed after reading Mastering Emacs:

Most commands that should accept negative (or just an arbitrary prefix argument) due to being mapped on a key that usually accepts it, completely ignore it instead.

For example, M-- M-d that acts as M-backspace in most editing modes, just ignores the negative argument in Paredit. I’ve managed to fix that with the following advice, but I’m not sure that every such command can be fixed this way, as there might be no counterpart command. This aspect of modifying commands with the (negative) argument became really important to me, because I’ve started using more motion-related commands, and Paredit basically prevented me from becoming more efficient.

(defvar aorst--paredit-reversable-commands
  '((paredit-forward-delete . paredit-backward-delete)
    (paredit-forward-kill-word . paredit-backward-kill-word))
  "Alist of `paredit-mode' command and their backward motion equivalents.")

(defun aorst/paredit-support-negative-arg (orig-fn &rest args)
  "Find ORIG-FN in `aorst--paredit-reversable-commands' variable,
and apply its counterpart, when the `current-prefix-arg' is
negative."
  (if (eq current-prefix-arg '-)
      (let (current-prefix-arg)
        (if-let ((f (cdr (assoc this-command aorst--paredit-reversable-commands))))
            (apply f args)
          (if-let ((f (car (rassoc this-command aorst--paredit-reversable-commands))))
              (apply f args)
            (apply orig-fn args))))
    (apply orig-fn args)))

(dolist (f (flatten-list aorst--paredit-reversable-commands))
  (advice-add f :around #'aorst/paredit-support-negative-arg))

Transient mark mode deletion feature that was added in Emacs 24 is purposely ignored by Paredit.

This again can be fixed with advice, and actually works reliably enough, making me only wonder why Paredit maintainers decided to put censored swearing in the comment instead of implementing the feature itself. Paredit has everything needed to do this, and yet chose to ignore the feature. It’s easy to fix this with advice, but again, Smartparens does respect Emacs’ design decisions. Here’s the code I’ve written to fix this:

(defvar aorst--paredit-delete-region-functions
  '(paredit-forward-delete
    paredit-backward-delete)
  "List of `paredit-mode' functions that should support tmm region deletion.")

(defvar aorst--paredit-kill-region-functions
  '(paredit-forward-kill-word
    paredit-backward-kill-word)
  "List of `paredit-mode' functions that should support tmm region killing.")

(defun aorst/paredit-fix-tmm (orig-fn &rest args)
  "Allow deleting/killing a region if the expression is balanced."
  (if (and transient-mark-mode
           mark-active)
      (cond ((memq this-command aorst--paredit-delete-region-functions)
             (paredit-delete-region (region-beginning) (region-end)))
            ((memq this-command aorst--paredit-kill-region-functions)
             (paredit-kill-region (region-beginning) (region-end)))
            (t (apply orig-fn args)))
    (apply orig-fn args)))

(dolist (f (append aorst--paredit-delete-region-functions
                   aorst--paredit-kill-region-functions))
  (advice-add f :around #'aorst/paredit-fix-tmm))

In the end, after simplifying my config, I’ve completely turned off the transient mark mode, as it is really not as important as I thought. So maybe this is why Paredit authors didn’t bother to implement this feature, but I still think it’s not an excuse not to support it, some users may rely on it. And I still occasionally enable tmm with the C-space C-space shortcut, so support for this feature is still important to me.

Point position is wrong after using splice commands in inferior-lisp type REPLs and any other REPLs I’ve tried so far.

This actually looks like a bug, but I’ve also noticed that not a lot of people use structural editing in the REPL (maybe because of that?). It’s a minor inconvenience, however, I’ve had zero problems with Smartparens strict mode enabled in REPLs so far. This is very important to me, as I often write code directly in the REPL buffer, so I’d like to have all my structural editing features. Sadly, I wasn’t able to fix this myself.

All this may sound like I’m praising the Smartparens here, but it’s actually not true. Smartparens has a lot of its own quirks and problems, that I had to deal with. It is by no means a silver bullet, but in the current state it’s good enough, I guess.

My dream package would be something based off Tree-sitter (or any other blazingly fast parser) because it actually understands the structure of the code unlike Smartparens, which uses the regex-based search for that. Yes, regex can be used for implementing structural editing, and it works to some degree for languages other than Lisps, as shown by Smartparens, but it’s not near as accurate, as it would be with a proper parser. I’ve tried my best at implementing an algorithm that implements a backward syntax parser for Elixir to make Smartparens better understand the do: keyword, as it doesn’t require matching the end keyword, which broke the parser. It kinda works, but still breaks on some combination of symbols in the code, so it’s not nearly as good as a solution with a proper parser.

However, even with its quirks, Smartparens with the Paredit compatibility layer, and respect for the Emacs editing model, make it overall a better Emacs citizen than Paredit. Yes, it’s somewhat clunkier to configure, but in the end, you have more EMACSy structural editing than you get with Paredit itself, and I actually don’t really understand why is that, as Paredit is older, and was used by Emacs hackers for quite a long time before Smartparens appeared. If anyone knows the story behind that, please let me know!

If you’re interested to try out Smartparens, here’s my configuration, that makes it work similarly to Paredit in most aspects, so you don’t have to re-learn your muscle memory. I’m suggesting you try out Smartparens for yourself, and see if these features I’ve talked about are really worth the switch. It was for me for sure.

Tempo is the term from the Mastering Emacs book, which basically means that you don’t need to release Ctrl or Meta keys for some chord progressions, like when using M-- M-d instead of C-- M-d. ↩︎

Comment via email

Programming ligatures in Emacs

Tue, 21 Jul 2020 21:00:00 +0300

For a long time, I was a fan of Hack font. It has really nice language support, great readability at a size of 9pt, and zero with a dot. I love it when zero comes with a dot. Many fonts use zero with a line, to differentiate it from capital O, but on small sizes, it is not great, however, a dot looks fine when both small and big.

But one thing was lacking from Hack, and it is ligature support. I always wanted to try out ligatures, but there were no other fonts that were visually close to Hack, appealing to my taste, and had good programming ligatures support. I’ve tried Fira Code, but it was too curly for my liking, Iosevka was a bit too narrow, and there’s also Hæck, that is based on Hack, and has ligatures, so looked like a perfect candidate. But my eye was caught by JetBrains Mono. While it’s not the same as Hack, it is visually similar, has great ligature support, and looks a bit nicer in Emacs! The Hack font works for me in a terminal, where I don’t need ligatures, while in Emacs something a little thicker is preferable. So I’ve chosen it, but the ligatures are not working out of the box.

Enabling support for ligatures

There are several options for enabling ligatures in Emacs, listed at Fira Code Wiki page. There are four options:

composition mode in Emacs Mac port
prettify-symbols
composition char table
font-lock keywords

We’re interested in the composition char table. The basic idea is to provide starting character, and a regular expression, that matches all ligatures starting with that character, and put it to the composition table. Here’s the code for JetBrains Mono:

(dolist (char/ligature-re
         `((?-  . ,(rx (or (or "-->" "-<<" "->>" "-|" "-~" "-<" "->") (+ "-"))))
           (?/  . ,(rx (or (or "/==" "/=" "/>" "/**" "/*") (+ "/"))))
           (?*  . ,(rx (or (or "*>" "*/") (+ "*"))))
           (?<  . ,(rx (or (or "<<=" "<<-" "<|||" "<==>" "<!--" "<=>" "<||" "<|>" "<-<"
                               "<==" "<=<" "<-|" "<~>" "<=|" "<~~" "<$>" "<+>" "</>"
                               "<*>" "<->" "<=" "<|" "<:" "<>"  "<$" "<-" "<~" "<+"
                               "</" "<*")
                           (+ "<"))))
           (?:  . ,(rx (or (or ":?>" "::=" ":>" ":<" ":?" ":=") (+ ":"))))
           (?=  . ,(rx (or (or "=>>" "==>" "=/=" "=!=" "=>" "=:=") (+ "="))))
           (?!  . ,(rx (or (or "!==" "!=") (+ "!"))))
           (?>  . ,(rx (or (or ">>-" ">>=" ">=>" ">]" ">:" ">-" ">=") (+ ">"))))
           (?&  . ,(rx (+ "&")))
           (?|  . ,(rx (or (or "|->" "|||>" "||>" "|=>" "||-" "||=" "|-" "|>"
                               "|]" "|}" "|=")
                           (+ "|"))))
           (?.  . ,(rx (or (or ".?" ".=" ".-" "..<") (+ "."))))
           (?+  . ,(rx (or "+>" (+ "+"))))
           (?\[ . ,(rx (or "[<" "[|")))
           (?\{ . ,(rx "{|"))
           (?\? . ,(rx (or (or "?." "?=" "?:") (+ "?"))))
           (?#  . ,(rx (or (or "#_(" "#[" "#{" "#=" "#!" "#:" "#_" "#?" "#(")
                           (+ "#"))))
           (?\; . ,(rx (+ ";")))
           (?_  . ,(rx (or "_|_" "__")))
           (?~  . ,(rx (or "~~>" "~~" "~>" "~-" "~@")))
           (?$  . ,(rx "$>"))
           (?^  . ,(rx "^="))
           (?\] . ,(rx "]#"))))
  (let ((char (car char/ligature-re))
        (ligature-re (cdr char/ligature-re)))
    (set-char-table-range composition-function-table char
                          `([,ligature-re 0 font-shape-gstring]))))

By enabling auto-composition-mode we can see the ligatures in action:

Figure 1: Ligatures off

Figure 2: Ligatures on

Hint: open images in separate tabs and toggle between those to spot the difference.

Note, in order for ligatures to work, Emacs needs to have support for HarfBuzz which was added in Emacs 28.

But I don’t want these ligatures to be enabled everywhere, only in programming-related modes, so here’s a config for composite package:

  (use-package composite
    :hook (prog-mode . auto-composition-mode)
    :init (global-auto-composition-mode -1))

This takes care of most of the errors, listed under composition char table section in Fira Code Wiki. Also by using rx macro we avoid writing complex regular expressions with backslash escape hell, and handle this task to Emacs itself. It’s good when Emacs does boring stuff for us, isn’t it?

Comment via email

Using a single Emacs instance to edit files

Mon, 29 Jun 2020 22:45:00 +0300

Modern text editors usually operate in one instance. When I select some advanced text editor as my preferred editor in the system, I expect this to happen:

I click on some files in the file manager;
If there’s no editor instance opened, a new instance opens with the file ready to edit;
If there is an instance of an editor opened somewhere, a file is being opened in it, and the editor is brought to me via some focus event.

This is what happens when you associate most of your files to be opened in VSCode for example. But this is not the case for Emacs, which is unfortunate. But, this is Emacs, of course, we can change it!

Usually, we don’t think about it much, but Emacs comes in two parts. The first one is the Emacs server, and the other one is the Emacs client. However, every time when someone mentions the Emacs server, it happens in the context of a startup time issue solution – e.g. launch Emacs once, then only connect to the process. And mostly the solution is to run Emacs when the system starts, and only restart it if you’ve updated the configuration in a way when Emacs has to be restarted.

This is not what I want, since I don’t have startup speed issues – my Emacs configuration starts under 1.4 seconds on my machine. However, I want Emacs to use one instance unless I explicitly request an additional one. I did a bit of searching for a solution but unfortunately didn’t find any that would satisfy my needs.

Configuring `server-mode`

To achieve our goal we need to configure server-mode in Emacs. Surprisingly there’s not so much of a configuration needed. I’m using use-package so I’ve added this into my init.el:

(use-package server
  :straight nil
  :config
  (unless (server-running-p)
    (server-start)))

You can see, that we’re starting the server only when there is no other server running. This is important for us, so we still could use multiple sessions without confusion.

Unfortunately, other sessions will not use their own servers, but I personally don’t care. I’ve thought about maintaining a persistent variable that holds server PID but dropped the idea since I’ve never actually used two different sessions of Emacs where I would want to connect sessions to different servers. This is definitively the point that can be improved, but it works fine for my needs in its current form, but if someone has an idea, feel free to open an issue or pull a request at my dotfiles repository so we could discuss it.

Although the server part is not the only configuration we need to perform, otherwise this would not really be enough to make a post :)

System configurations

Another big part is the desktop file, which we will be using to launch Emacs from the desktop environment menus, as well as the function for when we’re launching from the shell.

First is the shell function, as it is not so convoluted:

emacs() { emacsclient -a 'emacs' -n "$@" 2>/dev/null || command emacs; }

If you add this function to your .bashrc it will replace emacs command in your shell session. What this command does, is tries to open emacsclient, and connect to the server. We may fail, because there’s no server running yet, and in this case, we fall back to command emacs which will launch Emacs, which in turn will start the missing server.

In case the server is already running, emacsclient will be able to connect to it, but it will not spawn another window, instead it will use a running instance and a file will be opened in it. Sweet!

This pretty much defines the behavior I want, but I’m not launching Emacs from shell very often, so I want this behavior to happen when I click on files in my file manager, or when I’ve downloaded something in a web browser. For this, we will need a very similar thing as our shell function, except it will be the .desktop file.

XDG specification allows us to create emacs.desktop under ~/.local/share/applications/ with these contents:

[Desktop Entry]
Name=Emacs
GenericName=Text Editor
Comment=Edit text
MimeType=text/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-c++src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-tcl;text/x-tex;application/x-shellscript;text/x-c;text/x-c++;
Exec=sh -c "emacsclient -a emacs -n \"\$@\" || command emacs" dummy %F
Icon=emacs
Type=Application
Terminal=false
Categories=Development;TextEditor;Utility;
StartupWMClass=Emacs

Note, you’ll also need emacs.png icon under ~/.local/share/icons/, so this .desktop file could be displayed with it in the menus.

You can see that we’re using exactly the same function, as in the shell, except we pass the dummy argument because that’s how it works for some reason. And we have all this other noise around, to correctly display menu entries.

Now we can associate files we want to be opened with Emacs with this .desktop file, and just as with the shell function, Emacs will be opened if no instance is running, and the existing instance will be used if you click on another file without spawning new windows. With tabs this is really handy and works exactly how I would expect from an advanced text editor.

I think the same trick should be possible to do on other operating systems, but I don’t know their equivalent of .desktop files, so I’ll lave this part for those who would want to try ;)

Comment via email

Managing background processes from Kakoune

Fri, 05 Jun 2020 13:04:00 +0300

While working on my previous post I was mainly using Emacs, because it has the best support for Lisp languages. It has great integration with the REPL, can run a server for my application in the background, and so on. And actually, I use this a lot while working on this blog - I run hugo process in the background to see how my page is looking. This got me thinking about handling all of this in Kakoune.

Kakoune has facilities to run processes in the background, and it does this for many tools like grep, make, ctags, and other common shell tools that we use often. Kakoune also has built-in REPL support with repl and send-text commands, which can be used when I work with Lisps. However, there’s a problem.

When working with Clojure, I need to run two JVM instances in the background. This is due to the architecture of the project, and I can’t really do anything about it. So when I’m programming in Emacs, an amazing package, named CIDER^{(Clojure IDE that Rocks)} does this for me. But in order to do this in Kakoune, I have to start another terminal or create a new window in Tmux, and I don’t really like this.

So I’ve thought, why not start this from Kakoune itself? The problem though is that there’s no built-in way that I can think of. There are ! and | commands to run a synchronous process and pipe its result into a buffer, which is not for me. I’d also like to kill a process if I don’t need it, and see its log as if it ran in a terminal. Turns out it isn’t a really hard task.

I’ve created pmanage.kak plugin to test this idea. This plugin is quite small and has these three commands:

pstart <command>: Starts command as a background process, and creates FIFO buffer for that process named after process PID.
pstop <PID>: delete process buffer and send SIGTERM signal to process.
pkill <PID>: delete process buffer and send SIGKILL signal to process.

So now, I can do this:

open Kakoune in project root;
call :pstart 'npx shadow-cljs watch app' to start background watching process.
- A new FIFO buffer is created, and process PID is stored into a special option;
Then I can do :repl 'npx shadow-cljs cljs-repl app' and open REPL window that will be connected to that watcher process;
Develop!

I am also now able to run :pstart 'hugo server -D', and edit any Markdown files that my blog is made of. And when I don’t need that process I simply can call :pstop PID or :delete-buffer PID.

I know about kakoune:1414, but I think the solution I came up with is fine for most use cases.

Comment via email

Making Emacs tabs look like in Atom

Sun, 10 May 2020 22:41:00 +0300

This is yet another follow-up post in the Emacs configuration series, which is also about Tabs. The previous post was about how tabs behave when you close them, and how I think the algorithm can be improved. This post is more about visuals and horizontal space management.

By default tabs in Emacs are named after their respective buffers. This is how tabs look with my configurations and default naming:

Looks fine, but there’s a catch. Tabs with really long names take a lot of horizontal space, which can be a problem when dealing with buffers that were created by some package, like CIDER:

With tabs of this size, no wonder we get complaints that tabs are not usable. And on this screenshot, you can see that all tabs have different widths, which doesn’t really look good in my opinion. Both problems can be fixed with some code, but first, let’s check how the Atom editor handles tab sizes.

Tabs in Atom

This is the default look of tabs in Atom editor with One Dark theme:

By default tabs in Atom occupy more space than is actually needed for a tab, and I think that this is beautiful. Someone may be concerned that it wastes horizontal space, but it’s actually not - if we open more tabs, their width will shrink to make those fit in the window:

But this not going to happen all the time, and eventually, once some minimum width is reached, tabs will no longer shrink, and we’ll have to scroll those. We still can get the idea of what file is opened in the tab, and there are a lot of them in such a tiny window. And if some tab has really long name that doesn’t fit into a tab, it gets truncated:

This is the behavior we’re going to replicate in Emacs.

Making Emacs tabs resize automatically

First, we will need two variables - one for minimum width, and one for maximum width. I like to define variables that extend some built-in packages via defcustom because if someone else will use my config they will be able to customize such things with the custom interface or via code. Also Custom makes persistent configurations a bit easier as well.

(defcustom tab-line-tab-min-width 10
  "Minimum width of a tab in characters."
  :type 'integer
  :group 'tab-line)

(defcustom tab-line-tab-max-width 30
  "Maximum width of a tab in characters."
  :type 'integer
  :group 'tab-line)

Good. This will later be used in a function that creates a name for the tab. Now we need to think about the general algorithm. Note that we’re defining size in terms of monospace characters. This algorithm will not work for variable pitch fonts.

In Atom, tabs use fixed width up until there is no more horizontal space in the window to fit full-sized tabs. In Emacs, we can access the width of a window with the window-width function. So our first step will be to obtain such width, and check how many tabs will fit into it. However, instead of checking the number of tabs, we will calculate the width of the tab that we will need for all tabs that we currently have:

So, if our window is 300 chars wide, and we have one tab, it will occupy the whole width. If we have two tabs, each should be 150 chars long, and so on. This is great, but if we have 70 tabs, each would be only 4 chars. Given that we need at least one char to display the left padding, one char to display the close button, and one char for the right padding, we’re left with 1 char for the name which is not good at all. However we don’t want to use such wide or such narrow tabs, so we need to adjust their length based on these conditions:

This way if we have a tab width larger than our maximum width, we will use maximum width. If we have a width that is less than our minimum width, we will use minimal width, and this will enable scrolling. If we’re in between, we’re using the width that was calculated in the previous formula. Note that we’re subtracting the size of the close button from our width which is represented as × with spaces at the front and the end.

The second thing we need is to produce a valid name for the tab, but right now we will simply string-trim buffer name, and calculate its width. This should leave us with these computations:

(defun aorst/tab-line-name-buffer (buffer &rest _buffers)
  (with-current-buffer buffer
    (let* ((window-width (window-width (get-buffer-window)))
           (close-button-size (if tab-line-close-button-show
                                  (length (substring-no-properties tab-line-close-button))
                                0))
           (tab-amount (length (tab-line-tabs-window-buffers)))
           (window-max-tab-width (/ window-width tab-amount))
           (tab-width (- (cond ((>= window-max-tab-width tab-line-tab-max-width)
                                tab-line-tab-max-width)
                               ((< window-max-tab-width tab-line-tab-min-width)
                                tab-line-tab-min-width)
                               (t window-max-tab-width))
                         close-button-size))
           (buffer-name (string-trim (buffer-name)))
           (name-width (length buffer-name)))

Now, when we have all this information, we can compute the name for the tab and its paddings. First, we need to check if the trimmed buffer name exceeds the tab width. If it is, we truncate the name to the width of the tab minus 3, because we need to add single space padding before a name and add an ellipsis symbol followed by a space at the end.

17
18

(if (>= name-width (- tab-width 3))
    (concat  " " (truncate-string-to-width buffer-name (- tab-width 3)) "… ")

If name-width is less than tab-width minus 3, we can produce left padding, by computing difference between tab-width and name-width, and dividing it by 2. Then we concatenate this padding and calculate the right padding needed for the name. This extra calculation is needed when a name is odd or even, so we produce equally sized tabs for any buffer name:

(let* ((padding (make-string (/ (- tab-width name-width) 2) ?\s))
       (buffer-name (concat padding buffer-name))
       (name-width (length buffer-name)))
  (concat buffer-name (make-string (- tab-width name-width) ?\s)))))))

This gives us such results. With the same window width as in Atom examples, two tabs will occupy this amount of space:

If we will open four tabs, the size of each tab will shrink accordingly:

Though this is not as nice as in atom, due to the small unused space on the right side of the window. Unfortunately, we can compute width only in terms of characters, which can’t really have variable width, unless we use variable pitch font, but as I’ve mentioned earlier, this algorithm will not work with variable-sized fonts, and perhaps such computation will be quite expensive. Computing variable width in terms of pixels may be possible, but I couldn’t find any information on this topic. But the character-based solution should also work fine in terminal Emacs.

When we open too many tabs, we can see scroll buttons, and tabs no longer shrink in size beyond tab-line-tab-min-width value. We also can disable the close button if we want:

Rationale

Before:

After:

In the beginning, I’ve said that there are a lot of complaints that tabs unnecessarily waste horizontal space. Even though we’ve fixed this, now you may think, that this is still impractical, because you can’t see the whole name of a file in the tab, and tabs are not usable as a concept overall. And I can agree to a certain point. An interactive buffer list, that we can fuzzy match through, has no issues with space because we pop it up when needed, and can show you full buffer names any time. But I find myself using tabs very often simply as a visual indicator of what buffers are next and previous in the list, and switch between those via C-x right and C-x left. You can’t really do this with a buffer list unless you display it somewhere all the time, but then it takes much more space than tabs.

Tabs also help a lot when someone, who isn’t an Emacs user and is unfamiliar with the concept of buffer list, sits near me, since the concept of tabs is well known and obvious to most other people, because of tabs in browsers or other editors.

~~One thing that I have not yet succeeded to achieve is to automatically recalculate tab width on frame or window resize events~~. ~~It seems that force-mode-line-update does not initiate the process of name building, but for some reason, it happens on focus events, so I have yet to investigate this part~~.

Turns out there’s a way to update tab width on resize events by clearing the cache of tab-line in each window. As a quite dirty hack, we can use this hook:

(add-hook 'window-configuration-change-hook
          #'(lambda ()
              (dolist (window (window-list))
                (set-window-parameter window 'tab-line-cache nil))))

This makes tabs resize whenever you change window or frame width with your mouse, or when you split windows via C-x 3 and other windowing commands that change window layout.

Though this post only mentions the naming function, I’ve set up a bit more things to make tabs look as represented on screenshots. This configuration can be found in full form in my .dotfiles.

Comment via email

Making Emacs tabs work like in Atom

Thu, 07 May 2020 20:41:00 +0300

Another little piece from my Emacs config that I’ve decided to turn into a small post, following up on previous one. This time, we’re going to make tabs work as in most graphical editors.

Tabs were added with global-tab-line-mode in Emacs 27, and are pretty simple tabs, that are being displayed on the top of a window, and by default, their semantics are not very useful in my opinion. The main problem is that you get only two policies of how the closing of a tab will behave. It is either bury-buffer, which simply hides the tab, and moves the buffer to the end of the buffer list, and kill-buffer which always kills the buffer, and hides the tab, and you can’t really combine those behaviors by default.

This is not very useful, because you can have many windows, with the same buffers in each one, and when you want to close the window you can’t do that by closing the last tab. For example, in Atom, if we have such configuration:

If we close file-B tab we will be left with one window:

This is useful and works the same way in VSCode or Sublime Text. Let’s try the same thing in emacs -q. First, we create two windows, with a tab in each:

Then we press little close button on file-b tab:

And it replaces it with the file-A tab. This happens because when we click on the close button it calls bury-buffer, so the tab goes away, a new buffer is displayed, and we’re getting a new tab for it. This is not great. I think when we close the last tab in the window, the window should be killed as in Atom¹.

The other thing is this. In Atom we can have two windows with the same buffers opened like this:

And if you close one of the tabs the file will not be closed until all tabs are closed, but the window will be:

In Emacs, however, we can’t close the tab via the close button, because it will cycle buffers, so instead we can switch to the second policy of killing buffers instead. But it will not work either, because it will not kill the window, and it will kill the buffer in all windows. So how do we fix this?

First, let’s establish some logical rules:

Buffer can exist without a tab, but a tab can not exist without a buffer,
If the tab was closed buffer should be killed only if there are no tabs for this buffer left,
If the tab was closed and there are no more tabs in the window, the window should be killed.

These three rules are basically how tabs work in modern editors. Now we need to implement this in Emacs Lisp. Since there’s no way of configuring which function is used for closing a tab, we’re going to override it with an advice in our configuration file:

(define-advice tab-line-close-tab (:override (&optional e))
  "Close the selected tab.
If the tab is presented in another window, close the tab by using the `bury-buffer` function.
If the tab is unique to all existing windows, kill the buffer with the `kill-buffer` function.
Lastly, if no tabs are left in the window, it is deleted with the `delete-window` function."
  (interactive "e")
  (let* ((posnp (event-start e))
         (window (posn-window posnp))
         (buffer (get-pos-property 1 'tab (car (posn-string posnp)))))
    (with-selected-window window
      (let ((tab-list (tab-line-tabs-window-buffers))
            (buffer-list (flatten-list
                          (seq-reduce (lambda (list window)
                                        (select-window window t)
                                        (cons (tab-line-tabs-window-buffers) list))
                                      (window-list) nil))))
        (select-window window)
        (if (> (seq-count (lambda (b) (eq b buffer)) buffer-list) 1)
            (progn
              (if (eq buffer (current-buffer))
                  (bury-buffer)
                (set-window-prev-buffers window (assq-delete-all buffer (window-prev-buffers)))
                (set-window-next-buffers window (delq buffer (window-next-buffers))))
              (unless (cdr tab-list)
                (ignore-errors (delete-window window))))
          (and (kill-buffer buffer)
               (unless (cdr tab-list)
                 (ignore-errors (delete-window window)))))))
    (force-mode-line-update)))

Now let’s break this down. First, we’re storing our posnp, window, and buffer, then with our selected window, we get a list of tabs via a call to tab-line-tabs-window-buffers, which effectively returns a list of buffers that have tabs associated with those. Then we get a full list of buffers in all windows and store it to buffer-list variable, which we will need later.

Next, we select the window and count how many times we find buffers in our list of buffers from all windows. If it is more than 1, then we can we’re going to bury that buffer. If it is 1 we’re going to kill it since it is the last tab of that buffer.

There’s another check in there, that checks if the tab is last in the list of tabs for that window, and if it is, e.g. if (cdr tab-list) returned nil we’ve just closed the last tab in the window, so we can kill it as well.

In the end, we force a mode-line update because it updates the tab line as well. So now, with this function (and the rest of my config) let’s try previous examples in Emacs:

Now we close file-B:

Buffer file-B and its respective window both were killed. Now we create windows with the same buffer:

And if we close the right tab, we see that window is deleted, but the buffer is not affected:

And if we had tab file-A in first window and two tabs for file-A and file-B in second, closing file-A in second window will not kill file-A buffer, and will not kill the window, because tab for file-B is still there:

Closing file-A tab doesn’t kill file-A buffer or window:

Closing file-B tab kills its buffer and window:

This makes tabs in Emacs behave as in Atom or VSCode.

Atom actually has a setting for it, so when you close the last tab it can display an empty window, in which you can later drag and drop new tabs, but in Emacs, there is no such thing as empty windows, so it makes sense to always kill the window if there are no tabs left. ↩︎

Comment via email

Dynamic title for Treemacs workspace

Fri, 01 May 2020 16:44:00 +0300

Thought that I can share snippets of my Emacs config from time to time here, just like @clemera does on with-emacs.com. I highly recommend you to check it out, there are many great recipes and articles.

A while ago I’ve added static Treemacs title to Treemacs buffer for aesthetic purposes - it adds good alignment with tabs in other windows. But recently I’ve thought that it could also be useful, and indicate the workspace that I’m currently in. I have many workspaces, so this is good info to have. Here’s my little piece of code that creates a dynamic title for the package:

(defun aorst/treemacs-setup-title ()
  (let ((bg (face-attribute 'default :background))
        (fg (face-attribute 'default :foreground)))
    (face-remap-add-relative 'header-line
                             :background bg :foreground fg
                             :box `(:line-width ,(/ (line-pixel-height) 2) :color ,bg)))
  (setq header-line-format
        '((:eval
           (let* ((text (treemacs-workspace->name (treemacs-current-workspace)))
                  (extra-align (+ (/ (length text) 2) 1))
                  (width (- (/ (window-width) 2) extra-align)))
             (concat (make-string width ?\s) text))))))

Then we need to hook this function to treemacs-mode-hook, so it is called when Treemacs sets its mode in the buffer.

What this function essentially does is, it creates header-line for Treemacs buffer, adds nice box for it with the width half the size of line height, and set’s its background and foreground based on your theme. After that, it gets the Treemacs workspace name, calculates its length, and the needed amount of spaces in order to center text in the window. The ending result is like this:

Or with Emacs default theme:

Full Treemacs configuration can be found in my .dotfiles.

Comment via email

Andrey Listopadov

Limiting Horizontal Scroll In Emacs

Project.el enhancements

Finding project root based on specific root-markers

Saving only project buffers before compilation

Automatic refreshing of package archives for Emacs

Why is Paredit is so un-Emacsy?

Programming ligatures in Emacs

Enabling support for ligatures

Using a single Emacs instance to edit files

Configuring server-mode

System configurations

Managing background processes from Kakoune

Making Emacs tabs look like in Atom

Tabs in Atom

Making Emacs tabs resize automatically

Rationale

Making Emacs tabs work like in Atom

Dynamic title for Treemacs workspace

Configuring `server-mode`