Re: What improvements would be truly useful?

[Eli Zaretskii]

> From: Yuri Khan <address@hidden>
> Date: Tue, 6 Mar 2018 14:48:39 +0700
> Cc: Daniele Nicolodi <address@hidden>, Emacs developers <address@hidden>
> 
> One architectural decision that I would call baroque is the input model.

Then we have different interpretations of what "architecture" means in
this context.  To me, architecture of a program such as Emacs is its
model-view-controller structure, the single-threaded operation, etc.
Input model is a lower-level design and implementation layer.

> In Emacs, the input model is that of the character terminal: the input
> is a sequence of characters. The repertoire of Unicode characters is
> extended with special values for function and editing keys, and for
> keys modified with Ctrl, Super, Hyper, and Shift where necessary (and
> Meta is represented as an ESC prefix), but still it is a sequence of
> characters without explicit ties to the keys. Even mouse clicks are
> processed as a special kind of characters.

Unless I misunderstand what you mean by "character", the above is
simply not true.  In Emacs, input is a stream of events.  Several
kinds of events are supported, see enum event_kind in termhooks.h.
Only some of them are characters, most are not.  The relevant variable
in keyboard.c is frequently called 'c', so one could think it's a
character, but in fact it is a Lisp object, and can be anything.  In
particular, a mouse click doesn't look at all like a character, it is
actually a cons cell.

> This is inevitable when running in a terminal emulator where the
> underlying abstraction works this way, but in a GUI build this leads
> to inability to distinguish, for example, the ‘.’ character as coming
> from the bottom-row right ring finger in US English layout, or from
> the bottom-row right pinky in Russian layout, or from the decimal
> separator key on the keypad.

That is a different issue, unrelated to what kind of input events are
recognized and how they are represented.  Emacs does support function
keys on X and other GUI environments, so it could potentially support
any abstraction for keys, if the underlying GUI APIs allow that on the
X message level.  We even install a low-level keyboard hook on Windows
to salvage some of the keys that Windows insists on intercepting ahead
of the application.

IOW, I see no architectural limitations here, only implementation that
might be missing or hard to come up with.

> Another example was described in Daniel Colascione’s article/rant
> “Buttery Smooth Emacs”.

Daniel's blog is a good read for someone who is familiar with the
internals, but I don't recommend to form your opinions about the Emacs
internals and their problems based solely on that blog.  For starters,
some of what is written there is no longer true these days.