csw@ulysses.UUCP (Chris Warth) (03/01/85)
[ This discussion should really be moved to a group concerned with editor or user interfaces. Net.emacs is a little too restrictive. Perhaps net.chi or net.misc?] >From: john@moncol.UUCP (John Ruschmeyer) >Subject: Re: h,j,k,l in vi >Message-ID: <200@moncol.UUCP> >>From: friesen@psivax.UUCP (Stanley Friesen) >>Message-ID: <338@psivax.UUCP> >> >> But 'vi' *doesn't* force h,j,k,l cursor control on you. >>Every version of it that I have ever seen also supports the *real* >>arrow keys on terminals that have them. Why not use them if you >>don't like the ADM3-a approach. >> >Not quite- to be specific, 'vi' will use the arrow keys provide that your >terminal transmits some code or another when you press them. Many terminals >(P-E 1200's) treat the arrow keys as a local command and do not send them >to the host. > Even if you terminal *does* send a code for each of its arrow keys, you >may still not be able to use them in 'vi'. One of the arrow keys on my >TRS-80 Model 100 sends a code which is apparently reserved in 'vi'. (I >think it is ^_ .) Whenever I use it, I get a 'no tags file' error message. >-- >Name: John Ruschmeyer >US Mail: Monmouth College, W. Long Branch, NJ 07764 >Phone: (201) 222-6600 x366 >UUCP: ...!vax135!petsd!moncol!john ...!princeton!moncol!john Come on people! This discussion is absurd! Every screen editor I have seen (including vi) allows you to remap functions to to almost any key sequence you like. I can only speculate that ^_ does not work on your TRS-80 because of a bogus termcap entry; not because vi reserves keys. You may choose to 1) fix the termcap entry or 2) use a .exrc file to remap certain key sequences. Unfortunately due to vi's brain damage, you will inevitably lose some functionality when you map functions to key sequences that already mean something. Remapping functions in a screen editor is one of the most useful features available. It really burns me up when some clown says "editor X is better than editor Y because editor X uses mneumonic key mappings." Balderdash! If you do not like the function mappings in editor Y, change them! Function mapping is really very easy for novices to understand, and I feel it should be one of the first things people see when learning about a new editor. [WARNING! DIGRESSION BEGINS HERE!] However, I must make allowances for those people using vi. Vi provides a method of mapping that I call "interpreted mapping". Interpreted mapping simply allows you to substitute one key sequence with another. When the first sequence is typed, the second sequence is inserted in its place and interpreted normally. This method has its drawbacks; in vi, it is not possible to map '^F' to some other command and still be able to scroll forward. There are two other orthogonal types of mapping, one of which vi supports. "Functional mapping" allows one to map any sequence of characters to a "function". An example would be "map ^F deleteline". Vi does not provide standard names for functions so it cannot provide this type of mapping. [One might argue that vi partially allows this facility by allowing you to map to #1. However, this type of request is turned into a normal interpreted mapping request with the escape sequence of function key #1 as the rhs.] "Literal mapping" is like interpreted mapping but the substituted text is not scanned for command characters. Vi provides this type of mapping in its abbreviation facility. These are really three distinct types of mapping and all three have their uses. Interpreted mapping is a poor man's macro facility; literal mapping serves as a useful abbreviation command; and functional mapping insures access to all the commands no matter how badly you screw up the keyboard with the first two types of mapping. As you can probably guess, screen editing a subject very near and dear to my heart. I personally use a version of the Yale Z screen editor written in C; William Cook [now a graduate student at Brown] and I wrote it as undergraduates. It has provide many years of hacking fun; always modifying, never documenting. We allow all three type of function mapping through the following syntax: <char_sequence>:<function name> functional mapping <char_sequence>:'<literal string>' literal or abbreviated mapping <char_sequence>:`<interpreted string>` interpreted mapping These serve almost every use we can think of, but this is not the final word in function mapping. We also have a powerful and compact command interpreter that distinguishes between commands mapped to a common prefix. How this works in practice is a little long to go into here, but I would be glad to respond to individual queries. In addition we would like to provide a mapping facility that is a combination of all three of the basic types. Such a mapping might look like the following in Backus Naur form: <sequence> => any character sequence with appropriate use of '\' before spaces and ':'. <basic type> => <function name> |'<literal string>' |`<interpreted string>` <mapping> => <sequence>:<basic type>[,<basic type>] We do not currently support this but it would be relatively trivial to add. Now we can compare editors (and other screen oriented tools) by the functionality they provide, *not* through their changeable user interfaces. I would argue against vi (and emacs, for that matter) not because of the default function mappings, but because of the awkward text abstraction each of them uses. Also vi is deficient in the areas discussed above. I am often saddened by the fact that vi was the first screen editor on the UNIX scene. Now I see a whole class of tools coming out with he identical deficiencies as vi in the name of backward compatability. And so it goes... Chris Warth ATT Bell Labs MH 5J-106 Murray Hill, NJ [ihnp4,allegra]!ulysses!csw
robert@gitpyr.UUCP (Robert Viduya) (03/02/85)
>< Posted from csw@ulysses.UUCP (Chris Warth) > However, I must make allowances for those people using vi. Vi > provides a method of mapping that I call "interpreted mapping". > Interpreted mapping simply allows you to substitute one key sequence > with another. When the first sequence is typed, the second sequence > is inserted in its place and interpreted normally. This method has > its drawbacks; in vi, it is not possible to map '^F' to some other > command and still be able to scroll forward. Um, sorry, but you can map ^F and still be able to page forward. You just have to set noremap. I just tried it and it works. Here's what I typed: :set noremap :map ^F ^G :map ^A ^F This set control-F to show what file you're editting and where. Control-A is now the page forward key. robert -- Robert Viduya Georgia Institute of Technology ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert