For the English part of the blog, see Content AND Presentation.
2025-12-08 Some new additions to Emacs
While I’ve been compiling my Emacs from source code for a very long time, I do not do that very often. I’m still excited by the cool new things Emacs developers cook for us all, but I don’t have time (nor do I remember) to git pull and make all my Emacs very often.
However, I did it a few days ago, and was greeted with three surprises – two fantastic ones and one less so.
The less fantastic one means that some time before my last compilation of Emacs, the developers decided to issue a warning whenever Emacs loads a file without a “lexical binding cookie”. Don’t get me wrong – this is a very reasonable and expected change – but it means that my Emacs suddenly became very grumpy. Of course, this is (a bit) my fault – I load lots of small Elisp files at Emacs start, and the vast majority do not have the lexical binding cookie – but I also load autogenerated files (for example, files created by AUCTeX), and they don’t have the cookie. (Of course, I updated AUCTeX and now those files do get the cookie, but this means that I’ll have to regenerate all of them. Not a big deal, but a tiny bit of a hassle.)
Let’s now talk about one of the better surprises. In this version of Emacs, when I place the point on an “added” or “deleted” line in Diff buffers, and the line is actually changed (so it has a corresponding “deleted” or “added” line somewhere close), the place corresponding to the one I’m on is highlighted using the smerge-refine-shadow-cursor face. Even though it seems a little bit distracting, I like it a lot. I look at diffs very often, usually (but not always) in Magit buffers, and being able to orient myself in the diff this way can be extremely helpful.
I’m not sure how robust this feature is – I mean, I have a very high opinion about Emacs devs, but diff itself is not very robust (since it is line-based and doesn’t take the code structure into consideration), so I expect weird behavior from time to time. But that is not really a problem for me – in these cases I usually resort to difftastic anyway.
But wait, there’s more! The bleeding edge has another great addition – fill-paragraph-semlf. This is something many people seem to want, and also something many people coded themselves or copied from some blog or wiki. It is basically a fill-paragraph smart enough to begin each sentence on a separate line. At first, I was tempted to remap M-q to this new function, but I was a bit afraid to use it in Org mode. It has its own org-fill-paragraph command, which apparently does something more (or something else?) than just calling fill-paragraph. However, I looked at the code of fill-paragraph-semlf, and it turns out that it’s actually very simple – this is its main part:
(let ((fill-region-as-paragraph-function
#'fill-region-as-paragraph-semlf))
(fill-paragraph justify region)))
So, I decided to put
(setq fill-region-as-paragraph-function
#'fill-region-as-paragraph-semlf)
in my init file and from now on I get the new behavior whenever I press M-q both in Org mode and for example emails. (I’m not yet sure if I want that in emails.) Bad news is that it doesn’t work in AUCTeX, which has its own filling command. This is what I found in the AUCTeX sources:
;; The content of `LaTeX-fill-region-as-para-do' was copied from the ;; function `fill-region-as-paragraph' in `fill.el' (CVS Emacs, ;; January 2004) and adapted to the needs of AUCTeX.
Well, I guess I’ll just have to live with it. (I don’t use TeX very often these days anyway.)
To sum it up, if you haven’t consider compiling Emacs from source yet, now you have some good reasons! Of course, you can also wait until these features land in a new official version, though I have no idea when this is going to happen. (New Emacs versions are released fairly often these days, so probably not more than a few months.)
2025-12-01 Uppercasing a single letter
There are some key bindings in Emacs which many people remap to something they consider “more useful”. I do it myself – pretty much the only thing the default binding for C-z (suspend-frame) does is annoy me. What I don’t understand is that some people do this to M-c, M-l and M-u, bound to capitalize-word, downcase-word and upcase-word respectively by default. I consider them tremendously useful (in fact, I sometimes even use C-x C-l (downcase-region) even though I claimed myself back in 2019 that it’s “useless”!). What I want is not fewer case-changing commands, but more of them! My issue is camelCase identifiers. As most Lispers know, camelCase is a terrible idea, and people use special tricks to make it more legible. Still, it is quite popular, among others in the JavaScript world (well, it’s called JavaScript and not java_script, so what should I expect…)
A few days ago I had the following problem when using Knex.js. I had a .whereIn() clause which I wanted to change to .orWhereIn(). My immediate reflex was to position the point on the w, type or and press M-c to change the w to upper case. Of course, this doesn’t work, since capitalizing whereIn changes it to Wherein, not WhereIn.
What would solve my problem would be a command to upcase one character only. Writing such a command is easy enough, but it turned out that a command like this (upcase-char) already exists in Emacs. The only thing I needed was to bind it to some key. Usually commands operating on character vs. words are bound to corresponding C- vs. M- keychords, but of course C-c is, well, out of bounds
. It turns out, however, that M-C (that is, M-S-c, or Alt+Shift+C) is free. So, I now have this in my init.el:
(global-set-key (kbd "M-C") #'upcase-char)
That’s it for today!
2025-11-24 Changing window layout
Sometimes I have my Emacs frame split, for example having two windows – one beside the other – and I want to preserve both windows but have them stacked on top of each other. Or vice versa.
I figured that it shouldn’t be too difficult to write some little function to do that (although dealing with windows and their positioning is notoriously complex – but also incredibly flexible). I decided to look for existing solutions first.
I was not disappointed.
It turns out that Emacs has me covered already! Today I learned about the window-x package, which is built into Emacs (and autoloaded, so you don’t even have to require it). The “commentary” at the top of the file is pretty short:
This file defines less frequently used window organization commands.
The package defines one user option (about which later) and several commands (most of which come in pairs). A word of warning: the commands have been renamed recently, so what you get depends on which Emacs version you have. So, unless you have a bleeding-edge Emacs (or are reading this in the future), your Emacs may have a slightly differently named set of commands than what I describe below. Say M-x find-library RET window-x RET to see what you have installed.
Edit: I received a message that I was wrong – this library is only available in Emacs 31, so if you use the official, released version, you’ll have to wait for them. Sorry for my mistake!
So, the first pair is window-layout-rotate-anticlockwise and window-layout-rotate-clockwise. It is not easy to describe their effect in words, but imagine something like rotating your screen by 90 degrees – so each horizontal window split becomes a vertical one and vice versa – but of course without rotating the windows’ contents.
Here is an example using screenshots, which might be helpful to wrap your head around my clumsy description. (Note that my Artist clock completely broke because its window was too short.) The original layout is on the left, and the result of calling window-layout-rotate-anticlockwise on the right.
The next pair is window-layout-flip-leftright and window-layout-flip-topdown. These are easy to explain – they just change the current window configuration to its mirror image (with a vertical or horizontal axis).
Then, window-layout-transpose is the only one that doesn’t have a pair. (Mathematically speaking, the pairs are inverses, and this one is its own inverse.) It just flips all the windows along a diagonal axis, so the top window(s) become the left one(s), the left one(s) move to the top, the one(s) on the right move to the bottom, etc.
And the last two commands are rotate-windows and rotate-windows-back, which are (again) a bit tricky to explain in words. They leave the layout unchanged, but move the contents of the windows (clockwise or counterclockwise).
The one user option comes into play here. It is called rotate-windows-change-selected and depending on its value, the selected window stays the same or moves with the content. (The default is t which means that the selected window changes contentwise – that is, another buffer is now in the selected window – but stays the same geometrically – that is, if the leftmost window was selected before rotate-windows, the leftmost window is selected afterwards, etc.)
If your head isn’t spinning yet, there’s more! Each of the commands in window-x supports a prefix argument. If called with C-u, they perform their machinations on the parent window of the current window instead of the whole frame.
I’m not entirely sure how useful all these functions are to me. I have bound window-layout-transpose to C-x 4 t (by saying (keymap-set ctl-x-4-map "t" #'window-layout-transpose) in my init.el). This covers my initial requirement of being able to switch between “two windows side by side” and “two windows on top of each other”. Time will tell if that is enough – if not, I could always create a dedicated window-x keymap at C-x 7 or C-x 9, which are currently unused, or even C-x 6 which is a prefix key for two column editing (a feature I’ve never used in over 2 decades of using Emacs!).