The Modernization of Emacs: terminology buffer and keybinding
martin at see.sig.for.address
Sun Jun 24 14:10:52 CEST 2007
> On Jun 23, 10:36 am, Martin Gregorie <mar... at see.sig.for.address>
> 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
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
The fact remains that mechanical mice do jump when you click them,
though optical mice are better in this respect.
> The problem of course being the complete exclusion of type 1 users.
Totally untrue. They are the people that all the standard GUIs are
designed for and some (e.g Mackintosh) are very fast to learn. The
exclusion is down to the way that the purveyors of GUIs keep spreading
bullshit about how any untrained person can use a computer and never
mess it up or loose data. 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.
I grant you that type 2 users are rare, but I think flight simulators
may fit this case when used for training.
> One with a bog-standard UI but also a "console" or command prompt,
> scripting language, and customizable bindings?
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.
> 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 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". The only WPs I've used that didn't use them were
Wordperfect, WordStar, DEC WPS+ and the Wang dedicated WP systems. All
were horrid to varying degrees, with Wordperfect and Wordstar tying for
> * The word processor with the usual interface where I can also view an
> underlying markup representation and hand-hack that,
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.
> and which likely has the capabilities of the first two as a direct
> consequence of the implied architecture.
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.
NOTE: I'm not talking about secretaries using WordPerfect. Those that
used it hated it. I'm talking about the experience of IT professionals
writing structured text, e.g. system specifications.
> * The operating system where you can do powerful stuff with a command
> line and a script or two, but can also get by without either. (Windows
> fails the former. Linux fails the latter.)
Here you're talking about two different interfaces again. The nearest
I've seen to good solutions at OS level were the CL interface provided
by ICL's VME mainframes and IBM's AS/400 systems. The latter was
particularly good, with a single unified text screen interface which
provided help screens, menus and a command line. You could search for
and find commands via a menu structure, and then use form filling to
provide the arguments, with help available at any stage. If you were
writing a script the entire menu and form filling system was available
from within the text editor - but when you hit ENTER the completed
command was written into your script instead of being executed.
Both OS/400 and VME were very consistent in the way they assigned
command names and argument keywords. In both OSen it was possible to
think "if there's a command to do this it will be called BLAHBLAH", type
the name, hit the command completion key and have the argument entry
screen pop up ready to be filled in.
BTW, in both OSen this capability applied to user-written scripts and
programs as well as to the standard command set. Both could claim to be
object oriented: the VME command language was derived from Algol-68,
arguably the granddaddy of all OO programming languages.
> * For that matter, the operating system whose GUI takes the concept
> behind OLE to its logical conclusion, and lets the user separately
> choose and configure their text editing, this-editing, that-editing,
The AS/400 editor did exactly that. There was only one, but it swapped
personality to match the task and was language-aware as well as
application aware. It produced form-filling interfaces to help you write
command scripts. If you were writing a program it gave language-specific
prompts and could run syntax checks on each statement as it was entered.
If you didn't want any of that, it would just quietly accept input like
any other text editor.
> 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
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.
martin@ | Martin Gregorie
gregorie. | Essex, UK
More information about the Python-list