Dont. Emacs is there to be tinkered with, and your cat will break it by simply looking at your keyboard.
I love Emacs. I develop for it, financially support it, live it everyday. The last thing you want is to be stuck debugging your failed desktop session on Tuesday morning at the airport as your wife waits for you to find the tickets.
If you love Lisp, give StumpWM a try. Simplicity, DWM. Simplicity with modularity? AwesomeWM just works.
Keep your Emacs config away from your system packages. The latter should prop up the former, not vice versa
Actually your wife might be happy to know that I have developed some nearly stable Emacs packages that interface with the Sabre system for airline reservations. The only drawback other than stability is that they require a SPARC workstation running a special variant of FreeBSD.
That’s why I have a SparcStation LX. Fits in the carryon for travel much better than a pizza box. Even easier to travel with now that I can use an LCD and don’t need to lug around the ‘ol Trinitron.
With an inverter and a car battery in my backpack I can even show a digital/ on screen boarding pass with a full 8 bits of color.
It was even more impressive if you were accustomed to a one-ton SPARCstation pizzabox with a hulking two-ton 21" CRT on top of it.
(There were soon third-party SPARCstations in normal laptop form factors, but then how would bystanders know you were using a SPARCstation. You might as well put a Ferrari in a Prius shell.)
I've been using EXWM since 2016 and this hasn't been a problem for me. Emacs doesn't just magically break on its own. And even if I managed to break my config without noticing it the fix is just a git revert away.
I used StumpWM for many years before EXWM and I don't see how the config situation is any different.
I have been using it since 2017 and I have no problems to report that were specific to EXWM. I also use EXWM on my work dev machhine and have set EXWM as the windows manager for my kids computers.I absolutely love it. If you want the best experience, I recommend compiling emacs >=29 and configure it for native lisp + tree-itter so that you can get the most from eglot.
I have run into issues with the odd package, but nothing that has ruined my day.
The ultimate Awesome setup has to be that used by Daniel Berg and Julian Assange in The Fifth Estate. Plenty of Lua and Python scrolling frantically but I don't remember seeing any Emacs.
When I got cachix set up in Github CI with my custom emacs package that pre-builds and compiles my configuration including packges, I was as giddy as when I started programming. It's over-the-top, unnecessary, overkill, and an absolute blast. Stuff like this is the reason why I've gotten into this whole thing.
(Also, I think overengineering stuff like this is almost an outlet, which helps me stay pragmatic and goal-oriented at work)
Cool. Can you show how you start an Emacs (i.e., what flags you use) to test whether init.el would load successfully next time an Emacs is started the normal way?
Same(-ish) here. Between git and emacs auto-save, I don't recall the last time my init file failed to load without being able to revert to a previous working version almost immediately.
I use AwesomeWM since forever, with about 12 virtual desktops/workspaces. Nice thing is: it's a tiling WM but I can still put some of the workspace in "floating" mode and they then behave not unlike windows on a regular desktop (which makes some programs happy).
The feature that keeps me is that same client can be tagged in multiple workspaces, and it just exists in different layouts. It's a little buggy in the 4.3 tree, but fixing focus issue in my config was easy enough, that's the cool thing about hackable software.
This feature is the one of the biggest reasons I haven't tried something like EXWM or StumpWM yet. I really like AwesomeWM but can't say the same about Lua.
I was working on fixing some of those bugs last weekend. Can you clarify which annoys you the most so I can add unit test later this evening? tl;dr; The main problem is that the z-index stack and client ordering list are global and this cause changes to one tag to affect another. I am moving those structure into per-tag trees rather than global stacks.
> client ordering list are global and this cause changes to one tag to affect another. I am moving those structure into per-tag trees rather than global stacks.
Yup that was exactly the problem and how I solved it too. If I remember correctly if workspace1 has client A and B, and workspace2 has client B and C (B is common), global stack means if I switch from 1 to 2 while focus was on A, while in 2 if I ever switch focus to B, then I when I come back to 1 I would find that focus moved from A to B, which can be annoying.
While I have you here, do you think 4.4 is still years away? Is there an ongoing documentation of API changes?
> While I have you here, do you think 4.4 is still years away?
I/we were never very fond of releases to be honest. All it does is to fragment the number of version in the various LTS distribution, which makes support a pain (vs "the official version" and "git-master"). Also, I don't have that much time these days, so getting a release out is impractical. I am aiming for the Ubuntu 24.04 cutoff for packages.
> Is there an ongoing documentation of API changes?
`git log` ;). But also, just compare the official release doc with the development one. There's over 1k changes. The largest one being the documentation itself. Then a rewrite of the notification and wallpaper APIs are also rather large improvements. Everything is backward compatible, so there should not be any nasty surprises.
> Yup that was exactly the problem and how I solved it too. If I remember correctly if workspace1 has client A and B, and workspace2 has client B and C (B is common), global stack means if I switch from 1 to 2 while focus was on A, while in 2 if I ever switch focus to B, then I when I come back to 1 I would find that focus moved from A to B, which can be annoying.
Annoying, but also like >10k lines of code/tests/doc to "fix". It will take a lot of effort to get this PR merged without behavior changes or regressions... That global stack goes back 15 years and everything depends on it's exact behavior. It's as ossified as it gets.
Even though I still use X11, my concern with AwesomeWM is there seems to be no path forward to Wayland, which will eventually eclipse X to the point that distros stop supporting it.
Distros (especially those based on Debian and Arch/AUR) package all sorts of weird obscure stuff, the chances of not packaging Xorg are kinda low.
And if some do drop it and you don't want to switch to a distro that still has it, you can always compile and install it from source, it isn't that much of an issue. If said distro has XWayland (which is much less likely to be removed) it'll already have most of the libraries available.
Wayland works fine. I have been using Sway for years now without issue. It is also more secure[1], maintained[2] and even works with NVIDIA's proprietary driver. [3][4].
It also isn't the antiquated piece of crap that X11[5] is, which has trouble with things like mixed DPI, and other modern features that Windows and macOS do completely fine without "tweaking" [6].
If Wayland did not exist I would not be using Linux on a desktop. The "screen tearing" with X11 when using a compositor was painful.
Mixed dpi works fine under X and tearing is trivial to avoid.
Meanwhile under every other Wayland compositor other than KDE apps using XWayland are at best an unusable blurry mess.
Kde alone actually handles high and low dpi monitors plus xwayland acceptably and at least under void it's Wayland session is buggy affair still.
As far as sway in addition to being useless for mixed DPI plus XWayland it silently fails to start with Nvidia hardware unless you pass special arguments and modify the kernel command line which just looks to normal people like totally broken. We are talking about the party with >80% of the discrete GPU market.
Then there is zoom screen sharing the fix to make it work with Wayland theoretically came out 4 days ago and is probably still a crap experience.
You will probably suggest getting rid of all XWayland using apps,Nvidia, and zoom but this isn't how people actually use platforms.
If something is supported and available it becomes part of people's expected workflow and people who get a frozen back screen don't throw away their workflow,convince their employers to drop zoom, or go shopping for a GPU they don't use the thing that makes their screen turn black.
Zero fucks are given regarding whose job it is to fix it or whose "fault" it is because nobody cares about plumbing they care about apps and hardware support.
The alternative is like picking an author based on his choice of word processor instead of his work.
People have been calling criticism of Wayland FUD for a decade. For most of that period the actual experience using existing hardware and apps has been pretty bad. The gap between proponents vision and users actual experience is especially large when user uses old stable software and proponents use very recent versions.
This means proponents have taught users they are full of shit and Wayland sucks. This will persist even when all issues are well addressed on versions of software actually used by the majority of people.
Nvidia should just support the goddamn kernel if it wants to have working software on top? Wayland hasn’t hardcoded AMD or whatever, it relies only on the standard kernel APIs for managing buffers for display. You know why your nvidia card works with Xorg? Because you use a proprietary binary patch inside your xserver for it..
Again no user should give even one fuck. Here is the user experience of installing an X11 environment. Install in package management GUI or CLI based on user preference. Log out. Click little icon on login screen select environment. Login.
Lets install say sway. When we click login it silently fails and returns to the login screen. Running it manually at a tty which a user will never do reveals that the dev wants users to pass an argument --unsupported-gpu to acknowledge that he isn't interested in bug reports from you even unrelated to nvidia. Instead of informing you of this the developer has from the perspective of the user just silently crashed and exited. If you decide to debug this you will run into other issues like an invisible mouse cursor this is solved by setting a variable in the environment.
From a user experience perspective this is complete nonsense. The arguments needed to start a functional environment were known from the start but users are required to each go on an online scavenger hunt to discover them.
Your not entitled to the developers time but the user experience I'm used to as a user is that projects take bug reports, and respond if they have time, fix them as time goes by when they can. My normal experience isn't that the dev will insert idealogically motivated crashes into my workflow and make me pass effectively --fuck-me-no-bug-reports-for-you-jerk. I'm not entitled to him running his project differently but I don't know why I would use anything from such a project.
> When we click login it silently fails and returns to the login screen
That’s just your distro of choice fucking up the packaging, or you having installed some special display manager that handles it bad. If anything, xserver is/was a huge pain in the ass to start properly, and sway will just properly startup from console N.
If you want a 100% works suckless experience, then linux is not for you, period.
Of note Wayland fans always say everyone who has trouble are all holding it wrong. Tail wagging the dog they suggest you should have switched DE, applications, GPU, workflows, everything users actually care about in order to serve something no user has ever cared about...plumbing.
If your not holding it wrong then something else MUST be at fault. Your distro must have fucked up the packaging, your app doesn't support wayland, your GPU's wayland support isn't up to snuff. Again users don't usually hire a programmer to figure out which piece of software is to "blame" nor care.
If you have a little red switch and you toggle it to the left and everything works and you toggle it to the right and nothing does most people are going to toggle it right. People have more important shit to do than figure out why toggling it left makes their lives suck.
Look at this exact example with you positing a wholly fictional distro packaging or display manager problem to paper over the fact that sway is literally designed to crash at the login screen if you use the GPU with >80% of the discrete market share.
Nope. In order to start sway while running the nvidia driver you must run
sway --unsupported-gpu
If you try to run it without that option it silently fails at any login screen. If you run it at the console you will note it TELLS you to run it with that option. This means the developer has detected what needs to be done to start a session and is silently telling you to go fuck yourself. There is no argument that every distro ought to exec a wrapper script that tests if you are running nvidia and if found pass --yes-I-understand-fuck-me-sideways when the net effect would be to replace the body of the if statement that already exists in the devlopers code and more to the point I don't think anyone has. You may note here is the default desktop file as provided by the project.
100% my experience as well ! a Few times a year I try to move to Wayland on my modest old Asus laptop with NVIDIA 950M chip.
Either I spend the day with black screens and weird fixes that I had to google on my phone. Or if Nvidia is working there is at least two other things broken, which never seems like an easy fix. Zoom, tearing, dpi etc.
I'm sure you experience are different than mine, but currently these are the problems I have with Wayland and the not have with Xorg.
One can say the same about your post being FUD against Xorg.
For example that first Phoronix post is about RedHat's official stance on Xorg support not about everyone else, other developers still work on it. In fact just a couple of months ago someone implemented tear-free mode in the modesetting driver which would address your issue with "screen tearing".
You can easily check that by looking the xserver commits, it isn't like they are hidden.
The TearFree stuff was added by Sultan Alsawaf who doesn't work at RedHat (though note that above i wrote that this is the official RedHat position, that doesn't mean people from RedHat cant still contribute to the xserver).
I just recently had to switch from a wayland WM (Hyprland) to an X11 due to numerous issues:
- Screen tearing galore (apparently documented but been awaiting a fix upstream for 2+ years)
- Inconsistent input lag across apps. Notably Electron apps, like discord, where the longer I type, the more input lag I experience.
- Blinking apps. When resizing/going fullscreen/refreshing, applications will show desktop wallpaper randomly.
I wish Wayland was more stable for me personally. I want a smooth lagless experience but using a Wayland ecosystem with Nvidia is not where I want it right now...
Read the article! This instance of Emacs runs in a VM he uses for accessing and editing his personal tech notes at work, to provide better separation from his work system. He's not risking much. :)
> morning at the airport as your wife waits for you to find the tickets.
Hah oh the flashbacks. I've literally done this. Except — ironically — I was keeping the tickets in the airline's app.
The airlines app, idiotically, needed the network to fetch the tickets. The airport's network was misconfigured, as many are: it had one of those idiotic "proxy all traffic to the captive portal"¹ things, so the airline app was confused about why its AJAXs weren't returning the right stuff. But in the moment (i.e., TSA) I wasn't grokking that the error from the app was a lie because the network was malicious.
Perhaps Emacs could have saved me…?
(What I do now is open the ticket beforehand and then screenshot it so that it's local. And we also bring paper fallbacks. Paper cannot have it's packets captured.)
¹There's a proper way to do captive portals. This ain't it.
How did "proxy all traffic to the captive portal" MITM the app? Does the app ignore HTTPS errors? Does the app send your PII in plaintext? Does the app not know what are the expected protocols and status code from it's own backend servers?
I once had a ticket on my phone. My phone overheated and crashed just before I reached the ticket checking station at the gate. It refused to start for several minutes, because it was still too hot.
Ever since then, I've been printing out plane tickets...
I used tiling window managers for years (I started with wmii, and I even used ESXM), but now I'm settled on Gnome: Everything works out of the box, and it's mostly keyboard driven. I don't know if there's a good argument for me now to return to tiling window managers.
> I love Emacs. I develop for it, financially support it, live it everyday. The last thing you want is to be stuck debugging your failed desktop session on Tuesday morning at the airport as your wife waits for you to find the tickets.
100%, what possible benefit is there in tightly integrating a bunch of things so if one of them fails the whole house of cards falls down :-), also good luck with having a system so custom you'll have to do all the debugging, patch writing yourself.
It's a "cool idea" but not one you should be doing in practice. I've never really gotten the emacs is "everything". I thought UNIX philosophy was to do one thing an do it well.
Yes you may be really clever and be able to do that, but there are only so many hours in a day.
> It's a "cool idea" but not one you should be doing in practice. I've never really gotten the emacs is "everything". I thought UNIX philosophy was to do one thing an do it well.
Emacs isn't a UNIX program at all, philosophically speaking.
I'm curious why you would be fumbling in your computer trying to find tickets.
I do find the plethora of window managers interesting. Is that same level of exploration going to exist in wayland? My understanding was that the job of a window manager is very different in that world.
> I'm curious why you would be fumbling in your computer trying to find tickets.
I mean, it's certainly a joke, but because jokes are always better explained (/s) it's because most airlines offer the option of paperless ticket emails these days, and if you don't have a smartphone, you'll have to bring up the image on a desktop so they can scan it at the gate.
Right, I mostly get that. I have literally never seen anyone use a computer at airport security. As such, the joke falls rather flat. Would be better on a story about using emacs on your phone?
I should have also said I meant my quip mostly in jest, as well. I don't actually question why they would be doing something I know they aren't actually ever doing. :D
- olwm/olvwm: virtual desktops and the 19" SPARCStation 2 monitor was absolutely amazing at the time
- fvwm, fvwm2
- sawmill/sawfish was my intro to programmable WMs. It was great until Gnome gobbled it up as its default WM eventually ruining it
- GWM I believe is actually older than then all of the above but I haven't discovered it until I was looking for an alternative for sawfish
- StumpWM was my introduction to tiling WMs and having a proper REPL to allow modifying it live. I don't think that GWM had a REPL but I might be wrong
- EXWM is where I've been for quite a while now. Folding X window management into Emacs buffer management was just as amazing as olvwm was back in the day.
Regarding Sawfish I know that development continued after the Gnome adventure and I could have stuck with it but "Gnome ruined it" is how I perceived it at the time. I can't remember what the specific issues were that made me look for alternatives.
The parent is just being ridiculous, Emacs of course has undo, auto-save and version control. And unlike in certain modal editors it's pretty hard to do any real damage without touching Control or Meta.
> The last thing you want is to be stuck debugging your failed desktop session on Tuesday morning at the airport as your wife waits for you to find the tickets.
From the point of view of tiling, Sway is an i3 clone for wayland.
For AwesomeWM as a programming sandbox WM, it is much tougher to get something identical. A lot of AwesomeWM work goes into APIs, CI and documentation. Making a scriptable WM using wlroot isn't the end of the world. Making one with mature APIs, backward compatibility, high test coverage, an active userbase large enough to sustain a plugin ecosystem and extensive documentation is much harder.
Making AwesomeWM 100% wayland compatible has been attempted a bunch of time, getting 80% working has been done a few time too, but the last 20% is like 95% of the effort or something and those projects keep stalling. From my side, I put the little free time I have for this into actually realistic features and maintenance work, at least until there's an actual reason to move away from X11. Most users at this point have been using it for years or even over a decade. They want their setup to keep working the next morning over #newshiny.
Thanks for the response, and thanks for all the effort towards an awesome WM :-) I can totally appreciate your priorities.
My use of Wayland (and for a lot of users , I suspect) is mostly just flowing with all the upstream distribution defaults. Do you expect the number of awesome-on-X users to dwindle or continue for the foreseeable future? My main concern with regards to switching to AwesomeWM would be whether I’ll be left stranded if the rest of the Linux ecosystem moves on.
> I’ll be left stranded if the rest of the Linux ecosystem moves on.
There is no such things. Unless they remove xorg from the repository, then it's just an entry in the session login screen as it always was.
> Also, any pointers to the 80% attempts?
Waycooler rewrite 2 and rewrite 3 are close enough. There's some private implementations that are more recent and more complete, but not released and probably wont ever be. Being a FLOSS maintainer these days isn't very enjoyable (disclaimer: opinions are my own), I can relate to their reticence to open the floodgates. There's one based on wlroot FFI floating around on Discord.
Then there's a bunch of doomed attempts by people who just made the same mistakes as the ones before them, but had too much ego/enthusiasm to acknowledge how it was going to end. The problem with Wayland is that it's hype-y. People who fall into the hype tend to fall into all the hyped techs at the same time. Which means shiny Rust frameworks and edgy code generators. Then all those things are dead a couple months later and whatever depends on them also die. The only way a working AwesomeWM Wayland port can be made is using boring old glib event loops and boring old service-client architecture of xorg. Anything else will not be compatible, so the plugins and existing configs wont work, thus nobody will use it even if it was somehow internally usable. People with a lot of time and grand ideas don't tend to like boring/mature/old techs and backward compatibility. I can't blame them either, why would they.
> your failed desktop session on Tuesday morning at the airport as your wife waits for you to find the tickets.
Does Richard M Stallman look someone who cares about your wife getting upset for missing the plane while you fiddle with Emacs? That use case of Emacs enabling you to browse the web (accessing the airline’s website which runs non-free software) and check-in so you can ride on an airplane(which also uses non-free software) is not something that in his goals for Emacs.
> The last thing you want is to be stuck debugging your failed desktop session on Tuesday morning at the airport as your wife waits for you to find the tickets.
They should be on your phone or you should use your credit card to print them at the airport. I'm sure there are other examples that make your point though. Yours reminded me of the furniture salesman selling a warranty on a couch by saying it'd cover the cost of getting the blood out, or even give you a replacement, should you sit on a scissors and cut your legs up.
On the original gnu machine (a Vax 750 that had been lying around unused) I made emacs my shell in /etc/passwd. The machine had BSD Unix on it and that was so unpleasant I preferred to go straight into emacs.
Nowadays of course, SVr4 Unix/Linux is the best you can get. How the mighty have fallen.
The /etc/passwd entry was actually a one-page trampoline that exec'ed emacs (as -emacs of course) or, if invoked under anything other than init, /bin/sh for the subprocess of emacs case -- bash hadn't been written yet.
Around the same decade I did a similar thing with an athena vaxstation under X; I noticed recently I still had the same hacks in my emacs startup to keep M-x shell from starting another emacs (I didn't use the trampoline trick, just literally chsh /bin/athena/emacs.)
Actually the Demo Center in E40 (I was working for Janet Murray on the Writing Project at the time.) I did eventually end up joining SIPB though.
(And then years later wrote enough of an XOpenDisplay in elisp - by porting the codegen for the perl version to generate elisp - though I never got much further, certainly not far enough for a WM. Amusingly I did find another elisp-X implementation, years later; since elisp doesn't have any native types, your choice of byteorder for the protocol was arbitrary, and we'd chosen opposite ones...)
I wish I had the enthusiasm, grit and dare I say "sisu" that lisp developers possess. I worked with a guy - very skilled Clojure developer - who was an absolute wizard in Emacs. If a car company sold a vehicle that was powered by emacs, he would have bought it. He will probably construct his own casket out of elisp to be buried in.
Emacs was not originally written in Lisp and is a great programmer's (and general) editor even if you never touch or think of Lisp. You can even write (and save and edit) keyboard macros knowing no programming at all.
When RMS got it, the Internet (this was pre-Web) started chattering about RSI (back when the Internet was relatively high signal, and altruistic). I'm pretty sure that early information about typing ergonomics, received when I was still a teen, is why today I can type all day and night without problem.
Coincidentally, around the time of Internet buzzing about it, almost my entire development team got hand pain, and some of them had to stop typing altogether. Only one of several of them used Emacs; the rest were Vi or Sun's simple mouse-based notepad.exe-like editor. (We all used Sun Type-4 keyboards and the optical mice, in our cubicle system with the lowered keyboard shelves, and decent chairs with lots of adjustability. I think something in there was more likely the cause.)
That said, Emacs definitely was one of the culprits for ergonomics problems, in that it encouraged multiple-simultaneous-keypresses (e.g., Ctrl-something, Alt-something), which is one of many possible contributors to typing injuries. But at the same time, Emacs back then could dramatically reduce the amount of keystrokes and mousing you had to do, compared to the alternatives, so IMHO the situation wasn't really "Emacs will blow out your hands".
It's maybe also worth noting that RMS and JWZ (and perhaps others mentioned?) were prolific super-programmers, so the sheer amount of typing is probably also a contributor. JWZ was also eventually at Netscape, where they were popularizing the whole dotcom gold rush sleep-under-your-desk culture. Which will secretly eat up your health, when you think you're being strong and powering through tons of grunt work (losing, when you think you're winning).
Poor ergonomics, stress, sleep deprivation, or trying to write an entire software ecosystem mostly by yourself, can cut your typing career short, and worse. Try not to do that, and not to let your colleagues inadvertently do that.
> That said, Emacs definitely was one of the culprits for ergonomics problems, in that it encouraged multiple-simultaneous-keypresses (e.g., Ctrl-something, Alt-something), which is one of many possible contributors to typing injuries. But at the same time, Emacs back then could dramatically reduce the amount of keystrokes and mousing you had to do, compared to the alternatives, so IMHO the situation wasn't really "Emacs will blow out your hands".
Having used emacs for a number of years and now switched off it for greener pastures I think it comes down to the key chords. Even if you start with the best intentions you will inevitably end up with hair-brained chord schemes for what you need to do. Emacs is a fantastic editor, vim is vastly more ergonomic. Maybe I should try DOOM emacs or evil mode raw and see how it holds up. I am not a huge fan of having to switch to something like vscodium especially given I spent a long time configuring Emacs perfectly. But my hands are thanking me.
Editor technology has advanced significantly. Aside from ergonomics the underlying architecture of emacs seems very resistant to change. This is somewhat frustrating especially w.r.t. certain LSPs and other niceties modern editing has afforded us. Unfortunately there's nothing like it if you're a fan of LISP-likes.
It gives you comprehensive Vim bindings so what you need to learn to be comfortable in Emacs is very little. As a bonus, it also keeps your RSI risk unchanged.
zile is an attempt to create an equivalent to GNU Emacs using Lua instead of Lisp. There was an attempt to merge the GNU Guile engine into emacs to replace the elisp bytecode VM; Guile would have supported, in addition to elisp, Scheme and Javascript. But last I heard the project had stagnated or fizzled out entirely.
One might argue that VS Code is using Javascript in a similar manner to Emacs using elisp, but ... it just doesn't feel the same to me. I have very little experience with VS Code, though, so I might be mistaken.
While I do love me some Lisp, I don't think it's a categorical requirement to get an emacs-like experience. Lua is a very nice language, very dynamic, built around a few powerful primitives, that it should be possible to get something equally useful eventually. It just would be an insane amount of work. GNU Emacs has been going for nearly 40 years now, with lots and lots of contributors over time. Simply building something that is equivalent in terms of features would take forever; and I think the zile people have much less brainshare than Emacs.
So I think it should be possible theoretically, but in practice, it's a lost cause. Guile Emacs would have been cool because it could have kept on using the tons and tons of elisp code that exist now, but apparently the pressure to get that to work was not large enough to warrant the effort. And with emacs now supporting native compilation of elisp, it's likely to stay the gold standard for the foreseeable future.
The only thing missing from emacs taking over my life like this is a simple to connect to remote emacs server. I want to have my perfect config live on some server somewhere and then connect to the with my local emacs client, and then maybe tramp back if I need to deal with something local. Seems like it should be simple enough but I still haven't managed it.
It’s quite easy to have non trivial, reproducible configs on a single file nowadays (ex using straight/use-package).
The rare times I needed to use emacs on a remote server with my config my full blow setup is a copy/paste, or curl call away.
For an emacs-inspired actual WM, I highly recommend looking into stumpwm. It became my preferred daily driver even as someone who spent maybe an accumulated hour or two in emacs over my lifetime (that is to say, I'm very much not an emacs person). It's been developed for ~10y, hit 1.0 in 2017, and is still actively developed.
The OP mentions ratpoison already. ratpoison (or cage for Wayland) is great for those situations where I just want a quick-and-dirty OoB minimal WM without needing to tweak or install anything else. stump gives you groups(workspaces) and a powerful language and environment so you can customize and optimize everything as you like.
They especially shine when you have nested environments (say opening a virt-manager window where you're remote-Xing in to another host where...). It becomes like tmux for X. No more resolving conflicting keybindings - you just have your prefix key to think about. Just like when a tmux-inside-tmux-over-ssh, navigating between different layers becomes second nature.
(BTW OP is (2015) and their referred 2wm seems to be dead and gone now)
Emacs nuts (I used to be one) can also combine Emacs with a no-decorations tiling window manager (e.g., Xmonad, which I currently use, or i3wm).
That lets them do all their "Emacs is my operating system" stuff, but still gracefully degrade to non-Emacs windows when necessary.
BTW, one time I was doing that, I used a minibuffer frame, shared among multiple frames, and wrote a tweak to help: https://www.neilvandyke.org/perkymbf/
That's a great approach. I used xmonad for a while and switched to i3wm recently. At work, where I have to use mac, I replicated my i3 setup using yabai + skxd - that plus Emacs makes using osX almost bearable.
Honestly, my comment was going to be that this is the most emacs thing I’ve seen today, especially with other users, chiming in with 17 different options he could try.
“I spend more time customizing my computer than using it."
>As a result, one of the most amazing pieces of literature to come out of the X Consortium is the “Inter Client Communication Conventions Manual,” more fondly known as the “ICCCM”, “Ice Cubed,” or “I39L” (short for “I, 39 letters, L”). It describes protocols that X clients must use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late — by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.
>The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn’t work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It’s so difficult, that many of the benefits just aren’t worth the hassle of compliance. And when one program doesn’t comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.
>In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry’s standard naked emperor.
I thought this was going to be some development news with Wayland compositing going further: https://emacsconf.org/2022/talks/wayland/. Maybe it's because 29.1 was on my mind with the full Wayland client support being released.
If you want to just run one application in a modern way (yes, I'm assuming you agree that Wayland is desirable), then check out https://www.hjdskes.nl/projects/cage/.
I'm fairly quick with Emacs... But these days VS Code is so good I don't really miss it. Command palette kind of feels like M-x
Sometimes I feel like I'm too quick that Emacs is trying to catch up, that's the problem. Emacs native compilation made things a lot faster, but I reckon VS Code out of the box plus some extensions makes it a much better value proposition. It's difficult to go back to grepping when VSCode let's you see your regex results _on the fly_
I still use Emacs for Magit. I would pay for a Magit for VSCode implementation
consult-grep (and it’s variants using git or rg etc) let you do that, with results as you type in mini buffer, with full live previews in a separate buffer (if you want). With an extra keystroke you can export all the results in a buffer and edit/save them in place too.
thanks for recommending! Looks similar to what I'm looking for. Tbh even if it works as advertised it's hard to go back after getting used to richer views.
My ideal Emacs now should come with rich GUI panels with Emacs editing experience.
Yeah it’s quite personal at this point.
I have used both but I am way more efficient with emacs. I also find the investment in emacs pays back more over time. Generally I also find emacs a lot more snappy.
But that’s just me, and to be fair I have used emacs since the mid 90s and vscode only for half a year.
The past few years emacs developement/experience also improved massively.
It’s good to have choices ultimately and they both pulled good ideas from each other.
Speed is one thing, but satisfaction is the real value.
This is also why I type with a non-standard layout (Workman) on a non-standard ergonomic keyboard (Keyboardio Model 01). It's comfortable and functional, but above all, is satisfying.
Unfortunately, the change in keyboard broke Vim for me: at its core, vi's functionality is made out of its keybinds. You can remap them, but you can't reconceptualize them. Emacs has about half of this problem.
As much as I love emacs, that is too spartan for me. I would at least run OpenBox, it is lightweight and unobtrusive. That way I could still run emacs in full screen mode, and escape to a web browser gracefully if needed. I am not that much of a minimalist.
But I won't criticize other people's desktop environments, if it works for them, I wish them hours and hours of joy.
There are multiple indications that this was written in 2015, yet the advice seems new. The timelessness of elisp/lisp and the emacs ecosystem.
I actually did the same thing a couple years back on a system where an Arch Linux upgrade resulted in my Xmonad packages being broken beyond repair. "emacs only" wasn't what I was used to but I was impressed with how much utility I got out of just emacs and no window manager. With some of the author's tips, I could probably do the same. Though a lot of my work forces me into using a "real" web browser (with JS and the kitchen sink).
I've been using EXWM (Emacs X Window Manager) for over 6 years now and can't go back.
- I have _one_ window manager for my files, browser, and terminals.
- Everything is keyboard driven with a centrally managed set of hotkeys.
- Everything integrates with everything else. It's the convenience of an IDE without ever having to leave it.
- Because it's lisp based, every aspect of my environment can be inspected, debugged, and modified at runtime.
Of course, some recent advancements in Emacs really help here:
- LSP support means it's no longer a "second class" IDE/editor.
- Native compilation of Elisp means it's much snappier.
> Whenever a page doesn’t render well (can you say JavaScript)
I mean, yeah, emacs doesn't have a modern browser engine in it. I wouldn't recommend it for that use case and of course you'll have to "shell out" to a modern browser engine to handle that. Now, if emacs could somehow provide an X render target and let the browser process bind to it as the window, that would be kind of awesome and I could totally see kicking my window manager overboard and just switching to emacs. But the web just "looks wrong" text-only these days.
Yes, that's possible. You can set any X11 window as a child of another X11 window, the parent window will be responsible to manage (taking care of window geometry and what not) child windows.
The learning and configuration curves are too steep for the time I have available. Too lazy to give a try to other CLI window managers. As a tmux user, am I missing something?
emacs as a terminal has surprisingly good latency [0] but I'm pretty careless with my pipes and frequently overwhelm the buffer with verbose output. Waiting seconds for a ctrl-c to take so I can fix my mistake is painful. Any magical incantations (long line tweaks?) that help with this?
apropos of emacs as WM: with the config kludge I've made and frequent REPL spamming, I've found `killall -SIGUSR2 emacs` essential to get back the editor.
I tried to use Emacs for that for a while, but whether it's ansi-term or eshell it always felt a little kludgy. There's always this mental exercise of having to switch between char and line mode. I hate that I could accidentally delete characters in stdout sometimes and then something just breaks in my head for me.
I decided to finally give tmux a break and experiment with other terminal emulators lately, after enjoying living in tmux for a long time. I started playing with kitty first, which I'm still using. But more recently I've decided to try making more use of vterm, and so far I like it a lot!
It’s crazy to me, after I stopped being a teenager, to spend almost any time customizing my computer to this point. I used to tweak every screw but when I started working I did the bare minimum to get by and be productive.
Shoehorning things into what they don’t want to be is something I only do behind compensation.
I used tweak my computer like crazy as a teenager as well for fun and then when I entered the workforce.
Now I've started to work part time and so I have a lot more free time and energy which made me pick this up again. It's been a lot of fun and I learn so many things that I then bring into my work. I've switched back to linux from os x and stopped using vscode to instead use emacs.
That's, to me, the best form of an OS, linux gives me the ability to shrink my desktop resource usage to a _strict_ minimum, removing all the distractions, so I can focus on the task
Nice, up to the point where he can only open a transient (JavaScript enabled) web browser. These days, I need a persistent web browser as well as an Emacs.
yikes. People really think i3 or sway or other tiling wm's are "heavy"?
That being said I love the idea of living in my editor. That's all i do on i3 anyway with neovim.
How is the stability? If you open a huge file in emacs or something since emacs is your graphical session and it blows up the whole ui and everything goes down too?
this + emacs + evil mode might be fun for me a vim diehard to try.
I loved every minute of my neovim + i3 setup on Arch. Was sad to let that go when I moved into Apple’s ecosystem (their laptop hardware is too good).
I’ve begun switching my to Emacs + evil mode and I thoroughly enjoy it, it fulfills this ‘customization’ gap I’ve wanted for years.
If you want to just jump in and try out Emacs, use Doom Emacs. If you want to go on the journey of making your own config, take a look at “Emacs from Scratch” [1]. It’s been great for me so far.
Your journey to Apple's ecosystem makes sense. Their build quality is amazing. It's the software (MacOS) I can't stand granted I am all-in on everything Apple on other things (phone, watch, tv, ipad, airtags, etc).
I3 is what brought me to Linux. A true, proper, no-compromises tiling window manager is the killer feature. I didn't go to FreeBSD (given how much I love ZFS) because of containers/docker/podman (and how native fast container stuff is on Linux given it's just abstractions over things in the kernel ... yes yes BSDs have jails but we don't use BSD at work so...) and gaming on Linux (thank you Valve! and wine and proton folks).
Re Emacs every few months I try to dabble but the vi/vim muscle memory is just so so so hard to break. That being said for neovim I use AstroNvim. It's been dope.
This was posted by someone else in the thread, but SystemE is close to that dream [1]. There is also this HN thread [2] with more interesting links:
> Using the tooling in this repo, I am able to boot from linux to sinit as PID1, and from there to Emacs acting as PID2 using --script mode, performing all typical rc.boot system initialization using Emacs lisp until we hit the getty.
I love Emacs. I develop for it, financially support it, live it everyday. The last thing you want is to be stuck debugging your failed desktop session on Tuesday morning at the airport as your wife waits for you to find the tickets.
If you love Lisp, give StumpWM a try. Simplicity, DWM. Simplicity with modularity? AwesomeWM just works.
Keep your Emacs config away from your system packages. The latter should prop up the former, not vice versa