I’m still on i3 as it’s been convenient, but this:

this has all become very specialized over the past decade

resonates. I keep incrementally adding personal tweaks and hotkeys to my setup, and I have all my dotfiles in a repo so it’s persistent across installations.

One example was I made my headphone button pause/play videos with i3’s config:

bindsym XF86AudioPlay exec playerctl play-pause

But then I adopted a script to toggle mic mute on work Zoom meetings, so I combined it with the above - if I’m in a meeting it toggles mute, otherwise it play-pauses any current video. The script, for now:

#!/bin/bash
#
# Handler script for hitting mute on the headphone.
#

CURRENT=$(xdotool getwindowfocus)
ZOOM=$(xdotool search --limit 1 --name "Zoom Meeting")

if [[ -n "$ZOOM" ]]; then
    # if zoom is active, toggle mic mute
    xdotool windowactivate --sync ${ZOOM}
    xdotool key --clearmodifiers "alt+a"
    xdotool windowactivate --sync ${CURRENT}
else
    # otherwise do play/pause
    playerctl play-pause # will fail if no player found
fi

and of course I altered the i3 config to launch that script rather than playerctl directly.

Yeah. Heaviest awk I’ve ever done is extracting a value to a variable from a line with one pattern and using it to populate output from later lines matching another pattern.

Although I came from vi (pre-vim and pre-evil) and still have the muscle memory, I don’t and haven’t used it myself.

I hear it described as a “nearly complete” and “very comprehensive”. There is definitely a solid community of people using and enjoying it, but on the other hand there are always some reports of getting tired of having to work through, and sometimes extend, an additional interface layer, so in the long run being happier to just adopt the default bindings.

I know there are a few areas where trying to follow common vim workflows doesn’t work as well. Historically the performance of line number display been weak in Emacs, though I believe it’s recently much improved. A lot of people seem to make heavy and constant use of it in vim but conversely for me (and I think it’s more common in Emacs) it’s only an occasional, transient need when some external log or error quotes a line number, so I have them only displayed when I hit the go-to-line binding.

Overall, I think the most frustrating issues people have trying to adopt Emacs from vim are due to trying to impose their specific familiar vim workflows. The most obvious example is people concerned with startup time, but for more typical Emacs workflows it’s a non-issue. Users typically stay in Emacs rather than jumping in and out of it from a terminal (and if you really want that workflow, you run one instance as a daemon and pop up a new client to it instantly). My Emacs instance’s uptime usually matches my computer’s uptime.

The draw of Emacs is not about it only being an editor so much as a comprehensive and programmable text environment. It is a lisp-based text-processing engine that can run numerous applications, the primary being an editor (the default, or evil, or others…) but also countless other applications like file managers, VC clients, subprocess management and many others. It 95% replaces the terminal for me, and many other tools. So it’s the environment through which you view and manipulate all things text that is very accessible to modify and extend to fit your needs. Hence the joke about it being an OS is pretty apt, though to believe it needs a good editor implies vim isn’t a good editor ;).

Which Emacs community? I’ve been following it for ages in a few places (Reddit is the most common) and I literally do not encounter any of that. Calling it evil was humor - as if people who went to all the bother making it would be trying to push people away…

Using the evil package is very popular and often recommended, which means literally using it like vim, but with all the Emacs ability on top. I don’t know what on earth you’re talking about.

And yet Emacs users don’t fight vim users. Emacs users decided vim’s interface was pretty cool and added it to Emacs. Somehow people still call it a war though.

I have a similar approach but primarily in Emacs rather than a terminal. Tiling WMs — i3/Sway specifically — have definitely become home.

I’ve been through a bunch of tiling WMs after Ubuntu dropped Unity (where I had enjoyed some light pseudo-tiling but wanted more). I started with i3 but couldn’t shake the feeling it was kind of impure and slightly inelegant. But every other one I tried had more annoyances and weirdness and I came back to i3. To me, i3 it is to tiling WMs as Python is to programming languages - nagging feelings of impurity, limitations, and grubby corners, but in the end it is very practical and gets the job done well and has been refined over the years to round off its rough edges.

Recently with things like PaperWM I thought perhaps I could get the benefits of being closer to mainstream, but after trying to get comfortable I just could not and am back on i3 and will switch to Sway eventually.

I3’s model of workspaces per monitor, and semi-automatic tiling, semi-manual, and i3-msg, sometimes feels inelegant but is actually highly practical. You can add plugins like autotiling to automate more, and powerful scripting behavior attainable through i3-msg and Python bindings (I recommend if you start piping i3-msg output through jq to get info, just make the full jump to scripting in Python, it’s easier in the long run).

This really appealed to me too but I also want fixed workspace numbers and workspaces per monitor and paperwm shat itself on the former (Ubuntu, 22.04 and 24.04) and didn’t appear to offer the latter as far as I could tell, or anything I could manage to work reasonably with multiple monitors.

Perhaps I really just didn’t understand the intended workflow with workspaces and monitors but I couldn’t find anything coherent. It seemed like the only option was either only workspaces on one of the monitors, or move workspaces in lockstep across all monitors (more a Gnome failing than a PaperWM failing). Neither of which made sense to me. So I scuttled back to i3 again in the end.

No, it’s a shell feature. Terminal emulators don’t even know what shell are running typically, and I haven’t heard of them adding shell features. That would require the terminal emulator knowing you’re using bash, knowing how to interrogate history etc…

From man bash:

       yank-last-arg (M-., M-_)
              Insert  the last argument to the previous command (the last word
              of the previous history entry).  With a numeric argument, behave
              exactly  like  yank-nth-arg.   Successive calls to yank-last-arg
              move back through the history list, inserting the last word  (or
              the  word  specified  by the argument to the first call) of each
              line in turn.  Any numeric argument supplied to these successive
              calls  determines  the direction to move through the history.  A
              negative argument switches the  direction  through  the  history
              (back or forward).  The history expansion facilities are used to
              extract the last word, as if the "!$" history expansion had been
              specified.

Funny, in the US I just saw a car that was an “SS” model and I thought “Huh, apparently SS doesn’t immediately scream Nazis to Americans” (SS => Super Sport apparently, to Chevrolet)

Fewer keystrokes, more features, and the ability to see what you’re about to do explicitly. How does that make it the poor man’s option?

Sorry it’s not a very direct answer but this is one of the many things that make Emacs such a comfortable environment once you’re used to it, which takes … a while.

There is a man command and then of course it’s just more text displayed so you can search and narrow and highlight etc. in the same way you do with any other text. Plus of course there are a few trivial bonuses like links to other man pages being clickable.

It’s all text and Emacs is a text manipulation framework (that naturally includes some editors).

You don’t execute C source files. They have to be compiled.

First point as someone else commented, that driver is already present in any mainstream kernel. It’s very unlikely you have any need to build it.

But if you really want to build it the command will be make that will get instructions from Makefile on how to build the driver. But there will be other tools and libraries needed.

Same. I’m a little embarrassed that I have little idea what it’s like. Last one I used daily was Windows 7. But then I wonder

how convenient it all was and how was missing so many things

What are these things I’m missing?

I feel like this is well named (run as user 0) so then I’m wondering what else you dislike and what you think would be improvements?

What about a lightweight variant like Lubuntu or Xubuntu? 4Gb should be usable for a lot of things.

We can’t imagine anything but unfettered capitalism, so onward we go to our own destruction!

But our ignorant misconceptions are ubiquitous so they have become truth!

What problems with AMD Ryzen? I’ve been happy with them, except one that had excessive power drain on suspend.

My guess at the stance is I’d imagine it’s that switching away from snaps is switching away from Ubuntu’s support and security monitoring and updates to some less known/reliable/diligent third party?

Popey (Alan Pope) used to work for Canonical / Ubuntu, so he’s presumably not inclined to jump on the bandwagon of Canonical/Ubuntu/snap hate since he knows a lot of Canonical and Ubuntu people and their motivations and work. Not that there aren’t good reasons to criticize snap or other Canonical decisions, but it’s also plain that a lot of people just join a hate bandwagon and don’t even know what about it they object to. There is masses of wrong-headed criticism of Canonical out there e.g. I’ve frequently seen people criticize creating Upstart, saying Canonical should have used systemd, or bzr vs git! Presumably these people were annoyed at Canonical for not inventing a time machine.

Shush! Lennart might hear you!