Live data from Hacker News

Emacs is special regarding UIs

lists.gnu.org

351–360 of 418 posts

Re: Emacs is special regarding UIs

#351
post #11

One begins to understand the advantages of this approach after 10-15 years or so. 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. Whe…

Sometime I also get in a pessimistic mood. I really would like to convince myself that X11 is not going away in the next decades.

Esoteric hardware won’t work first, then maybe browsers. I’d estimate 15 years.

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.

Re: Emacs is special regarding UIs

#352
post #215

Earlier quoted context omitted.

Despite having felt this way about so many things, I have never seen this argument put so well and succinctly. I am going to be using this ALL THE TIME. 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."

Please do not so blithely invoke disability just because someone removed the feature you cared about. It sucks, but I promise you navigating the world in a wheelchair sucks a lot more. 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 disa…

Hey, this is not a contest about who had the crappiest life, and if it was, I can assure you that there are things in life that suck more than navigating the world in a wheelchair, and I’m not asking people to stop complaining about that just because they happened to me.

Anyways, replace wheelchair users with pregnant women, or old people. Ramps help them too, and the argument is still valid.

Re: Emacs is special regarding UIs

#353
post #315

Earlier quoted context omitted.

Thanks to Chrome which saves the zoom settings per domain, I have "configured" every site I read to be at the same size (125% for most of them, 110% for some, 200% for monsters who put a very small font). 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.

Chrome has a "minimum font size" setting that overrides websites that use small fonts. I set my minimum high (16 normal, 14 minimum) and haven't run into any breakage. (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...)

IIRC, in typography, a point is 1/72th of an inch.

I don't think desktop computers, with the possible exception of the NeXT, ever respected that.

Re: Emacs is special regarding UIs

#354
post #82
post #73

Earlier quoted context omitted.

> The shift away from X11 means no more forwarding X11 applications over ssh, which is slow at best and buggy and insecure at worst. 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

Honestly, I think people's reliance on X forwarding is just due to the fact that it happens to exist, not because they really need it. There's nothing like X forwarding on Windows to my knowledge. If X forwarding didn't exist people would have figured out how to do what they needed over SSH with text or when GUI's are irreplaceable sysadmins would have set up an actual remote desktop solution like on other modern ope…

> Honestly, I think people's reliance on X forwarding is just due to the fact that it happens to exist, not because they really need it.

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.

Re: Emacs is special regarding UIs

#355

Earlier quoted context omitted.

As a long time emacs user, I can confirm that emacs is terrible... and everything else out there is deficient. I can write custom code (ew, elisp) to determine how to switch between buffers (test buffer and code under test) and I can run my tests and find operations and the like in a first class buffer and a dozen things like that which are just incredibly painful in other editors. Also I hit Cx-c by mistake thrice a…

Run Emacs as a server. You can kill the client accidentally, then just load another client instantly and carry on from where you left off.

Exactly.

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

Re: Emacs is special regarding UIs

#356
post #332

Earlier quoted context omitted.

"The Emacs and Vim ... are outclassed by modern IDE" 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 s…

If you're not a professional Lisp developer, an environment extensible in Lisp is not a plus :-)

I've had colleagues who were dedicated Emacs users, yet didn't know anything about Lisp.

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

Re: Emacs is special regarding UIs

#357
post #331

Earlier quoted context omitted.

> Your complaint on the documentation reads oddly. You do know there is a tutorial included, right? 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.

But this was my point. Most of the documentation is a reference manual. Is why I referenced the user's manual for a car. You will not be using that to learn how to drive a car. Nor will you use it to learn how to build or maintain one, really. 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.

VSCode/Atom/Sublime all operate broadly the same way. To continue the car analogy, there's a wheel right in front of you, two or three pedals by your feet and a gear stick next to you.

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

Re: Emacs is special regarding UIs

#358
post #299
post #264

Earlier quoted context omitted.

Yes, you don't need Emacs or Vim to be a successful software engineer. If you are good enough you don't need anything more than a basic editor, a compiler/interpreter for a language, and libraries for that language that let it talk to whatever you need to do I/O with. 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 s…

You've misunderstood me. I'm not arguing that Notepad + msc.exe are more powerful than Emacs or Vim. 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,…

You might be talking about that JavaScript rewrite of Visual Studio that uses the Electron framework.

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.

Re: Emacs is special regarding UIs

#359
post #332

Earlier quoted context omitted.

"The Emacs and Vim ... are outclassed by modern IDE" 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 s…

If you're not a professional Lisp developer, an environment extensible in Lisp is not a plus :-)

Rubbish. Speaking as someone with seventeen-odd years of professional C# experience and no professional Lisp experience, Emacs Lisp is both easier to learn than the Visual Studio SDK and, more importantly in the long run, far more likely to be worth the bother[1] for personal use cases.

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

Re: Emacs is special regarding UIs

#360
post #357
post #331

Earlier quoted context omitted.

But this was my point. Most of the documentation is a reference manual. Is why I referenced the user's manual for a car. You will not be using that to learn how to drive a car. Nor will you use it to learn how to build or maintain one, really. 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.

VSCode/Atom/Sublime all operate broadly the same way. To continue the car analogy, there's a wheel right in front of you, two or three pedals by your feet and a gear stick next to you. 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? P…

I think that is being deliberately unkind to emacs. It would be closer to comparing it to a car designed 30 years ago in a country that drove on the other side of the road. Most all of the major points are the same, just in a different location.

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

Post reply on HN