Emacs is special regarding UIs • Hacker News Board

Re: Emacs is special regarding UIs

#331

Post by taeric » Thu, Sep 10, 2020, 8:32 PM UTC

BeetleB wrote: post #298

taeric wrote: post #277

Earlier quoted context omitted.

Your complaint on the documentation reads oddly. You do know there is a tutorial included, right? And, it mostly does what you are asking. You can even try to speed run through it occasionally to make sure you still remember everything. 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 l…

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

Re: Emacs is special regarding UIs

#332

Post by oblio » Thu, Sep 10, 2020, 8:33 PM UTC

pmoriarty wrote: post #321

oblio wrote: post #299

Earlier quoted context omitted.

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,…

"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 :-)

Re: Emacs is special regarding UIs

#333

Post by jberryman » Thu, Sep 10, 2020, 8:38 PM UTC

sn41 wrote: post #254

dhosek wrote: post #213

Wow, it's interesting how many people seem to have their own takeaways from this, many of which seem to have missed the original point of the post (I wonder how many actually read the post). The author of the post on gnu.org is blind (and the "Raman" he referred to is T. V. Raman, a blind mathematician who I met ages ago when he gave a presentation at the Portland TeX Users Group meeting about adapting TeX for presen…

It is an interesting historical note that T. V. Raman won the ACM best doctoral dissertation award as a blind scholar [1]. I take an active interest in accessibility partly because my wrists hurt. Technologies initially meant to help blind people have turned out to be useful for people with other conditions as well. [1] https://awards.acm.org/award_winners/raman_4110221

Are there any particular technologies that have helped you with your wrist issues?

Re: Emacs is special regarding UIs

#334

Post by Spivak » Thu, Sep 10, 2020, 8:41 PM UTC

pmoriarty wrote: post #199

Spivak wrote: post #163

Earlier quoted context omitted.

Right, the shift away from X doesn't mean the death of using GUI apps remotely, it just means moving to a Remote Desktop model instead of telling apps that their render target is your X server through a tunnel.

Could you flesh this out a bit? What is the official Wayland model for doing "Remote Desktop"?

I hesitate to call it an official model but the short version of the current direction is that the compositor acts as the glue -- providing the final rendered scene and the final merged audio stream to the client over some protocol (like VNC but doesn't have to be) and providing inputs and events to itself and the client applications.

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.

Re: Emacs is special regarding UIs

#335

Post by bartread » Thu, Sep 10, 2020, 8:43 PM UTC

taeric wrote: post #327

bartread wrote: post #292

Earlier quoted context omitted.

> Your complaint on the documentation reads oddly. You do know there is a tutorial included, right? And, it mostly does what you are asking. You can even try to speed run through it occasionally to make sure you still remember everything. 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…

I'm not sure I follow. As a power user of computers for years, I would be a liar if I said any of those programs were "quick to get running." Speaking as someone that is getting my kids up and running with computers. Training and tutorial running are the norm and should be. Expecting proficiency in anything with less than a few hours is an exercise in pain. If you want there to be a new tutorial, I don't know anyone…

What I'm trying to say is this: I can pick up almost any text editor and be productive immediately, even if I've never used that editor before. That is manifestly not true with emacs (or vim). Getting back to my point about the emacs documentation, it is simply not optimised to get me productive in the way I can be with other editors anything like as quickly as I can become productive with those editors.

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.

Re: Emacs is special regarding UIs

#336

Post by taeric » Thu, Sep 10, 2020, 8:55 PM UTC

bartread wrote: post #335

taeric wrote: post #327

Earlier quoted context omitted.

I'm not sure I follow. As a power user of computers for years, I would be a liar if I said any of those programs were "quick to get running." Speaking as someone that is getting my kids up and running with computers. Training and tutorial running are the norm and should be. Expecting proficiency in anything with less than a few hours is an exercise in pain. If you want there to be a new tutorial, I don't know anyone…

What I'm trying to say is this: I can pick up almost any text editor and be productive immediately, even if I've never used that editor before. That is manifestly not true with emacs (or vim). Getting back to my point about the emacs documentation, it is simply not optimised to get me productive in the way I can be with other editors anything like as quickly as I can become productive with those editors. Of course yo…

And my point is that you have plenty of other training in those editors you are ignoring. Not out of malice, but because it is second nature. You have done a ton of training on them already.

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

Re: Emacs is special regarding UIs

#337

Post by wazoox » Thu, Sep 10, 2020, 9:00 PM UTC

jwr wrote: post #198

hpfr wrote: post #62

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. A small price to pay for eliminating tearing and actually-secure screen locking. There are valid criticisms of the move to Wayland but I don’t really think this is one of them; if you really need remote access to graphical applications you almost certainly should not be using X forwarding…

> no more forwarding X11 applications over ssh, which is slow at best 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.

Yup. Today I have internet access faster than the LAN I used in the 90s and I routinely remotely run apps on my office desktop computer, reading my email, etc. from home. It works perfectly fine for anything not too graphically intensive, and it's way faster than starting a remote desktop session (which I use at times, too).

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

Re: Emacs is special regarding UIs

#338

Post by seba_dos1 » Thu, Sep 10, 2020, 9:09 PM UTC

pmoriarty wrote: post #302

voldacar wrote: post #291

Earlier quoted context omitted.

Performance too. Wayland adds at least one extra frame of latency and so is unsuitable for gaming and similar scenarios where one program needs to monopolize the framebuffer

Is that extra latency an inherent limitation of how Wayland is designed, or could future optimizations improve Wayland so that its performance is on par with X?

> Is that extra latency an inherent limitation of how Wayland is designed

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.

Re: Emacs is special regarding UIs

#339

Post by seba_dos1 » Thu, Sep 10, 2020, 9:13 PM UTC

pmoriarty wrote: post #208

swiley wrote: post #54

Earlier quoted context omitted.

I really honestly don’t like X11. I’ve poked around in the source a couple times and it confuses and scares me. I love the idea of moving entirely to just one graphics API and keeping the server simple. 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…

"I love the idea of moving entirely to just one graphics API and keeping the server simple" 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, ara…

It depends on the used compositor. In the wlroots land, everything you mentioned is already possible.

Re: Emacs is special regarding UIs

#340

Post by morelisp » Thu, Sep 10, 2020, 9:30 PM UTC

jrm4 wrote: post #215

sildur wrote: post #129

Earlier quoted context omitted.

Wheelchair users are also pretty unusual and we don’t go removing ramps from everywhere. I’m growing pretty tired of the “your use case is unusual, so fuck you” argument.

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 disabled people, mostly bad.