Around the 1990s the winner was vim.
Around the 2000s the winner was Eclipse.
Around the 2010s the winner was Sublime Text.
Around the 2015s the winner was Atom.
Now the winner is VS Code.
Who cares which editor will be the next winner? I just keep using #Emacs, esp. as none of all the winners can read my email (#mu4e) or be my window manager (#exwm) 🙂
I love #orgmode, but there is an idiosyncrasy in org-capture's that seems atrocious to me. Whenever I go to capture a note, the capture buffer deletes all windows that are open except one, and splits it so only that window and the org-capture window are visible. As far as I can tell this is the behavior regardless of what your settings for display-buffer are.
This seems to be because instead of respecting display-buffer settings it uses delete-other-windows to ignore them instead. I can advise it to ignore delete-other-windows, which is better, but it still undoes any changes I make to my window layout while the org-capture buffer is open. Secondly, it also doesn't restore #EXWM windows properly. I cannot fathom why the maintainers would ignore a user's display-buffer preferences.
This is bad enough that I'm thinking about abandoning org-roam, (and probably any other org-capture based workflows). I carefully curate my window layout so that I have the information needed available to me. Org-capture decides that it knows better, and leaves me with a highly inefficient workflow for accessing the information I need to make my note. I just don't understand the rationale here.
If anyone knows a workaround to this insanity, please let me know.
Going slightly crazy. I updated and built #Emacs from #git, which I hadn't done since last September. All kinds of weird behaviour. 🤔 In particular, I can no longer start up Emacs as my window manager (#exwm). Dies during initialization and --debug-init makes no difference. 😟 Serious debugging called for, I guess.
Luckily, I have #StumpWM as my backup and simply using Emacs full screen is almost as good as exwm... but not quite.
"Wayland and X.org are both part of freedesktop. Whatever maintenance is still happening on X.org is mostly being done by people who primarily work on Wayland. There isn't some kind of holy war going on between The Wayland Developers who want to kill X.org, and The X.org Developers who believe it is great and want to keep it. They're nearly all the same people, and they all want X.org to die."
@Anarcat
You'd expect from a heterogeneous group of hackers that one of the first applications to be ported to Wayland would have been #GNU#Emacs and #EXWM, right?
"First blocker for #Emacs becoming a #Wayland compositor is that Emacs and Wayland both have their own event loop, and you can't merge them too. But you don't have to merge them because you can just make Emacs speak Wayland. So, Emacs becomes a Wayland client, and there's an extra server Emacs is talking to."
No idea if anything happened to resolve these issuse since then?
One of the biggest life-savers on #emacs#exwm has been the command xrandr -s 0. This somehow refreshes things and causes my triple-monitors to wakeup in ways that -auto and -set do not. But I cannot find documentation on it ANYWHERE; I've checked the manpages, web search... nothing!
EDIT: just tried xrandr --help and saw that it is short for --size. I'm still not sure why it works such miracles, though...
I like that workflow as well. Using #EXWM with #Emacs made it pretty easy -- I just have a single tab per window, set my buffer name to the title of the X-window, and I'm able to fuzzy search using my completion framework.
Spent all evening getting #exwm working on my triple monitor setup. A few interesting challenges that together required understanding Xorg's historical issues with screens and displays etc. Tomorrow, keybindings! And autostarts. And maybe transparency...
@garjola@louis@ms I use #EXWM as well. Its level of "interference with Emacs key bindings" is actually a negative value since it extends Emacs window management functionality to all X windows. So instead of losing keys you get to use your Emacs keys in places where you couldn't otherwise.
And then you also get exwm-input-set-local-simulation-keys which pushes this even further.
I have one datapoint for a project I did follow after it left GNU: One year after leaving GNU Gnome broke my desktop so badly that I switched to #exwm (so that’s an example for getting worse after leaving GNU).
Im sticking to #exwm for the moment, as Im trying to stay inside Emacs as much as possible.
Given the evolution of #GuixHome it would be super to assess whether I should make the switch to a Guile flavour.
Im overdue rejigging my setup one way or another. Getting my configuration into GuixHome will be the way of resolving some niggles and giving the freedom to switch setups for these functionalities.
I recently found out⁰ that #Emacs#EXWM can be launched from within an until loop, so that the Emacs server can be killed without the X session to also be killed. Like this:
until emacs; do :; done
If Emacs terminates abnormally (e.g. if it gets killed), then the loop restarts it automatically. In case of normal termination, the loop simply exits (the colon is just shell speak to say "do nothing").
A game-changer for my EXWM setup! Thanks @elmord for the blog post.
To expand briefly on why this is a game-changer, for example, there are rare circumstances when Emacs freezes and a simple 'C-g' (from Emacs itself) or a 'kill -SIGUSR2 <emacs-pid>' (from another virtual terminal) won't unblock it.
Also, in my current GNU Guix setup, I don't seem to be able to refresh Emacs's load path after a new package has been installed. Restarting Emacs is a somewhat inelegant but effective work-around.
In both cases, it's good to know that a restart is possible with no collateral damage.
Using xcb.el I managed to recreate a X11 drawing demo with #elisp. This may or may not pave the way forward to faster graphics rendering programs in #Emacs...
I've started work on a simple game and will hopefully hand in something for #lispgamejam this time.
While hacking on a prototype with properly prefixed identifiers, I noticed that spawning just the window took 2.4s every time. I started debugging what took so long and eventually found accidentally quadratic code in the unmarshalling bits. PR is at https://github.com/ch11ng/xelb/pull/30 and may be of interest to #exwm users.
Now I'm debugging a font issue. Previously, I used a script turning the ASCII glyphs of the GNU Unifont .hex files into a char table and expanded each glyph into 8 times as many bytes to use the A8 format (alpha channel only, 8 bits). However, I realized that the font does not need 8 bits anyway (no anti-aliasing, only solid black/white pixels) and the A1 format would avoid the need for expansion. In theory at least, for some reason not a single glyph is drawn...