Emacs is my new window manager
howardism.org
howardism.org
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
Being off by one column of keys on your keyboard can really be a death sentence to your buffer (and maybe even codebase).
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).
FWIW I'm also a big Emacs user.
FUD.
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.
[1] https://blog.invisiblethings.org/2011/04/23/linux-security-c...
[2] https://www.phoronix.com/news/X.Org-Maintenance-Mode-Quickly
[3] https://www.phoronix.com/news/NVIDIA-GBM-Works-With-Sway
[4] https://www.phoronix.com/news/Sway-1.7-rc2
[5] https://www.youtube.com/watch?v=Zsz7Shbnb9c
[6] https://blog.summercat.com/configuring-mixed-dpi-monitors-wi...
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".
Who? I’m sure you could easily prove it instead of relying on hearsay.
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).
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.
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.
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.
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.
sway --unsupported-gpu
https://github.com/swaywm/sway/blob/master/sway.desktop
This is what everyone is using and it is exactly as broken by default as I claimed.
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.
https://linux-hardware.org/?view=os_display_server
Almost 2/3 of people are still using X11 because as experienced by users Wayland is kind of shitty.
- 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...
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.
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?
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.
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.
Here is my setup, written in Fennel Lisp: peterhil/awesome-ultraviolet: Awesome WM theme with dark violet colours https://github.com/peterhil/awesome-ultraviolet
Peter Pan on Twitter: "@app4soft @probonopd @MX_Linux Screenshot of my #AwesomeWM setup. https://t.co/2XMnDEdJfN" / X https://twitter.com/peterhil/status/1463914949491761164/phot...
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.
There was a discussion here about it a few days ago [2].
[1] https://blogs.gnome.org/tbernard/2023/07/26/rethinking-windo...
Add Space Bar and you are close to e.g. i3.
/s
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.
https://ifdesign.com/en/winner-ranking/project/sparcstation-...
(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.)
Then you simply roll back to the working git commit of your emacs configuration or NixOS generation!
Yes! NixOS is perfect for the author's situation. But maybe his setup is so simple that a little bash script could work just fine.
(I test by starting a second emacs, so I can used the still-running first instance of emacs to fix the regressions.)
(mine certainly is, and I've also been using EXWM for 6-7 years or so, with few problems)
(Also, I think overengineering stuff like this is almost an outlet, which helps me stay pragmatic and goal-oriented at work)
also, this is specifically for a personal vm on a work machine, right?
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.
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.
Also, any pointers to the 80% attempts?
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.
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 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.
I used StumpWM for many years before EXWM and I don't see how the config situation is any different.
I have run into issues with the odd package, but nothing that has ruined my day.
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.
https://sawfish.tuxfamily.org/
Worth mentioning, it supports tiles [1] and tabs [2], but those were added after becoming independent from a famous desktop project.
1. https://github.com/SawfishWM/sawfish/tree/master/lisp/sawfis...
2. https://github.com/SawfishWM/sawfish/tree/master/lisp/sawfis...
- 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.
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.
Just log out and switch to your backup WM/DE.
HN is nothing if not helpful and well-adjusted.
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.
Emacs isn't a UNIX program at all, philosophically speaking.
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.
Ever since then, I've been printing out plane tickets...
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.
(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...)
"Nah, it's cool, bash doesn't exist yet."
"Cool."
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.
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.
Evil is definitely well worth it.
> This is somewhat frustrating especially w.r.t. certain LSPs and other niceties modern editing has afforded us.
Which LSP servers don't work with Emacs?
https://github.com/emacs-evil/evil
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.
Also, an ergonomic keyboard can help with pain; I had pains on my right wrist and using the Kinesis Advantage has helped me tremendously.
(e.e. cummings)
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.
zile is not Emacs in Lua, it's just a programmable text editor. It's not the same thing.
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 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)
His video on literate programming for DevOps via Emacs' Org-mode was very impressive and inspiring to me. It's my favorite. :)
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/
“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.
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/.
Some of the Devs I've worked with move so fast in these tools it's mind boggling!
I'm an old school Mac person... I mouse and click things :-)
Master the shortcuts and keyboard + mouse chords.
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
My ideal Emacs now should come with rich GUI panels with Emacs editing experience.
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.
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.
But I won't criticize other people's desktop environments, if it works for them, I wish them hours and hours of joy.
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 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.
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.
Apart from that, great experiment and fun idea.
There are good free ones too, but this one is still best IMO.
i’ve got firefox and webkit2gtk if i’m feeling fancy.
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.
maybe chatgpt can help setup your init.el.
it’s quite a good experience when tuned.
Shoehorning things into what they don’t want to be is something I only do behind compensation.
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.
Except when you want to use stylistic sets, is Emacs planning to support them in future releases or are they out of the discussion?
I ‘live’ frequently in mosh+tmux+Emacs but to be honest with as simple of a setup as possible.
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’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.
[1]: https://youtube.com/playlist?list=PLEoMzSkcN8oPH1au7H6B7bBJ4...
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.
> 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.
Modal editing with seamless emacs integration avoiding the need for evil-collection type packages.