Path: utzoo!mnetor!uunet!husc6!mit-eddie!"SDRRTR::SDRRTR::MRGATE::\"MRGATE::PSI%SCRVX2::BLUE::IN%\"davis@blue.sdr.slb.COM\"\""@sdr.slb.COM
From: "SDRRTR::SDRRTR::MRGATE::\"MRGATE::PSI%SCRVX2::BLUE::IN%\"davis@blue.sdr.slb.COM\"\""@sdr.slb.COM
Newsgroups: comp.emacs
Subject: function-keymap: criticism
Message-ID: <8805081852.AA27501@EDDIE.MIT.EDU>
Date: 7 May 88 13:44:00 GMT
Sender: daemon@eddie.MIT.EDU
Lines: 105

Return-path: davis@ruby
Received: from ruby.colour.uucp by blue via TCP; Sat May  7 00:14 GMT
Received: by ruby.colour.uucp (3.2/SMI-3.0DEV3) id AA23068; Sat, 7 May 88
 00:06:40 PDT
Date: Sat, 7 May 88 00:06:40 PDT
From: davis@ruby
Subject: function-keymap: criticism
To: outinfognu@blue
Reply-to: davis@blue.sdr.slb.com
Message-Id: <8805070706.AA23068@ruby.colour.uucp>
Organization: Schlumberger Cambridge Research
Snail: PO Box 153, Cambridge CB3 0HG, England
Phone: [+44] (0) 223 325282

Software Hoarding: Just Say No
Memo: To shatter tradition makes us *feel* free...



	Some comments on the use of function-keymap in terminal
	set-ups.

	1) The effective use of function-keymap is restricted to
	   keyboards that already have clearly established labelling
	   of their keys. Any attempts to map, for instance, a Sun
	   keyboard onto the standard function-keymap slots would be
	   utterly arbitrary. 

	2) function-keymap pushes users in the direction of yet
	another level of mapping. Instead of going direct from
	"what-it-says-on-the-key" to "what-I-want-it-to-do", they
	first must discover what function-keymap slot the key has.

	      example: someone wants PF1 on a VT100 to be bound to
	      save-buffer. To use function-keymap, s/he must know that
	      C-a is the slot for PF1 in this keymap. Why on earth
	      should such a mapping exist ? Why should PF1 be mapped
	      to C-a ? (well, ok, why not, but that's hardly an
	      answer, especially when F1 and PF1 on a VT200 map to
	      very different keys -- its not even the `1' that
	      counts!!).

	3) The essential feature of customized function keys is not
	labelling but *geometry*. No-one is interested in knowing that
	the `first' function key maps to C-a and has a default binding
	of foo-bar: what's desired is saying "the top left function
	key does x". function-keymap does not offer this facility, and
	indeed, no default set-up via a standard keymap ever can....

	4) Confronting people with lambda syntax on their first effort
	at Emacs customization has its drawbacks.

	(setq term-setup-hook '(lambda ()
				  (load "my-emacs-keys")))

	is not utterly transparent to early users, especially
	non-hackers.

	5) Why, oh why, is M-[ bound to backward-paragraph. How many
	keyboards with function keys are there that *do not* use this
	as an escape sequence ? Especially given the ANSI standard for
	cursor arrows...... 

	6) Terminal setup files (vt100.el, sun.el) should contain *NO*
	defuns !! Why should anyone have to lose functionality because
	their site manager didn't preload the defuns, and they decided
	to go for:

	      (setq term-file-prefix nil)
	      (load "my-emacs-keys")

	7) The basic message is -- who *wants* terminal independent
	keyboard bindings ? As indicated above, it is geometry and not
	labels that govern customization, and standard keyboard
	geometry is a long way off, if even desirable....
	      
	8) One solution, in use here at SCR, is a keymapping utility
	that maps from real function key labels to actual keyboard
	escape sequences. Writing C code (or even e-lisp code) to do
	this for any given terminal is a doddle, if messy,  and means 
	that no-one need use a .ttyswrc again (Ian B. - honest, its a
	nice idea, F1 mapped to ESC*F1 but is this is the road to 
	portability ?) Whether this sits inside Emacs (eg;
	map-key-buffer), or outside (eg; % emap > my-emacs-keys) is
	irrelevant, but at least this solution presents a uniform
	interface for any terminal (once ReWrite has
	been coded, anyway).


	Ok, ok, enough self-advertisment. What comments does the gnumacs
	list have on this ? On the part of the code, vt100.el uses
	function-keymap, sun.el and the rest don't. Anyone have any
	arguments to support `independence by label' ? My experience
	of GNU so far has been that most experienced users don't
	really care about function keys, whilst most beginners, faced
	with `C-M-cokebottle-ESC-c C-x g' tend to reach for F1. This
	should be sorted out.

	Paul Davis 
	Schlumberger Cambridge Research,
	Cambridge, UK.