Emacs is special regarding UIs
lists.gnu.org
lists.gnu.org
I feel that I am constantly being forced into new "UI paradigms", and it isn't always a change for the better. I started with DOS (Norton Commander, anyone? to this day there is no comparable tool), then Windows 3.0 and 3.1 (which was mostly garbage and I did not enjoy the UI at all). I then started using Linux and discovered Emacs. When I could afford the extra megabytes of memory, I would also run X11. As years went by, I switched to the Mac.
These days I'm worried about what will be taken away from me, especially with Apple and their insistence on removing ports, the idiotic "Touch Bar" instead of function keys — but also with Linux, where the shift away from X11 means no more remote applications, and the (increasingly broken) approach of gluing everything together into a big mudball means that if you're running anything that isn't "mainstream", things break and you are very much on your own.
But I still have Emacs and I'm fairly confident that it will remain available and running on every platform I decide to switch to. And that I will be able to run it (with reduced functionality) on a text terminal.
Directory Opus. I've used it for nearly 30 years. First thing I install on Windows.
No, you are doing it wrong. Never need to see keyboard except when using touchbar thanks to no feedback.
no
And in line with the other commenters, my corporate HP and Dell laptop function keys aren't grouped. Fortunately, I interact with both through a nice external keyboard.
As an example, these days, when routing PCB tracks in KiCad, when I need to switch to a different board layer, I need to look away from screen and at the keyboard in order to hit the right function key. I also have to pray that the TouchBar will register my press, as it often likes to go to "sleep". I don't know if it did register my press until I look back at my screen and check if I'm on the right layer.
Having to look away from the screen when you're in the middle of routing a track on a complex multi-layer board is really annoying.
Plus, it's difficult to keep a hand near the function keys without accidentally getting near one of the touchbar areas, which results in a keypress, which results in a zoom-out for me (F1).
It's an abysmal user experience and a huge regression.
I was not using pulse or systemd until early this year, having used Linux since 2008 thats a pretty decent lifespan. It was finally required for Bluetooth headphones which weren’t really around in the age of alsa.
Until wayland has decent performance though I don’t think I’ll ever switch. None of the apps I use are native (except possibly Firefox and some EDA tools but only if gtk is set up right?)
I thought my new phone would change my mind but surprisingly wayland is way way slower than X11 on it (running native gtk apps.)
Do keep in mind though that modern X11 doesn’t really do remote applications either and many aren’t letting the server manage the scene graph /widgets anyway so remote rendering would be very slow.
https://www.phoronix.com/scan.php?page=news_item&px=Microsof...
I'm all for that, if and only if Wayland doesn't force me to give up what I consider to be important features of X.
Apart from the aforementioned remote access, a post titled "Why I'm not going to switch to Wayland yet"[1] goes in to some requirements that I also find important:
- Programmatic output configuration (xrandr, arandr, etc.)
- CLI clipboard access (xsel, xclip)
- Third party app launcher/window switcher (rofi, dmenu, albert, docky).
- Clipboard managers (parcellite, klipper, Gpaste, clipman, etc.)
- Third party screen shot/capture/share (shutter, OBS, ffmpeg, import, peek, scrot, VNC, etc.)
- Color picker (gpick, gcolor3, kcolorchooser)
- xdotool
That post is a couple of years old now, and I've been told in other HN threads on Wayland that some of this stuff is being worked on now, but until it's all there and it is actually mature and full-featured, I would not willingly switch to Wayland.
[1] - https://old.reddit.com/r/wayland/comments/85q78y/why_im_not_...
No, most Wayland compositors can already skip composition and pass the window contents directly to the screen in case of displaying just a single fullscreen window. There is also work ongoing on utilizing hardware planes when possible, to skip composition and improve performance in other cases as well - going beyond what was ever possible on X. Grandparent comment is simply wrong.
In comparison X11 doesn't assume a compositor - it can support composition, but doesn't require it. If there isn't a compositor, applications draw directly to the framebuffer and content appears as long as it is sent to the GPU (you may even send stuff faster than the monitor can keep up with - this is how you get tearing for example).
You can work around Wayland's limitation the same way you can work around it in Windows: get a monitor with faster refresh rates. As usual, better hardware is what fills the holes created by shoddy software (i got an expensive 165Hz monitor expecting to have a never-seen-before butter smooth experience on Windows - in reality what i got was more or less the experience i had back when i could disable the compositor in Windows 7).
I'm hardly a Wayland expert though, I was just commenting regarding my own anecdotal experience.
Yes but sometimes you really need that and it's a life saver.
EDIT: I just remembered about LTSP (Linux Terminal Server Project) which many schools used to lower the TCO of computing infrastructure. That relied heavily on Xorg's network transparency. I wonder what will happen to LTSP
MacOS doesn't use it, Windows doesn't use it. Even Linux is moving away from it. That's pretty damning for X as a technology during a time when even Windows has started to offer native curl and ssh, just saying.
Ubiquitous networking is common in the Unix world, but much less prevalent in the Microsoft and Apple worlds.
At least anecdotally, I'm not sure I can find a whole lot of supporting evidence for this -- the vast majority of the commercial applications I use on a daily basis let you install them on any compatible system that you own. This isn't just a byproduct of "well, they're not checking"; it's usually explicitly written in the license, it happens with programs that make you enter license codes they validate before running, and notably, it's very explicitly the model of the Mac App Store. Sometimes the license says only one copy of the program can be in use at a time without a site license, but for individual use that's generally fine in practice. (I haven't seen a program that's actually annoying enough to check for running copies of itself on a LAN and shut down if you're violating the license in decades at this point, although I'm sure they're still lurking out there in weird niches. It sounds like something Autodesk software would do.)
Anyway -- maybe running programs remotely using the Xserver model never took off in the Mac world, even after OS X, because there was no prohibition against just installing the software on multiple machines? In practice, it's not something I've missed very often, I admit; while I sometimes like to edit text files remotely, that's not something that feels like it would really be improved by this model over using a local editor that can open files over the network. (Edited to note that I'm not suggesting there aren't still valid use cases for X11's server/client model! They're just not ones that have impacted me; if they did, I'd run XQuartz, which I don't love, but it'd probably get the job done.)
I believe that latter condition is actually true for Microsoft 365 Personal[1], too -- it's tied to your Microsoft account, and the one "seat" you're buying is that user, regardless of the number of devices you have. Business editions tend to be licensed differently.
[1] I know that looks like I got the name wrong, but apparently in April they changed "Office 365" to "Microsoft 365."
Individual use (there's a funny story here) doesn't really matter; what matters is groups, corporations, with tens to tens of thousands of users, and yes, Autodesk is an example (and GitLab (https://about.gitlab.com/pricing/), sort of). Things that make X necessary and useful are typically, something that you absolutely need, that requires custom support and big hardware, but not something that everyone on your staff needs all the time.
Funny story: At one point, a security researcher realized you could run a program through an instruction-level compiler, reordering operations without changing behavior, so that the machine running the program would broadcast RF signals containing the program's license number. It wouldn't really do anything for single machines because the signal was too weak, but if everyone at a company were using the same license for program X, you could drive around the neighborhood with a van and pick that fact up clearly.
Microsoft was completely uninterested. If it would not prevent every individual from pirating even one copy, they didn't care. Which may be why I recently typed in a twenty-odd character string into my new gaming machine.
No. :) I tried to be clear that I was thinking about individual licenses rather than site licenses, but might not have been, and you're absolutely right about corporate site licenses. Apple's App Store is designed for handling individual licenses -- they're tied to Apple accounts, not machines. (With the asterisk that this isn't necessarily true for iOS devices which can be managed by your company, and there's a whole different way of managing those, but companies I've worked for haven't used those.)
I'm not sure I knew Microsoft was still requiring license keys like that for Windows, but I suppose I shouldn't be surprised.
That you can't just launch that on every machine you want (in particular non server installs) is more a limitation of Microsoft's licensing model than of the protocol itself.
For me, from a usability point of view, RDP runs circles around the other solutions. I've used this fairly often during the lockdowns and even over a shitty DSL connection there was close to no lag.
In windowed mode, I can either have scrollbars to view a subsection, or I can scale the window. Doing the right thing, changing the size of the remote desktop when the local window is resized, isn't an option because that is set at connection time.
Sometimes, for firewall reasons, I need to have needed RDP sessions. At this point, everything performs poorly, and I need to drag the overlayed blue bars off of each other, then interact with one or the other.
I miss SSH, and want better support for it. Nested connections can be handled with SSH tunnels. Text connections are fast enough to do anything on the slowest of connections. If I need a GUI, I can open up a single window through X11, without additional setup with RemoteApp. Windows remote management through RDP is slow, clunky, error-prone, and inflexible by comparison.
For your "nested session", the problem is that the adaptive nature of the protocol breaks down if the first hop has a very good connection to the destination. However, you're holding^w using it wrong. In this kind of scenario, I think MS recommends using a remote desktop gateway, which also works very well. I think one of the great advantages of RDP over ssh X forwarding is that it can use UDP.
I definitely dislike how you have to have a Windows server installation and specific license to set up remote app, though. But I've filed this under "it's Microsoft, what can you expect?".
I also find windows administration horrible, be it via remote desktop or keyboard plugged directly in the server. I grew up with Linux and macOS, so it was always a pain when I absolutely had to give someone a hand with something windows-related (my client has a bunch of Windows servers).
But still, I'm not the kind to throw away the baby with the bathwater and to think that if I generally dislike and would avoid a company's products every single thing that they do is bad. I really wish Linux could have something similar to RDP in performance. It makes me sad when I vnc to a computer across the room and the thing lags more than RDP to some windows box in another country.
edit: Regarding your having to work with several RDP sessions at the same time, it baffles me that the worst RDP client I have ever used is the windows one. I don't use windows on my machines, and the Linux client (Remmina) is absolutely a dream, especially when running on i3 (so there's no conflict with win / alt-tab / etc). Also, MS's mac client works very well and there's no key conflicts there either. You may want to look into the new Remote Desktop app on windows (not quite sure what it's called, it's on the windows store). It now supports window resizing and easier switching between sessions.
Side note: if the server is running Windows 8.1 or later (or the equivalent server versions, Server 2012 R2 or later), this isn't the case any more-- RDP sessions can be resized freely at any time.
Naturally, the built-in RDP client that comes with Windows doesn't support this (because, of course, why would it?), but the UWP Remote Desktop app in the Windows Store does (as does the current Mac client).
The catch is that the UI to configure RemoteApp isn't present on client versions of Windows. It can be configured manually (by editing the registry then creating RDP files by hand), or there are open source tools that will do the work themselves: https://github.com/kimmknight/remoteapptool
Somewhat outdated Microsoft docs on how to do this by hand: https://techcommunity.microsoft.com/t5/microsoft-security-an...
https://techcommunity.microsoft.com/t5/microsoft-security-an...
if windows was enough for my needs I'd use it ?
The same sort of thing can be said for Remote Desktop. If you're using a version of Windows that includes it, it is wonderful to use because it is just there.
Which is better? It depends on how you're using it. I generally prefer Remote Desktop for my use case because it takes care of audio and it is easy to resume sessions. That being said, those features don't matter to me most of the time so X is just as useful.
How all of this works on the backend is a combination of PipeWire to multiplex video sources and PulseAudio to multiplex audio sources.
There's nothing outright preventing something like X forwarding and https://mstoeckl.com/notes/gsoc/blog.html is a really cool project that makes it work.
From that author:
> The main difficulty in producing such a tool is that Wayland protocol messages primarily include control information, and the large data transfers of graphical applications are implemented through shared memory. waypipe must then identify and serialize changes to the shared memory buffers into messages to be transferred over a socket.
Seems like such a fundamental use case that should be made simple but is ignored (or made very difficult) by modern systems.
https://wiki.gnome.org/Projects/Mutter/RemoteDesktop
https://docs.kde.org/trunk5/en/kdenetwork/krfb/krfb-configur...
You most likely won't see an implementation "for Wayland" because that's like asking for a websocket implementation "for HTTP" the actual compositors that speak Wayland need to implement remote desktop capabilities and then expose an API for managing remote desktop sessions (org.freedesktop.portal.RemoteDesktop) to programs that want to leverage it.
Doesn't every Windows include it? I can't remember the last time I used a version of Windows that didn't have it, it must have been 20 years ago.
Which is why the people who need this functionality run Linux, not Windows.
You can run an X server on Windows, there's a bunch to choose from. That lets you run an application on a remote unix system and show it on a Windows system in front of the user. It might be nice to run an application on a remote windows system, but that's always tied to expensive licenses; some of those systems sound like they could be pretty seamless (at least as seamless as remote X), but I don't have experience with them.
Remote X has its problems, but it enables a lot of use cases with a minimum amount of hassle. Connect, run the application, close it when you're done. Other solutions with a remote desktop require starting that session somehow, and either leaving it running or shutting it down somehow. That can be useful if you want a long running session, but is more hassle if you don't.
Visual Studio Code has "Remote Development" (which is under a Non-Open Source License(!)) because they don't have "X11 Forwarding".
Think about the waste of implementing that code--in every application--rather than being able to do display forwarding.
Sure, one could use a remote desktop to do same thing, but it's a bit annoying if all you want is one window from the remote machine.
You should try xrdp. It can work like X forwarding (single application window forwarding), but you can also attach or detach from a running application (like screen or tmux for X).
Right now the workflow is simply ssh -X machine and then run some scripts that may or may not open interactive windows and then look at the result files using some graphical application. The same as if I was running it locally really (except on a beefy machine)..
I suppose that you could start a terminal session on the remote machine and spawn GUI applications from that. I'm not sure if xpra allows for a terminal session directly from the command line though.
Also, is this "sildur" of Minecraft shader fame? If so, much thanks, you've given me and my daughter many instances of "ooh pretty look at our house."
I don't want to speak for anyone in particular but X11 was definitely not a friend to people who cared about a11y or l10n. It wore its origins in "80s MIT students" on its sleeve, for good and bad - and for non-English-speaking or disabled people, mostly bad.
Anyways, replace wheelchair users with pregnant women, or old people. Ramps help them too, and the argument is still valid.
With love, The Chrome Team
Google continues the war against its own users.
Yes, I had that conversation with a friend.
Great. Which of those, if any, do you think might be installed on the machines I want access to?
Which of those, if any, do you think might be installed on the machines I want access from?
What do you think are the odds that the intersection of those is non-empty?
You have absolutely no basis for thinking this.
In most cases this could be solved with a good web user interface, but you can rest assured X won’t be dead in the next 5-15 years, and you can use an intermediary box w/VNC if security is that much of a concern.
Granted there is also sixel and tek4014 support in xterm, but they are quite limited in what they can do and not too many applications have display frontends for that.
X11 forwarding works with the latest Linux distros as well a 20+ year old systems running motif apps. Note: the old systems are now virtualized but we still need them, I work in the aeronautic industry and these are the time scales we are working with.
I don't know of any replacement, at least not one with that level of adoption. Again, we really want to run graphical applications on a server, not a remote desktop.
And BTW, things are getting troublesome. More and more Linux apps integrate accelerated web browser components and these tend not to play well with X11 forwarding.
Love the irony of using a remote display to show an Electron app BTW.
We also have a homemade documentation system, again outdated but certified. I don't remember the system but it is definitely not a modern Linux. I think there is also a Fortran tool used to compute the lifespan of parts on the same system.
A bit more recent, we have test benches made of several computers, mostly Linux desktops, each one deal with different things like real or simulated avionic hardware, they can be remote controlled but some apps run locally and have their own displays.
We also have certified build chains running on specific systems, and while a GUI is typically not needed. It may be useful from time to time, mostly for debugging.
We are in a process of modernizing all that stuff, but because of certification and the average lifespan of a program, it is a very slow process...
Things seems to be going backwards in this area..
[1] https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platf...
And screen tearing? Didn't SGI have that solved in the 90's?
It was "slow" when I did it over 10Base2 Ethernet spanning an entire building. These days our CPUs are several orders of magnitude faster, and so are our networks. I don't need it to play the latest 3D games, I need it to display a user interface to an app that runs on a different machine. It's plenty fast enough.
On a local network, it's not significantly slower to run most apps through X11 forwarding than running them locally, and I use this extensively. The only daily application that's too slow is a browser, but Firefox (and before it, Mozilla did it too, and before it Netscape) automatically opens calls to the browser in the existing local window anyway (and there's always some pre-existing Firefox window open), even when running on some markedly different system (POSIX for the win).
When I used MacOS more regularly, Quartz always was the first application I installed.
When I see the comments from philistines unable to understand the obvious superiority of the one true Unix way, I always think of this Dilbert comic : https://dilbert.com/strip/1995-06-24
Which works fine and isn't a problem.
> A small price to pay for eliminating tearing and actually-secure screen locking.
Not necessarily. Not in all use cases.
"It doesn't work for me, therefore nobody needs it," isn't a valid argument.
And thinking about it a bit, it wouldn't have made any sense to keep the feature around for so long if it weren't useful.
If you're on Windows, try xyplorer. I can't remember anything NC did that xyplorer doesn't, and it does a lot more, too.
What’s the problem with Midnight Commander and/or the 23 other programs at https://en.wikipedia.org/wiki/Norton_Commander#Norton_Comman... ?
Norton Commander was simple, but it got the simple things right.
If you want a closer clone to Norton Commander, try FAR Manager: https://www.farmanager.com/ (Windows only)
This is a long, gentle transition. Although I believe it to be possible, I still haven't ever run a pure-Wayland system. Most graphical applications for Linux still need an X server, and Wayland provides one. Under sway, I can still run ssh -Y and start X clients on the host I'm connected to. This works just fine. It's going to be years until Wayland kills off X11 on the wire, and alternatives are already under development. I worry about a lot of things, but this isn't one of them.
Plus the death of all non-mainstream window managers, it seems.
Realistically, I'm not moving away from X11 if it will create a UI regression for me. This means that unless I can get Window Maker and application forwarding, I'm not moving to Wayland, and I doubt I'm alone in this general feeling, even though other people use different window managers.
In any case X11 isn't going anywhere even if Xorg developers decide to abandon ship, others will pick it up and continue. It isn't like Xorg was the first and only server, it already the third or fourth fork from the original server.
Thanks to wlroots, many new window manager projects are starting, often inspired directly by particular X window managers:
https://github.com/swaywm/wlroots/wiki/Projects-which-use-wl...
However, the Mac problem is also annoying... not having $1200+ every two or three years to spend in new hardware is limiting. While it’s true that you can “code on anything”, resource overhead becomes a consideration at some point... which is why I switched back to Linux, but then I’m back at my first complaint.
>A lot of baggage gets applied today when folks talk about "Accessibility", but to me the touch-stone of a truly Accessible system is one where you dont have to ask what interaction modality someone else is using e.g. witness email, where the persons participating in a conversation never need ask "Did the person I am talking to use Braille, speech, or something else", similarly, someone who has a hearing impairment can send you email without you ever needing to know that he cant hear you.
I feel like too many developers treat accessibility as an afterthought rather than a central concern.
While over time things improved to the point where I only have pain after doing pixel-style photoshop work with a mouse, it made me painfully aware of easy it is to take things for granted and not consider accessibility.
If we live long enough, each of us will almost certainly have accessibility issues.
So improving accessibility helps our future selves.
I do this mainly because switching from font size to font size actually tires my eyes (they always need to refocus) on the long term.
Firefox supports both, but the default is to preserve it, I think.
(I am not sure if the point sizes of fonts have any meaning. I like my text a certain size and it's a different number in Chrome, Powershell, and Putty, which is weird to me...)
I don't think desktop computers, with the possible exception of the NeXT, ever respected that.
Put a nominally 12pt font on your screen. Now plugin a monitor with 2x the resolution. Now plugin in a projector with 4x the surface area, but the same resolution.
Drag the window around. What happens?
Yes, in highly defined scenarios, where you know for certain the number of pixels per inch and you know it doesn't change, you can generate as 12pt font that is actually 1/6th of an inch high.
Most of the time, software doesn't find itself in these situations.
Monitors are not. They have fixed surface area and it's entirely possible to respect that, since modern monitors identify themselves to the OS, so it's relatively trivial to calculate pixel density.
This sizing system was designed to be used with paper and PostScript printers respect it (or it'd be impractical to drive printers with different pixel densities).
(I always liked Chrome OS's solution to this problem: you can't span windows across displays!)
The generalization of this observation is called the curb-cut effect:
https://burness.com/blog/the-curb-cut-effect-how-a-fix-for-o...
Also, Karabiner-Elements helps me to remap some of my awkward key combinations. For example, I avoid doing any typing with my pinky - so shift has been remapped to spacebar long press, and control has been remapped to caps lock. These are standard settings that I think many people use.
I also try to use text-to-speech and voice control to avoid pressing the ridiculous arrow keys on the MacBook Pro.
On other machines, I have an easier time, since I have bought a mechanical keyboard which supports softer keypresses.
When I finally come around to it, I will try to purchase a joystick/accessibility (vertical) mouse. I just don't want to clutter my small desk too much.
E.g. do you want keep an eye on some information which can be fetched from the net? You just write a script which regularly fetches the info and puts it into a buffer, so you can take a look at it anytime, and then regardless of platform you have that info readily available just by installing your own emacs config file.
It's much easier to write such things in emacs than curating various different scripts in various languages (python, etc.) which all require their specific support which is either available or not.
Sent from eww.
Sent from nnhackernews
Sent from `M-x hackernews`.
Not in my experience.
I much prefer to use the simpler acme / plan9 way, where I am free to use the language I prefer or that is better suited for the job. Same for vscode, atom, etc.
Vim and neovim are halfway between these extremes and I would say easier to bend towards acme than towards emacs.
That being said, I use org mode because it’s great, thanks to emacs capabilities. I would however also much prefer org mode if it was an external pandoc-like program, usable from anything.
I disagree. I’ve been using Unix/Linux for 25 years, I’ve met maybe 1 or two people who know or use Emacs, whereas almost everyone knows enough to do some scripting.
I’m also guessing that installing and configuring Emacs is way more work than installing Python. And any gained Python knowledge will pay you back tenfold more than learning Emacs.
I use python too when it's the less hassle. E.g. when parsing a page with BeatifulSoup which would be more cumbersome in emacs without BeautifulSoup.
Actually Python is not a very good example since Windows now includes python and python3 commands by default[0]
0: https://devblogs.microsoft.com/python/python-in-the-windows-...
$ sudo apt install emacs $ emacs
From there it's learning some keystrokes. Payback? Almost immediate. And you can use it to work with Python, or any other language. After that, maybe reading a couple of howtos and installing a few add-on packages and customizing your configuration. Payback? Almost immediate. It's really productive.
Learning Emacs is VERY clearly not this trivial... to use Emacs to any extent where it's more useful than it's competitors, you have to learn the models it works in, a new programming language- and then there are a LOT of keystrokes
It probably is a good idea to learn it, in some sense, and you'll probably have to pick up at least the basics that I've picked up, but it's definitely not a commitment to learn a new language.
I'd consider myself an advanced user of emacs, but that still doesn't mean that I have any motivation to write any new emacs modes or functions, since just about everything I could ever want already exists!
Plus, it's the same race car. I've programmed half-a-dozen languages quite seriously in emacs, and I'm not changing editors the whole time. So, while I may not know elisp, I do know a fair amount about emacs and don't have to relearn how to do a lot of things in a new IDE every three years... or, worse yet, discover that entire features are missing because "nobody" has ever used an editor that had them. (I'm not sure I could live without macros of some sort in an editor.)
An experienced racer would be much better off with driving in manual, but for a beginner or someone never expecting to push the car to its limits the automated gears are plenty good enough.
The people who Emacs will please most are power users who are willing to put in the time to learn it and configure it to their liking.
I’ll concede that one can be extremely productive using Emacs or Vim, but the steadfastness to refuse to adapt to changes in how most developers work isn’t going to help win any arguments.
Let's take these claims one by one:
> you have to learn the models it works in
I read a book on Emacs and practiced along all within one week. At the end of the week, I was doing more with it than with any of the previous text editors I used.
Indeed, my desire to learn Emacs was explicitly to replace the other editors I was using - and I succeeded. Over the subsequent weeks, every time I encountered a situation where I said "Oh, I wish the feature I used in editor X existed in Emacs", a quick Google search told me how to set it up for Emacs.
> a new programming language
I was a power Emacs user for over 9 years before I learned Emacs Lisp. Clearly wrong claim.
> and then there are a LOT of keystrokes
While I'll admit you get more productive the more you learn, for most of those 9 years I did not know many keystrokes. Instead, you do M-x and the command. With completion systems like ido (the "simplest" of the powerful completion systems), you can quickly find the desired command just by guessing what it will be named.
I only started learning lots of keystrokes recently, using flashcard software. And even with that, I stopped after about a year once I learned how to use hydra.
For instance- search and replace. I'm not an IDE user, but I'm sure I could pop open any modern IDE and find and use search and replace in roughly 5 seconds. Emacs- is that discoverable? Or does it require documentation?
I’m a full-time python developer in the sciences and an emacs user and neither of those claims are true.
More’s the pity.
I really doubt that a person who is able to code in elisp will not be able to grasp the concepts of Python.
https://www.gnu.org/software/emacs/:
> [Emacs is] an extensible, customizable, free/libre text editor — and more
<user>: ,terminal
fsbot [->] I heard terminals are [0] Terminals do weird thing to your keyboard input: http://catern.com/posts/terminal_quirks.html
fsbot [1] Terminals have limitations compared to the graphical windows; it's advisable to use "graphical" Emacs unless one has a good reason not to. See ,betterdefaults for disabling scroll bars, tool bars, etc.
fsbot [2] https://garbagecollected.org/2017/01/31/four-column-ascii/ ;;[ ,more / ,dump]Though terminals definitely have their quirks and limitations, they have some advantages over GUI Emacs.
For example, I have my Emacs configuration geared towards terminal use, and use it from within tmux. Because of this I never have to fear losing my Emacs session because X froze or crashed (which has happened from time to time). I can also use Emacs configured the way I like it even before X has started, and on remote systems without X (for which I don't like to use TRAMP mode because it also has the potential to freeze up).
By running Emacs in a terminal under tmux, I also don't have to mentally context-switch between the terminal and a separate GUI Emacs session. I have not been satisfied with any of Emacs' terminal modes, tough I have heard that libvterm is a lot better, so I might give it another go, though even if it's great at terminal emulation there are some other issues with running a terminal from within Emacs which may be insurmountable[1]... which leads me to the next point...
With Emacs running under tmux in a terminal rather than the other way around, I never have to fear losing all of my terminal sessions when Emacs freezes or crashes (which has also happened from time to time). By contrast, tmux is super stable, and I've never once had it freeze or crash, so I can 100% rely on it to keep my terminal sessions running no matter what.
[1] - Running a terminal under Emacs (even if it's a proper terminal like libvterm) has the issue of conflicting keybindings. I already have both Emacs keybindings and tmux keybindings that I have to make sure don't conflict, but if I add to those keybindings for any app I happen to run under a terminal under Emacs then there are bound to be way more conflicts. Of course, it's possible to require some extra keystroke to be pressed before sending on a raw keystroke to the terminal app, but that's just too painful for me to bother with except maybe under special circumstances. In the general case I prefer to have my shells running directly under tmux than in an Emacs terminal.
As a long time tmux and vim user, I picked up emacs just so I could use org-mode, and installed evil-mode. I have been using GUI emacs but I'd love to use emacs in tmux. In tmux I had been using C-a as the prefix.
The only annoying part is needing to hit C-b twice to move one space backwards.
I really should remap the tmux keys, but at this point I'm used to it.
Update: Well it does the same thing even when I run emacs in terminal, without tmux. It looks like I may need to configure iTerm2 to interpret C-RET properly? I am not sure.
Update 2: C-RET sends a return https://gitlab.com/gnachman/iterm2/-/issues/1897. How are folks getting around this limitation?
For me it's not even possible in a TTY.
I've recently started making a relatively determined attempt to become proficient with emacs due to increasing frustration at poor performance from both VSCode and Sublime Text when working with larger projects and, I'm not going to lie, it's hard going.
Take something as basic as working with multiple windows. Emacs has concepts of buffers, windows, and frames, but windows and frames are diametrically opposite in concept to windows and frames in client side web development.
That's not too difficult to grasp but, say you're in dired, and you want to open a file in a new OS window (in emacs-speak this would be a frame). You'd think you could just move the caret over the filename and hit some key combination to open that file in another window (sorry, I mean frame). Possibly you can but the nearest I've managed to get so far is (from memory) C-x 5 f, which brings up the minibuffer prefilled with the pathname of the directory you're browsing in dired, and then you have to start typing the filename (which, granted, will autocomplete), which seems somewhat redundant, and only then can you open the file.
It's also full of things to trip you up, like the key bindings for switching to another (emacs) window and killing a buffer - both fairly common operations - being far too similar and easy to confuse for a newbie.
It just seems so deliberately contrary, but I'm hoping the investment will pay dividends given time and persistence (this is, however, approximately my fourth or fifth attempt in 20 years to learn emacs, so we'll see).
Also I hit Cx-c by mistake thrice a week.
;;; Make it more difficult to kill emacs accidentally
(defun my-kill-emacs ()
"Confirm before 'save-buffers-kill-emacs'."
(interactive)
(if (y-or-n-p "Really kill Emacs? ")
(save-buffers-kill-emacs)
(message "Aborted")
)
)
(global-set-key "\C-x\C-c" 'my-kill-emacs)My emacs uptimes (M-x emacs-uptime) are generally the same as my machine's uptime, which is typically months. Emacs is one of the most rock-solid pieces of software I have running.
It's also great for remote. I have emacs daemons running continuously on my remote boxes. To start work on those machines, I log in and start my emacs client. I've never had a need for things like "screen".
My understanding is that without screen/tmux, the process will die if you disconnect the shell (on a remote box).
Interesting that --daemon works too (I've been running emacs through tmux for years, and never knew that).
Unbind it. Problem solved. That's what I do with my clumsy fingers.
A slightly nicer embedded docs. They were great for 80s way of life, but it could use a slightly more reply (to stay in the context of a live editor / lisp machine). Maybe a text demo system.. after all you could script a demo of workflows in elisp for newcomers to see rapidly.
- hydras could be extremely useful for newcomers for instance (and I'm no fan, but it cuts the chase by a factor of 1000)
- ace-jump
I don't know, I'm just suggesting
They're a big part of what make Emacs useable for me.
I have set up hydras for pretty much every major mode I use (except magit, which kind of has its own hydra-like menu system).
Because of hydras, I don't have to remember all the arcane keyboard shortcuts these modes have bound by default, and don't have to look up how to run a function that's not bound at all.
All I have to remember is one keyboard shortcut which I have configured to bring up a hydra in every mode, and it'll show me a menu of everything I can do in that mode.
This is really fantastic, has revolutionized the way I use Emacs, and has made it 10 times as useable for me as it was before I used hydra.
I wish 'UI autocomplete' like this was a standard feature of operating systems. GUI's aside, how nice would it be to run a CLI command with some flag that allows you to explore the various options and string them together, rather than reading the manpage and searching for whatever flag you might want to use?
You must be referring to `C-x b` vs. `C-x C-b`. I remember getting apoplectic over this in 1995. I remain aggrieved to this day.
My recommendation would be to bind `C-x C-k` to `kill-this-buffer` and unbind `C-x k`, or bind `C-x C-o` to a hydra that lets you repeat `C-o` i.e. hold down ctrl and repeat `o`, to cycle windows. Or both.
Alternate, try out `ace-window`.
I'm not sure about "too easy to confuse for a newbie." These kind of mistakes only happen when you are switching buffers rapidly without checking prompts, and newbies won't be doing that. And the default mnemonics are (unlike much of Emacs) good for these tasks. So rebinding doesn't feel like a big ask.
(Agreed `C-x b` should be removed imo.)
Also some of the plugins augment Emacs so much that some people see them as part of emacs rather than an add-on. I don't use dired; I use helm/ivy.
I am having good luck with Doom Emacs. You may want to check it out, especially if you are used to the Vim keybindings. It provides a lot of extra functionality out of the box.
For a lot of tools, both in software and other fields, there are three different classes of user.
1. Those with fairly straightforward tasks that they just want to get done.
2. Those who mostly have staightforward tasks, but occasionally have something a bit more complex but not too complex.
3. Those that need to handle everything from simple to ridiculously complicated.
Take electrical testing tools for example. For a lot of people a simple battery tester is all they need (class #1). If you want to test a battery and have never used a battery tester before, it will either be obvious what to do, or a glance at the instructions will tell you.
Some people need a bit more on occasion, and for them we have a class #2 tool, the multimeter [1]. You can still pretty easily test a battery with one, but the first time you probably will have to spend a minute or two in the manual, learning what voltage setting you want (the V with the ~ over it, or the V with the dashed and non-dashed line over it?) and which holes to plug the probes into.
Some people need a lot more. They have a class #3 tool, the oscilloscope [2]. You can check a battery with an oscilloscope, but if it is your first time you are going to spend a lot of time in the manual before you get there.
Emacs and Vim are class #3 tools.
[1] https://en.wikipedia.org/wiki/Multimeter#/media/File:Fluke87...
[2] https://www.tequipment.net/Rigol/MSO1104Z-KIT/Mixed-Signal-O...
You don't need Emacs or Vim to be an incredibly successful software engineer. It's actually the opposite, Emacs and Vim users are a minority among successful software engineers.
So they are only a specific kind of power tool.
More than that, they can't even handle the "ridiculously complicated". Common examples are trying to use them with projects containing millions of lines of Java or C# code.
But using a more advanced editor can make it easier. If you are going to be doing software engineering for a few decades all the times you have to do some repetitive task in a simple editor that would have been quicker in a more powerful editor adds up.
I'm arguing that IntelliJ/Visual Studio are more powerful than Emacs or Vim.
The Emacs and Vim architectures are antiquated and the volume of effort put into developing them (and their ecosystems) are outclassed by modern IDEs, especially for languages that scale to large numbers of developers working together (Java, C#). Emacs and Vim are poor man's IDEs compared to actual IDEs for these cases.
Emacs and Vim are mostly popular amongst C/C++ developers, where the ecosystems are generally baroque, forced by the need to integrate with embedded systems with limited toolchains or with libraries/frameworks that are very limited, and amongst developers working with dynamic languages, where you generally have small teams. Or large teams and a ton of headaches :-)
However, that in itself is not my reason for preferring Emacs. It's also my markdown editor, often my file manager, my PDF viewer, my image viewer, my git interface, IRC client, email client... I could go on, but I'll stop there.
Emacs is not and has never been an IDE, it's a highly versatile and extensible text-editor. You can't compare apples and oranges.
Outclassed in what way?
Have you looked at LSP[1] and its support in Emacs[2], for instance?
That's not to mention things like SLIME and paredit for Lispy languages, or the integration of the rest of the Emacs ecosystem in to your development environment, the ability to develop and configure all these development tools in Lisp instead of being forced to switch to some other language, etc.
[1] - https://github.com/Microsoft/language-server-protocol/
This is not surprising; it's no different from Vim users who have never written or debugged a line of VimScript.
At the end of the day, it's kind of just shifting around based on what feels good. It feels similar to sitting in a cafe for a bit, but some times working from home, and some times in the mountains.
But there's no need to put people down by saying stuff like "poor man's" IMO. And if you're restricted to what makes C# and Java tolerable, that's a small space. There's a lot more stuff out there.
And programming is not as simple as "make decisions that optimize your engineering throughput" IMO. Otherwise gardening would be agriculture, right? Both are important in their own ways.
In any case Vim's terminal emulation and asyncness these days along with coc.nvim brings it back on track IMO. There was a period where it was behind.
I do think it depends a ton on language. The best experience in Vim is editing Go, I think. And then TS and C++ have been a close second. Lisps are not great, Emacs tends to better. For Java and C# it's definitely IDEs. VSCode is also fine for a lot of langs, in a more out of the box way. Cursive is also good I hear for Clojures. If you need to move between a lot of langs, the only IDEs that pan out are IntelliJ mostly, unless you count Code as one. But Vim and Emacs have the best multiwindow and multi buffer management. And the best git integration for patch by patch staging, for sure.
And ofc for ObjC and Swift it tends to be Xcode. If you're really into Freepascal then Lazarus etc. Smalltalks are their own thing ... it keeps going on.
Donald Knuth. Author of "the art of computer programming" and many contributions in computer science.
Linus Torvalds. Original author of Linux (the most widely used kernel) & git (most widely distributed version control). In fact, he wrote his own version of emacs. He doesn't do much, if at all, coding now.
Joe Armstrong. Author of Erlang.
Guido van Rossum. Author of Python.
Yukihiro Matsumoto. Author of Ruby.
Rich Hickey. Author of Clojure.
Andrei Alexandrescu. Author of D.
Xavier Leroy. Author of OCaml.
Michael Widenius. Author of MySQL & MariaDB.
Guy Steele. Co-author of Scheme.
Stephen Wolfram. Physicist, computer scientist & author of Mathematica.
Peter Norvig. Research director at Google & well known Lisper.
RMS. Well, original author of GCC, Emacs & the GNU system.
All of them, apparently, don't require one of those "powerful" IDEs.
VSCode would need to be 10x better for the seasoned veterans to justify switching. If it were only 2x better, arguably the investment would not be worth it, but it doesn't change the fact that VSCode would be 2x better than emacs.
The name "Microsoft Visual Studio" refers to a product line with a long life, which had been a monumental piece of shit over most of that life.
Vim and Emacs helped people survive Windows development jobs centered around Visual Studio.
It is also a piece of software where changing the terminology is very difficult. While a non-scriptable program could simply change the documentation and be done with it, Emacs would either have to change the names of exposed functions (breaking compatibility) or have one set of terminology for scripting and another while discussing the user interface.
Perhaps better choices could have been made, but the issue is non-trivial.
I've put in a ton of time and effort configuring Emacs (after spending about 25 years on vim and vi), and though it took a long time, the results have been well worth it for me.
There's no way I would give that up and go to something with more reasonable defaults but which is much more limited in customization capabilities and which lacks a Lisp ecosystem which has been improved by thousands of people for many decades.
You do know that there is a middle ground, right? Emacs itself could come with reasonable defaults.
You'd still be able to customize it (after all, you probably did) and all the newbies wouldn't have to read about 80's computing arcana to figure out how to split a window.
I've never tried any of them myself, because I already have Emacs configured to my liking, but reasonable defaults is what these packages aim at.
That's the rub though. Emacs could change its defaults, plan large deprecation and rename, rewrite all its documentation and write even more to help migrate. And 20 years from now someone will be whining about the 2010 "web arcana" embedded in some interface and command set.
> newbies wouldn't have to read about 80's computing arcana
Because here's the perfect example. Emacs isn't 80s computing arcana, it's 60s computing arcana largely encoded into it in the 70s. In the early 90s when I first picked it up there was a similar push to encode the arcana from the 80s instead. "Pick the standard keybinds that make sense!" they said. Like Shift-Delete for cut and Shift-Insert for paste!
... oh, that's probably not what you want today either, is it?
So here's your options:
- Churn the defaults and everyone's configs every 15ish years
- Document as best you can the defaults and how to change them, and make the best UIs you can at the time, in fashion or not. (Kill rings are still better than cut buffers!)
Universal "reasonable defaults" don't exist in a tool meant to last 50 years in an ecosystem of fads.
You could bundle up maybe a dozen keybinds like this, but it's not going to scale to even address the complaints we see in this thread (window vs. frame terminology), let alone the full gamut of mainstream Emacs configuration. And it's a massive amount of work to do. And it's not fundamentally different than just picking an Emacs-distribution-du-jour (Spacemacs, Doom Emacs) right now.
If that's what you want, my view is you might as well be churning whole editors. And truthfully, if that's what you want, do it! But I want a kill ring, and buffer/window management that doesn't presuppose multiple frames, and my mode line. I don't want to waste critical keybindings like C-x or C-c on weaksauce single-buffered text operations. And yeah, there's a lot of things I would change if I was doing "Emacs from scratch", but on the other hand I don't need to because I can change them now, and easily share them, and still take advantage of what everyone else is doing.
At a certain critical mass, soft-ware stops being soft. Other things bend to accommodate the soft-ware.
You know what's even harder than hard soft-ware? Social mores and expectations. For example, such as those formed by millions upon millions of spreadsheet users.
Or billions and billions of web users.
So, where am I going with this? Emacs has encoded some norms from the 60s when the tech community was probably 0.1% of what it is now, and when large numbers of those 0.1% people were technically adept and very flexible in adopting new things.
"Web arcana" has been assimilated by a million more applications and systems than those systems that inspired Emacs had. It has also been assimilated by billions (!) of people.
60s arcana is not equivalent to web arcana, for this reason.
When we hadn't even standardized the keyboard layout and the "display" was a dot matrix printer? When there was no networking to speak of?
How does that make more sense?
I can throw the bullshit rhetoric right back at you: You think absolutely nothing was better in the 60s? That modern IDEs lost nothing compared to the tools of 10, 20, 30, 40, 50 years ago? Why isn't Emacs like Borland? Why isn't Emacs like Visual Studio? Why isn't Emacs like Eclipse? Why isn't it like Mosaic, QuickBasic, Coldfusion? There are reasonable answers to these questions, and they'll tell you also why Emacs isn't like whatever you want to compare it to today.
Maybe Emacs already occupies a local maximum, "a middle ground", taking some of the best compatible ideas from the times it's been alive in. Vi another local maximum. IntelliJ or VSCode, others - but emphasis then on local, and I hope you like retraining.
The problem is not keybindings or what decade its metaphors exist in, it's people see Magit or Org or whatever high-level fully-integrated tool, and want just that. And you don't understand that is an outcome of a path that really does require the whole philosophy to ingest into your workflow. But you don't want to learn the philosophy, you just want to 10x crush git or whatever. No, it won't happen. There's all sorts of dumbass metaphors in in this thread now, but in the end Emacs is garden, not a hammer or a workbench or an oscilloscope or whatever. You get out proportion to what you put in, you work with it not just use it.
Shit's just gonna get faster. You need to find ways to live with it, not copy it. Talk to your fathers-in-law.
You could try Spacemacs. I've only just started seriously getting into Emacs, and have found Spacemacs to be a big help.
The straight documentation on the parts? I'm curious how you would want those to be otherwise. They mostly read like the user's manual of a car. Fairly technical, but at a very high level. With occasional tips on how to use the part you are reading about.
But that's the point: it doesn't.
Maybe it does if you want to invest a few hours getting up and running, but I don't have that kind of time: I need to get stuff done now.
I'm not saying I'm too important, or my time is too valuable, or any nonsense like that: I just don't have time to invest in spending a day or even half a day learning what are in contemporary times the basics of using a text editor.
And that's the problem with the tutorial: it doesn't start with a quick two page summary of what, in contemporary times, are considered the basics of using a text editor. It's long-winded and academic and takes way too long to get to the point on any and all relevant topics.
The result is that I have to (and not just me: anybody used to non-emacs - or perhaps vim - editors) invest non-insignificant amounts of time learning basic functionality that works in a common way across most other editors and IDEs (IDEA, Visual Studio, Rider, VS Code, Sublime, TextPad, XCode - heck, even Microsoft Word) and learn completely different paradigms for all of it just because emacs is "special". It's pretty frustrating because for me the editor is not the point. I'm only looking at emacs at all because a lot of editors, once you get to a project of any size, become absolute CPU hogs and it starts to get in the way. But given the grief I may come to the conclusion that a better investment is just to buy a faster laptop.
I'm totally happy to be proven, or to prove myself, wrong, but right now the whole emacs ecosystem seems unnecessarily, contrarily alien simply for the sake of it.
There also seems to be a strong lack of empathy for users. Few influential people seem to have given any consideration as to how to make the software accessible for newcomers. In this day and age that's almost laughable.
If you want there to be a new tutorial, I don't know anyone that would be against it. The "game to learn vim" was popular a few times. Same basic idea. I don't know what I would make of it, right off. There are some great typing modes that let you quickly type the current document and score you on speed/accuracy. Moving to other windows is tough in any option. But I could imagine a fun game made to navigate through. (Though, with helm, most navigations are autocompletes nowadays.)
I hate that it feels like a lack of empathy for you. But I really don't see the ecosystem as alien. Any more than I see the python ecosystem as alien, or the java, or javascript, browsers, etc. They are all just a little different. But all have some rough analogs. And all feel like they are just trying to shield users from complicated problems. Many times making things more complicated in the process.
Of course you're right, when you start using computers everything is hard, but many applications have common conventions, even across different authoring organisations and people, and even across different operating systems.
Emacs has conventions but there's next to no commonality with other applications within the same broad class, so you are starting from scratch. Emacs makes no affordances for people who are already used to using other software, whereas much other software does make those affordances, and so is easier to pick up as a result.
Maybe you don't see that as a problem, and that's fine, but for me - and, I suspect, quite a lot of other people - the steep learning curve feels unnecessary and, frankly, bizarre to the point of being out of place.
There's no reason Emacs couldn't be easier to use. There's no reason the documentation couldn't be written to accelerate proficiency with the application. But neither of these things is the case, and it's a deliberate choice. As I've already implied, it seems almost obtuse just for the sake of it.
I know it will sound contrived, but when I sit at a coworker's desk using sublime, I'm literally lost on how to navigate. I don't even know how to get the editor to list all open buffers. IDEA? I mean, I know it has the functions, but it is a search every time I have to try them. (Again at someone else's computer.)
I could think it was just my emacs knowledge not working, but I see the same hiccups from folks moving from each. So it isn't just me.
Are there affordances that are common? Yeah, but many have changed, and not all over long timeframes. Worse, many are different from Windows to Mac to Linux. There is a good argument for adopting what is native to where you are, but the rise of browsers has shown that to not be that important, ironically.
I do see it as a problem, if it is keeping folks from using computers. Or, if it makes folks build things that can't be used from emacs. That said, I don't see it as an insult or as a problem if you choose to use something else.
Again, for many of us, emacs is easy to use. For many of us, the documentation is written in a way to accelerate proficiency. I would love more documentation or affordances to help. So not stonewalling, but I caution against the attitude that what is there is bad.
And I get it, I think. I have recently tried to plunge into Blender and Gimp. Holy crap do I feel punished for mistakes there all too easily. :(
It's true, but I don't see why this is being given much importance. If you pick up any editor and use it only to the extent that you can without ever having to read up documentation, then simply go ahead - you likely do not need power features. If you need to do powerful things, then I suspect you will need to read docs regardless of the editor.
Emacs is a powerful tool. If you only need basic editing, then don't use it. That you can't do basic editing with Emacs without even going through a tutorial is not a flaw of Emacs, and you are clearly not the target audience for the program.
The tutorial covers only the very basics. It's less than 1% of the material in the manual. And I definitely agree with him - most Emacs manuals (whether for Emacs or for some packages) are written more as reference manuals than something to learn from. If you're lucky some of them will have a tutorial in the beginning.
So, to that end, what makes the manual of VSCode/Atom/Sublime good? Since there is an implicit comparison to those as a good comparison.
In this analogy, emacs' accelerator is on the ceiling, the bake hangs off the side and to steer you need to tap out the morse code for the words left and right on the dashboard.
Can you become proficient using that kind of interface? Probably.
Can you change the interface to something more sane? Sure, but you have to first learn how to weld...
Even better, compare it to driving a boat, when you've been used to cars. (Or, for that matter, realize that it is a stick shift car when you've been used to automatic. And slowly realize everyone has a slightly different way to get their system running as an automatic.)
This is like a car model that came into existence 40 years ago, but is still making cars today.
Ford is over a 100 years old. Yet I have no problem getting into a rented Ford and driving without consulting the manual.
And my point is I agree that vanilla Emacs can feel spartan. Thing is, my customizations have aged really well. My config for Emacs hasn't changed too much in over a decade. That kind of stability is hard to put value on. Especially when our industry seems to price itself on instability.
C-x 4 is a prefix for "other window".
C-x 5 is a prefix for "other frame"
(It's OK if you did not know this. I was a heavy Emacs user for a decade before I learned this).
For your particular problem, you may want to look into Hydra. Setting up your own Hydra for dired-mode will involve some basic Elisp, but not much - you can just copy/paste from elsewhere. However, you may need to write an Elisp function for your particular situation, and then have the Hydra call that function.
Similar to another commenter, once I learned hydra, I create my own menus for every new mode I want to use. Much easier than memorizing keybindings, and you can put your own custom stuff there.
Also, I rebound F6 to switching windows. C-x o would drive me nuts. F6 is the standard in Windows/DOS, so that's what I was used to (I still use it in Outlook for work to avoid the mouse).
I'm on the other end of the spectrum, I'm betting that computers will become fast enough with time to run these bloated editors that were designed to be usable.
What ties all these notes and files together is Emacs Lisp: Write Lisp functions to automate most of what you do. - Previously I used Python for that, but Elisp is so much more fun to automate text-based workflows.
I would have to write a book to summarize all the ways this can transform your interactions and workflows with your computer and especially with everything text.
Edit:
After twenty years of using all sorts of text based databases and PIMs (AskSam, NetManages ECCOPro, various outliners, Outlook, Evernote, Omni{Focus,Outliner}, Bear Writer App, Ulysses App, and half a dozen other tools) I have come to realize that nothing beats Emacs + Org + Lisp.
I use emacs 25/7, I hate org.
Something about it rubs me the wrong way, yet I use it but only the basic parts. I think it's that I can't wrap my head around the mental model of it, and since it encompasses 2000 topics (trees, timing, workflow, states, agenda, journaling, tagging) it's like a mountain of mud before my eyes.
What it is good for is that it gives you maximal freedom in organizing things the way you want. When I start out with a new org file, I just make lists and add functionality when needed.
While with most other todo/organizing applications you tend to be forced in some framework. This is how you should organize, and when you want to deviate things become cumbersome.
And then the other good thing is that editing is FAST (I use evil mode), in most other organizing/productivity tools you have to click a lot. Simple things become a chore quickly.
Freedom + speed = gold
who knows, maybe one day I'll finally see the light
[0] and I fully agree that most systems are way less ergonomic than emacs
I also have read the org manual a few times, and it feels so big you can't hold a mental model for long enough to make sense while incorporating all its features. As you know, org mode has too many features to use them all at once (like emacs itself).
What (kinda) worked for me was, after knowing "I've read it all", to purposefully "downgrade" to a very very basic workflow. I thought then I would start adding features on a need basis, because I had the perimeter of what it can do.
But it turns out I haven't added anything else to the trivial workflow. There's a bit more info here ( https://puntoblogspot.blogspot.com/2018/12/3-basic-org-agend...), but essentially the trick was to use just one capture template for everything that just schedules the current task for today (so it appears in agendas until I mark it as done), and one single file, without different subtrees.
("t" "Todo" entry (file+headline "~/org/tasks.org" "Tasks")
"* %^{title} \n SCHEDULED:%t\n %?\n %i\n %a\nAdded: %U")
Seriously, M-Ret, TAB and S-TAB are all you need to get going.
I watched the Google Tech Talk on it and was immediately productive. Don't bother with the Org manual until you want to do more.
> As a blind user, I can write a special mode which does something specific, say, implement an IRC client. Almost all my work can instantaneously be used by sighted people using their graphical toolkit.
This goes well beyond the ability of the author to create software that is accessible for both sighted and blind users. It is stating that support for both audiences is handled elegantly by the same toolkit, so you aren't creating an adversarial situation where serving the needs of both groups of people requires some form of compromise in the user interface or necessitating significantly more effort. (I would imagine that some care is required, but Emacs developers are going to address it anyhow since the program is intended to run in graphical and non-graphical environments.)
I suspect this support of multiple environments is part of the reason why there is an esoteric collection of applications that run within Emacs. As an example: it is possible to read ebooks in Emacs, with formatting and images being supported in X and gracefully handled in a terminal.
For one, all the keyboard shortcuts and commands that you have to learn; I don't know if I have the capacity to learn all that anymore, not without deliberate practice, while in modern editors you can get by with keyboard + mouse and slowly learn some new shortcuts here and there.
Second, it feels like you have to spend a lot of time to set it all up.
Third, will it replace an IDE? Error checking / linting, autocomplete, fast navigation, auto-imports, loads of things like that that seem to just work out-of-the-box in e.g. idea.
I use emacs for org-mode exclusively. You only need to learn the buffer manipulation and org-mode keybinds for this, and the configuration.
I use vim for ad-hoc text editing, it's a poor IDE as I've configured it.
I use IntelliJ IDEA with IdeaVim for writing code.
I do not consider myself superhuman. A notable fact is that at some point previously, I've used every one of these as my main development editor.
I couldn't imagine having to maintain configuration for IDE-style features in all three editors, so I won't bother, but I do bother using the best tool for the job.
There's a lot of solutions for this but pretend I want to graphically step through, edit the code etc...
Emacs can do this quite well without any special hassle.
Just try using it as a debugger, when you're annoyed, search the web and you'll find your answer.
I'm not an emacs user so this is coming from a non koolaid drinker but I've been using it more and more for these special use cases
Maybe this is just as easy to do in, say, IntelliJ, I just feel like emacs will leave a cleaner footprint and have more sensible defaults.
So give emacs a try for debugging something (the Google-fu is GUD, grand unified debugger), it's not hard to use, the learning curve is pretty modest and you may be surprised by how sensible it is.
Neither is wrong, but I do believe that when someone goes on about how if you just try hard enough to grok emacs, you will suddenly get it. Maybe. But I think there is an audience bias there, whereby only people who are inherently interested in tweaking and fiddling will achieve that benefit, and only people who wish to just get things done on a paid tool will be OK with using a mouse every so often. Horses for courses.
I think you have properly pegged the determinant as desire for customization.
As for full fledged IDEs, no, I don't think Emacs can pretend to replace those, but you can still make the Emacs experience comfier. Linting is pretty good on Emacs with things like flycheck (& flyspell for spelling in say comments or commit changelogs).
For kernel C development I have a simple flycheck module that compiles the edited file and inlines all warnings / errors as lints. I also have another one for checkpatch (extra script you're meant to run before sending your commits to the mailing list); as a result I never have to look at any other window than the one where there is code in it.
For Python, pylint is supported out of the box by flycheck. Auto-completion is supposed to be feasible, but I had some issues with it and gave up - never felt like I really needed for what I do in Python anyway.
Fast navigation can be done with the usual cscope / gtags. More recently, I've been converted to using ripgrep for most searches (https://stegosaurusdormant.com/emacs-ripgrep/) as it is crazy fast. You can also directly edit the matches and commit the changes, which serves as a project-wide "search and replace".
Seriously, check out Doom, whether you use neovim, Emacs, VS Code, or nano (Doom has quite good Emacs and CUA bindings as well). It’s brilliant to the point where I’d describe it as Emacs with sane defaults. I guess it probably can’t match the more niche IDE features but LSP and friends are bridging most of the gaps.
You can finally safely ignore claims that beginners should roll their own emacs configs thanks to Doom. That strategy is good for learning if you’re used to diving into unfamiliar systems but you can learn just as much by starting with Doom and working your way inward anyway. The community is great, just like the larger emacs community.
I can’t stress Doom enough; it gets better often not by the day but by the hour. Henrik is a machine.
Compared to Spacemacs, which has complex abstraction layers over Emacs, Doom seems to be much lighter. It's easy to get into Emacs browsing Doom's modules. Plus, the BDFL model is serving Doom quite well since Henrik is a god-tier BDFL. He's constantly active and keeps Doom very focused on performance with sensible defaults and consistent programming style. Docs are a focus and are growing, and they're extremely comfortable to browse in Doom Emacs itself, as well as the Doom and Emacs source code of course.
None of this is meant to attack Spacemacs, it did and does much for Emacs, and many swear by it. But I would say Doom is better these days.
I use both doom emacs and neovim, and I'd say: not really, at least not for me, there are some Vim features evil doesn't emulate properly, or at least it doesn't work like in Vim. Off the top of my head, I write in many languages, but absolutely hate the US international keyboard for accented characters, guess what? Vim has built-in support for digraph[0] by using Ctrl-k and iirc this is a motion keyboard shortcut in emacs, and since I like and use org-mode a lot, I'm always frustrated when I have to type in another language. Another one was with the various Terminal emulators packages in emacs, although this one was solved recently[1], whereas in (neo)vim it works flawlessly ootb.
It's defined in Evil (which Doom uses directly).
Seems like you just need to figure out your bug.
Fwiw use-package is pretty magic and reliable these days.
It made emacs a bit more accessible for me.
Agree, but I am extremely used to the trackpad and haven't used a mouse in years... because of its closeness to the keyboard (in pretty much any laptop) I can do things very quickly when I have no shortcut at hand... so much so that I only find it worthwhile to memorize a few shortcuts for the tools I use most (the terminal, IntelliJ IDEA, and a few for VS Code though I find their shortcuts terrible)... but it's unescapable that you'll need to use the mouse or trackpad sometimes, especially when not using your main tool (things like browsers, photo apps, even file managers unfortunately), so getting good at it I think is more useful than memorising a million shortcuts for a single tool.
You might have a better time using https://github.com/VSpaceCode/VSpaceCode
Or, if you like vi(m), evil mode [2] should be good to go.
The other things are worth exploring for fun and curiosity but it's sensible to look at them as they are - beautiful rainbows rather than maps to buried pots of hyper-productivity.
Two objections come to mind at the moment::
* vim keybindings have helped my RSI significantly (and before you go there, I got RSI when I was an IDE user, before I focused on on Emacs)
* Using Emacs and building my own config has not made me massively more efficient at the workflow level, but it has taught me a great deal about software design and development than I would have otherwise learned.
As to the second thing, it occurred to me recently that my .emacs is old enough to vote and probably still contains bits of other people's .emacsen that were old enough to vote when I first edited it.
> For one, all the keyboard shortcuts and commands that you have to learn
That's a valid concern. But if there was one keybinding every programmer should learn, it's probably Vim's. And while emacs has a default keybinding, it is not tied to it. Vim keybindings using evil-mode uses the same elisp interface as the default binding. Evil-mode feels very native and at par with Vim user experience. (Kakoune's bindings are derived from Vim's and is said to be better. But it's immature now. Hope it catches on.)
Emacs is a programming platform and not an editor as such. You should simply forget the key bindings (use what you are comfortable with- evil or even the Windows bindings) and focus on what the platform has to offer. Packages like Org-mode, Magit, restclient and a lot of others have no other alternatives. Emacs GUI also acts like a terminal emulator far more advanced than VT-100 emulators.
(Neo)vim is useful as an editor when you are setting up new systems or administering via SSH. Emacs is useful as a personal programming environment. With evil-mode, there will be no problem using either in the respective context.
> Second, it feels like you have to spend a lot of time to set it all up.
I support what everyone else recommends. Start with Doom Emacs or Spacemacs if you are a beginner. It does take a lot of time to set it up from scratch. I just prefer to set up everything from scratch, since I use a dotfiles repo. Improvements in configuration are incremental when you have a dotfiles repo.
> Third, will it replace an IDE?
All those are available. Just needs configuration. Or else, use Doom Emacs or Spacemacs - they come pre-configured. That really isn't the reason Emacs uses love it. It's those features you can't get in an IDE. If you have a task for which you need to switch out of an IDE, elisp makes it easy to integrate into emacs. The package repositories are full of such packages.
> [Every dynamic module] should also export a symbol named plugin_is_GPL_compatible to indicate that its code is released under the GPL or compatible license; Emacs will signal an error if your program tries to load modules that don't export such a symbol.
The viral nature of the GPL already bothers me. Emacs trying to enforce that I'm only running GPL compatible code is even worse.
There is an extremely active addon ecosystem as it stands.
Because I used Org mode, for awhile I tried to switch my other text editing to Emacs. But without a good mode, it's not worth using Emacs. I do all my other text editing in Vim.
> Second, it feels like you have to spend a lot of time to set it all up.
You learn a subset that's relevant to you. Also there is which-key which helps _a lot_.
But, I mean how do you learn, say, Spanish? Do you just drop English and start speaking Spanish to everyone from day one? No, it's something that happens in a dedicated time. Once you feel comfortable enough, and when the chance presents itself, you being integrating it to your daily life.
Similarly with Emacs, you could just start playing with it, maybe say editing your personal scripts with it at times, using Org mode for some notes. And then slowly integrate it to your life.
No matter how much work is done in the UI compartment, a tool as comprehensive and customisable as Emacs will never be learnt in one day. There won't be any magic bullets. It's always like learning a language.
The important consideration is if the returns are worth the investments here. Unlike other editors---which are great software in their own ways, anybody who says "hackers should use Emacs or Vim" or similar BS just don't know what they're saying---, Emacs provides some particular opportunities, which depending on your workflow might not be worth it.
> Third, will it replace an IDE?
Yes, you can get it to do all that. OOTB is hard, but AFAIU projects like Spacemacs and Doom are kinda making that happen.
* everything is a buffer, which in essence is a grid of text, that's the UI primitive, if you can render a grid of text you can probably build an emacs UI easily.
* every action/command is an elisp function that operates on these buffers
Combine these two and you can create pretty much anything. Code written in elisp that outputs buffers.
An analogy with the modern web as a platform: elisp is the JavaScript and buffers are the DOM.
Leave all the icons to their fans.
I've been using Spacemacs for around a year on the `develop` branch. For me it's fine, but for those who want a very stable experience I don't recommend it -- it does break sometimes.
Now, whether any of those UI styles are actually worth supporting is a completely different question. But it is not quite as universal in support of different UIs as this email claims.
(You can technically write line mode applications in Emacs Lisp, try `emacs -batch -l dunnet` for an example. But most Emacs functionality is not available in line mode, the core text editing functionality certainly isn't. There is also a HTTP server available for Emacs [1], so you could use it to implement a HTML-based user interface, but once again the vast majority of Emacs functions are not available over HTTP)
EDIT - just to be clear, I'm talking about emacsclient, talking to a emacs server. Not an actual full blown emacs implementation that's just stupid.
Let's just hope they don't have annoying GDPR and other popups when you're trying to edit a file.
Your remark about GDPR is kind of strange ... not sure what that would have to do with anything ... GDPR applies to people and organisations, not their tools.
To a lesser extent, there are people that are concerned about "all the extra work" this entails, and the cost it adds to their bottom line. But this stuff is important nowadays. You really should be taking care of it.
There is some scaremongering about small firms being blown out of the water for noncompliance, but really, unless you're doing something you shouldn't be doing you should be fine. The terms of GDPR though still not completely clearly specified are flexible and reasonable. The main thing is now, that you can't say you weren't aware of it.
OP is saying that Emacs-as-website would be frustrating if it had those popups.
The cookies warning is all about notifying the casual reader who might otherwise believe they were passively browsing static content.
Logging in means you get a single cookie (a login/session cookie), that cookie is necessary and thus a functional cookie that you can't say no to. All other cookies (and basically every form of tracking) still isn't allowed without consent.
You know that GDPR doesn't require pop ups unless the service is doing something that isn't otherwise lawful?
Old-school pure HTML forms actually has a lot conceptually in common with block mode terminals such as IBM 3270. The server sends the client a fill-in-form, the user fills it in, the client sends it back to the server in one block. Most of the logic exists on the server (although some basic very basic validations may execute on the client). So, I was actually talking about serving up a classic pure HTML form app over HTTP as a UI style.
I'm just talking about a thin client, such as you typically use when you have emacs running as a server. You only have to manage text and windowing, and capturing user commands and communicating with the back end. These are the kind of things browsers are good at.
Of course, Emacs doesn't support 3270. But that was my point – that there are UI styles which Emacs doesn't support. They might not be useful UI styles, especially in 2020. But historically they were important, and any suggestion that Emacs is some kind of magic which supports all UI styles isn't really true, although maybe it supports all contemporarily practically relevant UI styles.
It works pretty well.
What trouble were you having with specifically?
(defun fixed-pitch-mode (&optional arg)
(interactive (list (or current-prefix-arg 'toggle)))
(buffer-face-mode-invoke 'fixed-pitch (or arg t) nil))
GUIs and line-mode terminals are radically different, so you have to think of a language of UI primitives that are high-level enough to have a natural implementation in each style.
This is hard! For starters, a GUI is inherently spatial, whereas a command line is more temporal. If you want to specify a sandwich, say, then in a GUI, you might have three select boxes next to each other for the bread, filling, and dressing, and a submit button, whereas on a command line, you need to prompt three times, and perhaps offer options for going back and changing the selection. Or offer internal commands for viewing the lists and making a selection, for a more shell-like interface.
From what i remember, our API ended up looking a lot like web forms - the application presents a series of questions, each with a prompt and a structure for the answer (free text, select one from a list, etc). The GUI implementation then put together a (very ugly) GUI with a elements for each question, the command line implementation asked each question in turn.
We never got as far as trying to display rich information. That could have been a whole different set of problems.
Now I understand how having a scriptable and text-based foundation would help with accessibility, just Emacs wins no UI contest.
You can bind copy-and-paste as well as any other text wrangling functionality to whatever you want and there are ways to make it behave like other platforms without too much difficulty. But why hamstring Emacs' copy and paste by limiting it to the simplistic version we're used to when you can copy to multiple registers and have a searchable history of copied text?
Font rendering uses Harfbuzz in the latest version and is quite good in my opinion, there's even color emojis. Scrolling is certainly better than any terminal emulator I've used, although there's no smooth scrolling. I guess everything is off if you're comparing it to a browser, but modern browsers aren't exactly paragons of UX either. But if you're comparing prettiness options like these, yeah, Emacs loses to VS Code. All Microsoft had to do was build a text editor on top of a browser engine to get those features :). I'd say Emacs is more extensible, though. Lisp machines and all
I'm a super basic user and nowadays basically have Emacs open all day just for org-mode. Nothing else.
To me it seems a terrible text editor and has an UI that's foreign on macOS and Ubuntu. It's unclear to me under what OS/Window manager/etc Emacs fits right at home. It seems out of this world.
I can imagine there may be some configuration that would fix some of these problems, but I just use Emacs as it comes out of the box.
The fact that it's, essentially, the same on every OS I use it on is another selling point. I bring my .emacs file and make minor tweaks for different OSes (due to where files/programs are if absolute paths or relative paths in the user home directory are different). It always works the same once I've made those small changes (and they are small, and once done my Windows .emacs is good on any Windows box). Again, there are few other programs like this. At a minimum, you often end up with subtly different keybindings (macOS using the command key, Windows using control, and Linux using control or alt) and subtly different layouts that break workflow and habit.
It is annoying that Apple has a command key that I have mapped as Meta. Since that means if I try to copy something in Firefox, closed tab. That said, why are the keyboard shortcuts in so many other applications so destructive? And crappy? Browsers could be forgiven if they were just for viewing, but you edit in them a lot nowadays, such that the browser not having easily customized keyboard bindings is a laughable insult for user centric design.
(Do they even still pretend to support user stylesheets anymore?)
Yes, but eons have passed, things are different. Should everything else mold to Emacs or should Emacs fit into the overall OS/window manager/etc.
Maybe Emacs really is supposed to be an OS. I'm now wondering if there's a way to boot straight into Emacs. Clearly we could have a slimmer kernel /loader for that. :-)
But I totally get that this is from outer space for another group. Vim is a great alternative for people who want a more opinionated editing wizard mode, and VSCode is really competent at interacting with remote filesystems and supporting lots of languages for the GUI crowd. It’s a great time to be editing text.
A cool project I stumbled across is Aniseed[0], which thanks to Neovim's Lua bindings, lets you control neovim with Fennel. I haven't done anything noteworthy yet, but for the first time it actually seems like it would be fun to write my own plugins.
[0]: https://delysid.org
From a technical point of view, the website makes heavier use of tooling that nowadays are used less, because there are alternaltives. One example are actual hyperlinks and different pages, whereas today there's some trend towards keeping more content on a single page and use buttons to navigate it.
(In particular, Electron-based local applications which of course have a cross-platform web-based UI.)
I'm not saying they aren't different, at the very least, Emacs prioritizes text, while the web prioritizes multimedia. But I'd love to hear other peoples takes on the differences.
The web is generally terrible for accessibility. Since emacs has always prioritized maintaining compatibility between its graphical and text UIs, it words very well with screen readers and refreshable braille displays. It's also been designed from the beginning with keyboard navigation in mind.
In emacs there is a beginning and an end, and you just follow the flow. In webstack you have elements, which have a position and if you are lucky they are tagged with their purpose. If not, it's up to you to figure out whether this is for navigation or content or advertisement or some other navigation or comments, which is more another kind of navigation... Basically there is just no really realiable structure with the web. Sometimes there is something, sometimes not, sometimes it's this way, next week it can be that way...
And even worse are dynamic site where parts of the site are loaded on demand. So you need a complex setup of tools to handle those content, instead of simple text-search and cursor-moving.
The Web is also designed around a linear flow of text. The Web also provides opportunities to make navigation semantics clear. The Web also implicitly supports keyboard navigation everywhere. etc. Although many websites try to work around those principles, is that a problem with the web or just the websites people are using today?
If you do it on purpose, then maybe, but not to the degree of what webstack offers. People already have a hard time to handle org-mode-hierachies and folding...
> The Web is also designed around a linear flow of text.
No, that went out the door when CSS was added. Now it's designed around random positioning of little boxes. Some boxes contain linear text, some contain media, most contain even more little boxes.
Emacs does not have those boxes in the first place. The only boxes it has are outside the document, avoiding this whole class of problems for accesability.
Remember before CSS, people just did the same thing anyway with tables. CSS only made easier what people were already doing. I am sure the same would happen to Emacs if it ever became a widely used piece of software.
Does the emacs-api directly support this or is it just some hacked up solution everyone must do on their own? Of course can you emulate boxes and any kind of layout-sytem, but whether it's a general supported solution or just some ugly hack that has no backing in the general culture of a software, makes a significant difference. It's the difference between 99% of all encountered content is problematic for accesability or just 1%.
Not to mention that many of us have used emacs for email for ages. Which, lo and behold, is dynamic with parts loading before or after others. Even viewing images inline has been doable for a long time.
Don't get me wrong. Emacs has stayed mostly text focused. Even mostly linear focused, I would agree. I view that as a plus, though. The modern web world? Not so much. And telling that most "resurgences" of popular sites and ideas are usually a return to a linear treatment of data. Often most of the extra crap around are flashy graphics or desperate attempts to get more interaction from users.
There was an essay discussing this ... but I do not recall it now.
Cross platform UI, with a faster Lisp, would allow Emacs to be even more special.
I’d try one of the LSP based approaches instead these days.
Yes, on some modes there is a visible delay between pasting text and being able to type again, or writing some code and it telling me it's wrong. But the one kind of interaction that matters is always flawless.
Many editors do not get this right.
Emacs has a certain feel to it. Hard to put the finger on, but the movement of the cursor and the scrolling, it just feels nice for me. Like a well worn favourite T-Shirt.
If you want to use emacs as a an alternative to VSCode, or IDE in general, you'll find high quality plugins that will enable you to do so. But then you might experience slow downs.
As emacs is single-threaded (people will come and tell me it's not anymore, I know, but in practice it still is) you'll feel any slow downs in those plugins. Emacs typing latency isn't great.
It's a mixed bag really. It can be fast, it can be slow. It's still my favorite editor.
I'm not looking to encouragement to change (after 20 years in Vim that ship has likely sailed for good), I was just curious if the speed of Emacs lisp was a frequent bugbear.
But overall I'm a very happy emacs convert. It's extremely malleable and pleasant development environment and I think it definitely deserves all the gushing articles/posts its been receiving past few years.
It's not 100% ready for day-to-day use yet—the deferred compilation logic seems to be recompiling more often than it has to—but I've been quite happy with it so far, and it will make a substantial improvement for Emacs users once it's stable and rolled out. Hoping it can be released with Emacs 28 or 29 at the latest :).
How could native code solve that?
Guile at least could.
As a guiler I want Emacs to be guile-based, but I totally understand the Emacs POV: guile is an external dependency with unsecure maintainership.
Guile Emacs was the work of one (very talented) guy. He's moved on to other things, but it's not inconceivable that another Guile fan will pick up the torch some day.
If enough Guile/Emacs fans get together this might actually turn in to a viable, maintainable project... this is, after all, how Neovim started. Just some people who were unsatisfied with where Vim itself was going, and teamed up to make their alternate vision a reality -- with great success.
Guile Emacs work is actually a much smaller task than Neovim, as Neovim's authors rewrote Vim from scratch, whereas Guile Emacs has a much more humble aim of simply allowing eLisp to be hosted on the Guile VM.
It could still happen.
The problem with integrating it is that you need someone with good knowledge about guile (since the elisp implementation is pretty bad currently) but even more important: someone who know Emacs internals (not many).
Anyway, while elisp might not be the fastest language around, it's not the origin of all slowness in emacs. Crufted design is also a big culprit. The dated regex-machine is often mentioned as a big problem, making syntax highlighting especially painful.
Though I'm not a Rust fan, and would infinitely prefer Guile Emacs, I am kind of half-hoping Remacs succeeds so Emacs can finally put all of that legacy C behind it.
Multi-second lag on type and navigating isn't acceptable. Org-mode is especially bad.
I ended up going in the other direction: kept emacs, got mostly rid of windows (I have it in a VM for the odd occasion where I need to use a windows-specific program. The fact that my company is flexible on the work OS is a huge bonus for me.
Nobody is being forced to use a particular style and color scheme and we don't have repeated redesigns which remove functionality for the sake of user friendliness or minimalism.
C-Z (in the GUI) triggers minimise of the window.
In a shell, that's fine. It suspends the process. In a GUI it is just bloody annoying. There's a perfectly good minimise button if I want it. This is just a frustration every time I fat-finger C-X. Which is used so frequently it's just asking to be pressed by accident.
(when window-system
(global-unset-key (kbd "C-z")))Emacs has the idea of _buffers_ which are the actual window panes that you can view. The _buffer_ has data in the form of text which has properties in much the same way a block of html can have properties. An emacs-lisp function has full access to do anything it wants with the buffer. For example it can insert contents, change the font family, change the bit of text into a button with a callback. This is exactly how syntax highlighting/semantic highlighting works in emacs, you just change the styling for bits of text [1].
A _mode_ inside emacs is a collection of emacs-lisp functions which trigger (usually on a file extension name). Typically they will set certain keybindings for specific mode-like behaviour. You always have a single _major_ mode and multiple _minor_ modes - the vim emulation layer, for example is simply a minor mode which adds the vim keybindings and emulates the vim state machine inside emacs-lisp.
> It seems like each script is registering commands it can run in context of mode
An emacs-lisp file can be _evaluated_ in the same way as a python file into emacs. It's like a REPL - you can evaluate a file and the functions become available. There's a bit of extra behaviour which allows lazy loading et cetera, but user defined scripts are first-class and there's no distinction between them and those which are "native".
> updating of values
You can update a variable by simply evaluating the appropriate lisp function. If you want to update a value in the text buffer, you just replace/rerender that chunk.
> handling async requests
A buffer can also have a _process_ running which gets events each time the buffer is updated. When you run a command, you direct the output to a buffer and you trigger your lisp function on certain events. This is sort of how the HTTP requests work, but there's libraries which abstract some of it for you. Buffers are really just an abstraction for textual data.
Some of this is simplified, but I hope it gives you a vague idea of what emacs is.
[1] https://www.reddit.com/r/emacs/comments/iemo44/wysiwygified_...
It's supported by text properties [1] and overlays [2]. Character properties are special attributes attached to a single character, while overlays can attach attributes to a "region" and override old text properties (like div in HTML).
In Emacs,
> A button is essentially a set of text or overlay properties, attached to a stretch of text in a buffer. [3]
The Emacs display engine is sorta like an HTML render engine.
[1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Te...
[2] https://www.gnu.org/software/emacs/manual/html_node/elisp/Ov...
[3] https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu...
So tell me about the UX of free software speech recognition in emacs. I want to read about how to set that up and the limitations of it as I watch my 5 year-old niece interact with Alexa.
What does "OT-ness" stand for ?