The Modernization of Emacs: terminology buffer and keybinding

[Twisted]

On Jun 24, 8:10 am, Martin Gregorie <mar... at see.sig.for.address>
wrote:
> > Actually, what I prefer in (2D and 3D) visual design apps is the
> > ability to snap to some kind of grid/existing vertices, and to zoom in
> > close. Then small imprecisions in mouse movement can be rendered
> > unimportant.
>
> That might work for visual design apps, but it doesn't for CAD, where
> you may want to point to an arbitrary position with a (scaled) accuracy
> of microns.

I didn't mention that you should be able to zoom and make the grid
fine to whatever limit is reasonable given the application? The issue
being, how accurate is "accurate enough"? Pinpoint precision isn't
possible, unless it's an integer or a functionally derived value like
pi or some arithmetic result of that. Grids are good for getting
rational numbers exactly, and nothing will hit the irrational ones
exactly, save if you can enter a formula for it to use to compute the
point's location to any desired precision. A mouse click (sans grid)
will always introduce some error; the zoom level lets you limit the
magnitude of the error. So does a grid, and to zero if the desired
point is a grid vertex, and to half the grid size more generally.

> The fact remains that mechanical mice do jump when you click them,
> though optical mice are better in this respect.

Ultimately, the button has to be non-mechanical for this sort of thing
to really work. Or else not physically part of the mouse. Being able
to "click" from the keyboard makes sense given such requirements. So
does being able to snap to a grid.

> > The problem of course being the complete exclusion of type 1 users.
>
> Totally untrue.

I'm not talking about in general. I'm talking about the specific sorts
of unixy applications that are under discussion here. Those
emphatically cater solely to type-3s and type-4s, aside from newer
graphical apps for KDE and Gnome, which are emerging as a third group
of type-1-accessible tool alongside Mac applications and Windows
applications.

> Thats not true and never can be: a computer is
> the most complex device the average person will own or use and is likely
>   to retain that title for the foreseeable future.

What about the fabrication devices? Oh, but I suppose the "foreseeable
future" has already ended by the time those trickle down to widespread
consumer use.

> I grant you that type 2 users are rare, but I think flight simulators
> may fit this case when  used for training.

Anything you have to use to meet some important external goal, I
suppose. But most usually there are options. A programmer needs a text
editor but it need not be emacs. Jobs requiring the use of specific
software (for training, or just on the job) maybe, of which your
example is a subset.

> Not really. What's needed is a single interface that can be used by
> anybody from beginner to expert and that, in the case of an error, shows
> precisely where it got, what caused the action to fail to complete and
> that allows the user to continue from that point without having to
> undo/redo the bits that were successful. Its not easy, but it can be done.

Why do those who have the skills, talent, knowledge, and thus
capability to do this insist on making cruft like emacs then? I've
never seen a classic-unix tool that didn't barf unhelpful and
uninformative error messages at the drop of a hat (just like Windows!)
and present a piss-poor UI, or even no UI at all (unless "usage: blah
blah blah" qualifies as a UI, to which my response is one word. "Non-
interactive.") When the error messages are informative, they're still
cryptic, and only someone with knowledge of the software's internals
has a hope in hell of fixing the problem as a rule. Of course, the
number one rule of interface design is to speak the user's language
and the language of the problem domain, and remain mute (except to
developers invoking debug modes) about the implementation details and
the language of the solution domain. Especially given that a different
version of the same software, nevermind a different app with the same
usage, is probably going to use a different implementation anyway. One
exception can be to expose a specific scripting language for advanced
users to use to automate tasks. Emacs does this, and it's one thing I
don't have a problem with. As long as knowledge of its arcana is not
needed to either do straightforward stuff, or fix the errors that
occur attempting to do straightforward stuff, anyway. If the beginner
can safely ignore the thing's existence (e.g. the VB-based scripting
language in some office and paint programs) it's fine.

> > ROM BASICs and QBasic (on any really ancient microcomputer, and old
> > pre-Windows PCs, respectively; the former came with printed manuals
> > and you could just run prepackaged software from disks very easily;
>
> Hang on: you don't read manuals. You object to using tutorials and to
> buying books, so its a bit precious to claim this example.

The manuals came with the computers, at no additional charge. It was a
different time. This isn't going to be true of any separately-
purchased book or user-made printout concerning emacs. Also, the
manuals provided a basic introduction for the beginning user. A
traditional-unix-tool providing anything resembling that would
genuinely shock me.

> > * The word processor with the usual interface where I can define
> > logical styles, then change them in only one place and affect every
> > pre-existing occurrence retroactively.
>
> Thats been in Word since DOS days and is part of OpenOffice. Its called
> a "style sheet".

I distinctly remember Winword circa 2002 not being able to
retroactively change all of a bunch of like-formatted paragraphs
easily. Not without delving into VBscript or something, anyway.

> You're thinking of Wordperfect and its 'Reveal Codes' function. That was
> the worst idea I've ever seen in a WP, matched only by the illogically
> arranged set of 12 function keys, each with 4 shifts.

Why?

> It didn't. 'Reveal codes' could only let you inspect the current
> document. Unfortunately it was essential to use it because some input
> sequences could completely mess up the formatting and the only way to
> recover was via 'Reveal codes'. The effect was similar to making a data
> entry clerk use a hex editor on a database to fix keyboarding errors.

Oh, because the implementation (of "reveal codes" and of everything
else) was awful, not because of any intrinsic flaw in the idea itself.

Would you want to edit a Web page without being able to hand-hack the
HTML? Use a GUI builder for Swing without being able to hand-hack the
Java? Thought not.

[Snip description of an advanced-for-its-time interface]

What happened to the guys that did all this stuff after it became
obsolete? Microsoft offer them $300 grand a year to mop floors or sit
in on various board meetings without a vote or something to get them
out of the way, being unable to use their talents competently and
equally unable to stand having them work for a competitor, or worse,
contribute to open source? Or offer a mob type $100 grand once to
whack them maybe?

> > The bog-standard alt, this, that sequences on Windows "come close";
> > they do make the menus display, but otherwise they do exactly what you
> > want, and you can ignore the menus blinking around in your peripheral
> > vision.
>
> No they don't: you can't easily string them together to act as a single
> command and the error diagnosis and reporting is remarkably poor. Same
> goes for Gnome, so I'm not particularly bashing Windows here.

You can string them together manually, or use a keyboard macro
recording and playback tool (they exist, though one doesn't come
standard with Windows; I think maybe one does with MacOS). It would be
nice if straightforward macro recording was standard in Windows
though.

On the other hand, I've not always been 100% sure of that sort of
thing. Even seemingly straightforward search-and-replace can suffer
from Sorceror's Apprentice Syndrome even at the best of times. And if
the thing treats every individual replace as a separate undoable
action instead of the one batch-of-replaces, and has a buffer of only
10 undos, and 13 items match, and one of them was unexpected and
shouldn't have been replaced...

Macro capabilities might be a dream, but macros running amok are a
nightmare. Maybe a real programmability would be better. I think the
scripting language capabilities in some apps provide that, with more
ability to control and constrain it from going into Sorceror's
Apprentice mode, but every app tends to have its own scripting
language and API and no real introduction-to-scripting type stuff,
leading us back to "the emacs problem" -- an arcane interface that
begins and ends in midair, with nowhere for the beginning user to
climb aboard, and differing from application to application so
limiting the value of investing much time in any one of them versus if
a single universal one were used (say Lua, or even elisp, or even
*gag* VB...)