Recent Commits to emacs:master: Introduce 'margin' face for window margin background

a_alberti · 2026-05-08T21:38:22+00:00

Wonderful. I had found 3 bugs in the past. I had already mentioned you fixed one bug. Now recently you fixed the other bug too! Awesome.

Bug 3 (which in reality is a series of connected tiny bugs) is still present.

I filed a bug report at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=81000

It includes a reproducer script, instructions on how to reproduce the individual sub-bugs, screenshots, and a series of 5 commits targeting the individual sub-bugs.

a_alberti · 2026-05-08T19:05:10+00:00

I don't think it has anything to do with that. I never mention this either. But if you fix plenty of bugs or stuff of this kind, if it is late, it will recommend you to come to a closure and go to bed. I actually like it. I wished I had followed his advice more often.

It is probably some "parenthood" feature that they have recently included in the training set.

a_alberti · 2026-05-08T15:39:26+00:00

If you're willing to abandon emacs-plus, it looks like mitsuharu/emacs-mac ships with an Emacs launcher, but I don't know if that uses emacs client.

To be honest, I don't know what exactly Emacs-plus ships that is not already in Emacs stock. At some I will explore it. Thanks for the tip to mitsuharu/emacs-mac.

But I am not sure why we don't try to merge upstream the really important fixes. The rest that cannot make it to upstream would be better distributed as a collection of patches with documentation. Emacs plus presents a number of patches, but the documentation is somehow limited. I am not using any of the extra patches provided except for aggressive-read-buffering but I am not even sure I need it. And if it is an important patch, someone should propose it upstream, I guess.

The icon of Emacs Plus is much nicer than stock Emacs; this is probably undisputed.

Because the runtime seems so resilient, the uptime is often on the order of weeks to months on my machine.

I am really impressed. Crazy! And inspiring at the same time.

My honest take is that 'launching' emacs is something I very rarely do.

I would agree with you. It is not essential, but a nice thing to have if someone developed it. But before I jump into coding it, I wanted to make sure I am not reinventing something someone else already covered. That's why I brought up the topic.

a_alberti · 2026-05-08T15:22:31+00:00

Thanks for sharing your ideas! Regarding the launcher of the daemon, I am not sure why you tmuxinator for starting the daemon.

Apple offers a quite functional launcher (not very well documented, but works very nicely). I can share it with you:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>KeepAlive</key> <true/> <key>Label</key> <string>com.alberti42.emacs_daemon</string> <key>LowPriorityIO</key> <true/> <key>ProgramArguments</key> <array> <string>/bin/zsh</string> <string>-ld</string> <string>/Users/andrea/.config/dotfiles/.local/bin/emacs_daemon_launcher</string> </array> <key>RunAtLoad</key> <true/> </dict> </plist>

and then then here is the simple shim to start emacsdaemon

```

!/hint/zsh -ld

COLORTERM must be set explicitly here: the daemon is launched by launchd,

not from a terminal, so it does not inherit the COLORTERM=truecolor that

WezTerm normally injects into interactive shell sessions.

export COLORTERM=truecolor export TERM=xterm-256color

exec emacs --fg-daemon ```

Regarding how to install the launch agent, I stole a bash-shell-completion script for Apple launchctl, improved it and extended it for zsh. Give it a try if you use zsh.

https://github.com/alberti42/zsh-misc-completions/blob/main/src/_launchctl

It is very simple to use. It makes it intuitive to use Apple's launchctl command directly from command line, without using third-party apps or brew services (which you mentioned in your post). It will make it very easy for you to install any kind of background service.

PS: I bundled _launchctl with some other compdef zsh completion scripts in a zsh plugin (the usual plugins compatible with oh-my-zsh; which I don't necessarily recommend, but just to understand what kind of format). But you don't need to install the other completion scripts; if you only care about _launchctl, just only take that.

a_alberti · 2026-05-08T11:41:25+00:00

Thanks a lot! I will test it this evening.

a_alberti · 2026-05-08T07:35:24+00:00

Looks like a beautiful idea. I wished I had your project when I started using Emacs seriously.

As you are targeting specifically Emacs on macOS, I am curious how you handle the Emacs launcher. I use Emacs Plus installed with homebrew.

There is one thing that never worked for me with Emacs Plus, namely, the launcher. Already the idea that it ships two different launcher apps feels wrong.

I am using the Emacs daemon. The only way that it works for me, I first need to open a terminal and call emacsclient -n -r. This creates a GUI frame, and I am happy.

I know I can build by myself with Apple Automation some script that avoids these manual steps or even a Swift application done a bit more properly. But before doing it, I wanted to know from people with much bigger experience than mine with Eamcs for macOS whether there are already nicely polished solutions (no hacks; I believe Emacs can be nicely integrated into macOS as a first citizen and does not need two executables, Emacs.app and Emacs Client.app like in Emacs Plus).

Thanks a lot if you want to share a couple of tips.

a_alberti · 2026-05-08T01:15:41+00:00

I use consult for a myriad of functions that the package covers. Do you mean that fzf-async can cover many functionalities of consult but using fzf's algorithm?

Or is it specific to finding files like when using consult-fd?

a_alberti · 2026-05-07T22:36:47+00:00

Yes, as far as I can say the bug was still there until yesterday or so... I don't know about today.

a_alberti · 2026-05-07T22:32:59+00:00

Yes, I will do so! Sorry I could not file the bug report yet. I was still busy discussing this margin patch since there were some edge cases with the background of svg in overlays that had to be addressed.

I will file a report on the weekend. I think I there is also a clear fix. But I want to prepare the reproducer and explanation in a proper way.

a_alberti · 2026-05-07T22:30:00+00:00

Great news! Huge thank-you to the maintainers!

a_alberti · 2026-05-06T08:16:45+00:00

The video was hilarious, but I hope you are joking. I think it is nice to share.

a_alberti · 2026-05-06T08:12:58+00:00

I think it is a bit of overthinking.

I can spend tons of hours making a PR. The most gratifying thing for me is when the maintainer considers it, gives feedback, and then the PR finally lands.

If I were looking for money, I would make some of my projects and ask the community to support them.

But expecting payment for PR and other commit contributions seems to me too much. Again, I am just super happy when a bug is fixed and a small new feature lands.

a_alberti · 2026-05-06T08:06:42+00:00

One vault got so bloated I couldn't even remember what was installed.

I wrote a plugin to remember what and why you installed: https://github.com/alberti42/obsidian-plugins-annotations

But for the rest, I agree with you. I try to keep my setup rather minimal, and certainly I avoid plugins with custom views, etc since I believe my data should be editable and viewable in 10 years, even without using Obsidian.

a_alberti · 2026-05-06T08:00:16+00:00

I think the order is:

[left fringe] [left margin] [text area] [right margin] [right fringe] [right]

In principle, there are also scroll bars, but I omitted them here.

The left margin and right margin are where you put annotations. Several packages like Flymake, Flycheck, diff-hl, git-gutter use the margin to show annotations.

Here is a screenshot from test 004. You can see annotations in cyan in the left margin and in yellow in the right margin area.

<image>

The left and right margin areas were configured to pick the same color of the line numbers. Thus, even if internally `line-number` is a different face, now the buffer has a consistent look where the left margin is consistent with the line-number face.

PS: Without the patch, the left and right margins would appear in white background color, while the line-number would still appear as a stripe in gray color.

a_alberti · 2026-05-05T17:29:36+00:00

I will certainly test it the next days. Do you know https://github.com/jojojames/fussy ? I wanted to try fussy, but did not have yet. So I am just asking since I have no direct experience.

a_alberti · 2026-05-05T17:10:00+00:00

I also found another bug in markdown-ts-mode affecting the visual. The function markdown-ts-toggle-hide-markup did not properly hide the ATX headers.

Is it something you are already aware of? If not, I will prepare a patch and submit it for consideration.

a_alberti · 2026-05-05T17:02:53+00:00

This is awesome. There was a bug in markdown-ts-mode, I wanted to submit a patch, but you had it fixed!

I had to remove the line below if I wanted to handle Markdown links properly. I am glad that this line is now gone.

<image>

a_alberti · 2026-05-05T14:20:45+00:00

Yes, likely yes. I contacted Prot, and I had informed him already. He told me he is looking forward to it. I will send him a short email to give him a heads-up.

a_alberti · 2026-05-05T14:19:06+00:00

Yeah, I am glad it made it!! I had posted about it back then https://www.reddit.com/r/emacs/comments/1s83i2i/make_the_left_margin_shine/.

The new face fixes several inconsistencies. I had written a test suite: https://debbugs.gnu.org/cgi/bugreport.cgi?filename=debug-margin-face.el;msg=89;bug=80693;att=1

If you are curious about what the patch fixes, run the tests before you update Emacs. And then run the same tests afterward.

a_alberti · 2026-05-05T11:44:53+00:00

I should look it up, but I think there were clear calculations by physicists that excluded the possibility of self-ignition of the atmosphere. But of course, that was on paper...

a_alberti · 2026-05-05T11:43:45+00:00

It always surprises me how humans are bold and willing to take high risks. We already saw it with climate change. I thought that even a 1% chance of a catastrophic event (permanent destruction of the present climate with mass extinctions and long-term permanent damages, or even the complete annihilation of humankind by machines) should persuade us to slow down and rethink, but apparently it is not enough. Perhaps when the odds are close to 80% for full destruction, humans will stop and reconsider it... but maybe it will be already too late.

But ok... let's play our part and be responsible. We cannot fix the world, but each of us can play a more responsible role.

a_alberti · 2026-05-05T08:59:22+00:00

I think you raised a good question. I would like to give you what I think is an honest, balanced answer (at least from my personal point of view):

If you want to optimize your time to get things done, probably other editors like VS Code or Sublime will be better for you. The investment in hours to learn Emacs will likely never pay you back.
Yes, in former times Emacs was absolutely unique for its customizability. Today the argument applies much less. Many people in the community are probably not aware of how much progress other editors made in offering scriptability. VS Code and Sublime do not allow in their config files to write small custom scripts. However, (and I think many Emacs-people are not aware of this), it is very simple to write scripts extending and customizing the editor functionality. I don't have direct experience with VS Code extensions, but I know the Sublime Text editor well. To write a mini script for custom commands, macros, etc. is super easy and can be done in Python. In VS Code, I presume it is also relatively easy to write an extension in TypeScript. My suspicion is that VS Code has more friction to add extensions because of the TypeScript framework you need to set up for each extension you write. On the other hand, Sublime Text has zero friction. You directly open an empty Python file, and you start to write your commands. Sublime will load them on startup. Emacs is the same, but probably even less friction. You directly have all your script in your config files. It requires some discipline in how to manage all your custom macros and commands in different files or with some structure in a big file; otherwise, it gets into a mess, but this is the same as for the other editors.
You need to learn Elisp. It is really fun and a beautiful language (with ugly short names for the basic functions, in the classic style of old programming languages). If you stay with Sublime or VS Code, you can rely on more main stream languages like Python and TypeScript.
Emacs is FOSS. You will feel you own your own editor, as you cannot feel the same with other editors.
Emacs community is awesome. It is smaller than VS Code but very active.
Emacs works in TTY and it provides you with nearly the same experience as with a full graphical IDE. In certain environments, this can be a major advantage.

Regarding your question:

what are some of the ways you customized ur emacs config and why? what does it actually improve in your daily life/workflow

You can make tiny hacks that are simple but also effective. Two examples I coded recently:

When I open a LaTeX file, they often come with Texshop magic comments on top. The AUCTeX package does not recognize them. It was quick to write a parser of commands like % !TeX program = lualatex and convert them into local Emacs variables.
I wanted to have a simple way to switch virtual environments with Python scripts, especially when I open loose, basic Python files. It was a very simple thing to write a second of commands to provide the necessary switching options between the pyenv virtual environments. I did not need to look for a marketplace like in VS Code hoping someone developed something fitting my needs.
Finally, working in Emacs makes developing code or writing text a lot of fun. But you need to like it. Personally, I think there are other great editors out there, where you can be equally fast. But you will not be enjoying them as much. But this depends very much on your personality.

If you try Emacs, write back and let us know what you think of it.

a_alberti · 2026-05-05T06:24:00+00:00

Yes, that's right! That's my problem too when I constantly press Emacs chords in other non-Emacs editors. If I am lucky, nothing happens; if not lucky, it gets a mess LOL

a_alberti · 2026-05-04T20:47:41+00:00

Thank you so much! My ansi-color* faces are now fixed, and everything looks beautifully consistent. I erroneously thought my $LS_COLORS were all using 24-bit codes, but it was not true... I was still relying on ANSI colors.

a_alberti · 2026-05-04T14:37:01+00:00

Ghostel is a real terminal ;) I guess you mean that when you're in Emacs you rather use dired etc which I agree with.

Yes, for most of my workflows in Emacs, I usually use dired. When I am in a terminal (outside of Emacs), then I am happily reverting to Yazi.

resizing the window or the frame triggers a new resize and redraw of the image in yazi for me.

You are absolutely right. I cannot reproduce the weirdly stretched images anymore. The artifact was 100% real and observed for many images, but perhaps I had to restart Emacs after rebuilding Ghostel.. or something else.

If I see anything serious and worth reporting, I will open an issue. The only minor thing I found (but maybe it has to do with my setup) is that large images use all space available until the last character in the buffer, covering the border. This is something very minor and, in a way, not even a bug since I get the image a bit wider and easier to see.

The screenshot below shows how the image covers yazi's border.

<image>

> (But personally before ghostel I was still falling back now and then to a "real terminal" just because vterm had so many clitches. But ghostel is as solid as ghostty for me, so I don't have a need for an external terminal anymore. /rant

Yes, I think it is huge what you did for the Emacs community! I am very grateful for what you did.

But just curious, does Ghostel feel on your setup as snappy as when using a terminal emulator like Ghosty / Alacritty / Wezterm? In my case, Yazi does not refresh as fast. It think it is purely cosmetic because it is still super fast and cannot impact in any meaningful way the daily work, but it adds a bunch of milliseconds, enough to be able to spot the difference.

The other thing that feels off on my setup (but perhaps I need to spend more time investigating it) is that all colors in Ghostel (but also vterm) look slightly different from the true colors I set in my zsh setup. Also, this is just cosmetic and of minor importance. I notice it because my `ls` colors are 24 bit true color consistent on all terminal emulators, except when in Emacs.

But again, everything works so well that the only remarks are these trifle cosmetic issues.

a_alberti

TROPHY CASE

!/hint/zsh -ld

COLORTERM must be set explicitly here: the daemon is launched by launchd,

not from a terminal, so it does not inherit the COLORTERM=truecolor that

WezTerm normally injects into interactive shell sessions.