Emacs is special regarding UIs • Hacker News Board

Re: Emacs is special regarding UIs

#261

Post by rpdillon » Thu, Sep 10, 2020, 3:55 PM UTC

fierarul wrote: post #179

eatmygodetia wrote: post #101

Earlier quoted context omitted.

In Emacs's defence, it didn't reimplement everything so mich as implement it first. When there's very little prior work to go on, often parts of the design won't be great, and then it becomes hard to move away from them.

Interesting how somebody else claimed about the same thing. 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. :-)

I think a lot of folks value having their apps 'fit into' their OS. For me, I see the constant churn in desktop OS patterns as tiring and essentially useless. Emacs provides a wonderfully consistent interface no matter where I run it. I can see how it seems foreign to others, but it is consistent. For me, that's a fantastic trade.

Re: Emacs is special regarding UIs

#262

Post by billfruit » Thu, Sep 10, 2020, 3:56 PM UTC

GuB-42 wrote: post #159

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…

At work, we do X11 forwarding all the times. We have a wide variety of UNIX machines and we often need to run several graphical applications from different machines (not a remote desktop). 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…

Not just Electron, even QT as well performs horrible over X11 forwarding in recent versions...

Things seems to be going backwards in this area..

Re: Emacs is special regarding UIs

#263

Post by donio » Thu, Sep 10, 2020, 3:56 PM UTC

Spivak wrote: post #163

II2II wrote: post #158

Earlier quoted context omitted.

The happens to exist bit turns out to be very important. I can login to a machine and run an X client without installing and configuring extra software on the server. If I am using a desktop with X installed (most *ix based systems), there is no extra software to install and configure on that end either. The worse case scenario is the necessity to install an X server on platforms like macOS and Windows. The same sort…

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.

What if I don't want a remote desktop though? 99% of the time I only want a the remote application I am interested in to seamlessly display on my screen, why do I have to bring along a full desktop?

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

Re: Emacs is special regarding UIs

#264

Post by tzs » Thu, Sep 10, 2020, 3:58 PM UTC

oblio wrote: post #234

tzs wrote: post #200

Earlier quoted context omitted.

I think that tools like Emacs and Vim are aimed at people who recognize that very often over the next few decades of their careers they are going to have a need for powerful, complex, flexible text editing, and so even if they have no interest in learning the software for its own sake its worth putting in the up front effort because it will pay off later. For a lot of tools, both in software and other fields, there a…

The thing is, you need AutoCAD (or equivalent) to be a productive engineer in certain fields. 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…

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 some repetitive task in a simple editor that would have been quicker in a more powerful editor adds up.

Re: Emacs is special regarding UIs

#265

Post by GuB-42 » Thu, Sep 10, 2020, 4:01 PM UTC

kej wrote: post #253

GuB-42 wrote: post #159

Earlier quoted context omitted.

At work, we do X11 forwarding all the times. We have a wide variety of UNIX machines and we often need to run several graphical applications from different machines (not a remote desktop). 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…

Idle curiosity: what kind of applications are these remote systems running? You mentioned the aeronautic industry but I'm not familiar enough with it to imagine the kinds of things you would need to run remotely.

A big one is a test tool for avionics running on Solaris. We are retiring it but some test procedures still require a specific version of it. And we don't want to update (and recertify) these procedures.

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

Re: Emacs is special regarding UIs

#266

Post by mrob » Thu, Sep 10, 2020, 4:03 PM UTC

hpfr wrote: post #99

fierarul wrote: post #12

I thought it will be a criticism how everything seems off with the Emacs GUI from the copy-paste to the font rendering to the way scrolling is done, etc. I'd guess it managed to be so cross-platform by re-implementing everything, kinda like Java Swing but with less care for design. Now I understand how having a scriptable and text-based foundation would help with accessibility, just Emacs wins no UI contest.

I don't know if I'd call it re implementation when the original Emacs is older than DOS and GNU Emacs, still maintained today, is older than Windows (1985). Emacs's keybindings, font rendering, and scrolling were just as valid then as any other approach. Let's at least avoid comparisons to Swing :). You can bind copy-and-paste as well as any other text wrangling functionality to whatever you want and there are ways t…

Scrolling is broken from the average user's point of view because it moves the cursor. If you're typing something, and then scroll to reference some other part of the document, you can't just start typing again after finding the information you need. You have to manually restore the cursor position or you'll end up typing in the wrong place. Unlike pretty much every other text editor, Emacs's concept of a cursor is something that lives in screen space, not document space. It's stuck in the VT100 hardware cursor paradigm.

Re: Emacs is special regarding UIs

#267

Post by twic » Thu, Sep 10, 2020, 4:04 PM UTC

skissane wrote: post #7

I can think of a few UI styles Emacs doesn't support (to my knowledge) – line mode terminals, block mode terminals (such as IBM 3270 and 5250), and HTML. 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 -batc…

Some time in the late '90s a friend and i sat down and tried to design a UI framework that could cover lots of styles. We started with GUI and line-mode terminal, but hoped to add curses and the web (1.0 of course, so using forms, not JavaScript). I didn't know about block-mode terminals at the time.

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.

Re: Emacs is special regarding UIs

#268

Post by pmoriarty » Thu, Sep 10, 2020, 4:20 PM UTC

bjoli wrote: post #20

melling wrote: post #3

Emacs Lisp is slow. There has been a multi-decade effort to make Guile support ELisp, and using Guile to make Emacs more performant. Cross platform UI, with a faster Lisp, would allow Emacs to be even more special.

Guile Emacs will never happen. Robin's work was amazing, but at it's absolute height guile Emacs was still a slower and buggier version of regular Emacs. I am pretty certain a full guile Emacs would be better than current Emacs (guile is actually a very neat little VM with lots of cool optimisations going on), but that is not where the reality is. As a guiler I want Emacs to be guile-based, but I totally understand t…

Never say never.

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.

Re: Emacs is special regarding UIs

#269

Post by antonvs » Thu, Sep 10, 2020, 4:23 PM UTC

oblio wrote: post #236

pmoriarty wrote: post #214

Earlier quoted context omitted.

Yes, the Emacs defaults tend to be pretty awful, but you can configure it your liking, given enough time and effort. 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 custo…

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

> Emacs itself could come with reasonable defaults.

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

Re: Emacs is special regarding UIs

#270

Post by freeone3000 » Thu, Sep 10, 2020, 4:24 PM UTC

hpfr wrote: post #62

jwr wrote: 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…

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…

You've listed disadvantages of an existing system but haven't listed an alternative. What should we be using for remote access to graphical applications?