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.

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.

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.

Things seems to be going backwards in this area..

[1] https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platf...

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...

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

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

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.

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).

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.

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...

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.

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.

Seems like such a fundamental use case that should be made simple but is ignored (or made very difficult) by modern systems.

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.

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.

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.)

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.

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."

if windows was enough for my needs I'd use it ?

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.

Which is why the people who need this functionality run Linux, not Windows.

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.

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."

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?

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.

You have absolutely no basis for thinking this.

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.

And screen tearing? Didn't SGI have that solved in the 90's?

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.

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)

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.

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...

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.

Directory Opus. I've used it for nearly 30 years. First thing I install on Windows.

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.

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_...

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.

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.

https://www.phoronix.com/scan.php?page=news_item&px=Microsof...

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.

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.

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.

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.

No, you are doing it wrong. Never need to see keyboard except when using touchbar thanks to no feedback.

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.

no

>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.

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...

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.

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.

https://news.ycombinator.com/item?id=24429493

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.

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’m a full-time python developer in the sciences and an emacs user and neither of those claims are true.

More’s the pity.

$ 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.

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?

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.

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-...

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.

    <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.

For me it's not even possible in a TTY.

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?

Sent from eww.

Sent from nnhackernews

Sent from `M-x hackernews`.

https://www.gnu.org/software/emacs/:

> [Emacs is] an extensible, customizable, free/libre text editor — and more

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).

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...

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/

[2] - https://github.com/emacs-lsp/lsp-mode/

This is not surprising; it's no different from Vim users who have never written or debugged a line of VimScript.

[1] https://xkcd.com/1205/

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.

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.

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.

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?

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.

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.

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 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.

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.

You could try Spacemacs. I've only just started seriously getting into Emacs, and have found Spacemacs to be a big help.

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).

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.

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.

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. :(

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.