The Modernization of Emacs: terminology buffer and keybinding

Martin Gregorie martin at see.sig.for.address
Sun Jun 24 08:10:52 EDT 2007


Twisted wrote:
> On Jun 23, 10:36 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.

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

> * 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,
> whosit-viewing,
 >
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
> 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.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |



More information about the Python-list mailing list