TEDIT: New architecture for key bindings, plus better suggestions for initial window regions #2070
Conversation
This had a dependency on the separate PR
|
Is there in any of the sources of this change some table or list of the new TEdit keybindings? Are they the same as TEDITKEY? |
|
The default keybindings are on the list TEDIT.KEYBINDINGS. (The larger set of Tedit keyactions is the list TEDIT.KEYACTIONS--we don't have key assignments for all of those). These are not guaranteed to be the same as what was in TEDITKEY, which was kind of a snapshot in time of some of the keyboards. I kept the previously active bindings, tried to synchronize others with the 1108 bindings described in the Koto release document. If you want to add additional bindings, make a list with entries of the form (actionname charactername...) and pass it in to the function (TEDIT.INSTALL.KEYBINDINGS). I will provide more description in the Tedit release notes. |
|
Since I'm testing this PR, for the time being I just need a list of keybindings to exercise and If I understand correctly, When launching TEdit with no document argument, such as from the background menu, the initial window region is wide and thin with a limited editing area:
This is not a problem though as I can shape it to show a larger area. Passing a document argument to TEdit works well with the initial region and the margins. But, when opening or viewing a document rather than writing it from scratch, I usually make the TEdit window taller to fit more text. |
|
@pamoroso , for the empty document, and for any document that doesn't have or imply any useful margin information, I'll make it work the old way, sweep out an area. On the key mappings, I think there is still a confusion that I carried over in the names of these functions and variables. The confusion is between keys and characters. So, there is a mapping between actions and their implementations (currently called TEDIT.KEYACTIONS), a mapping between characters and actions (currently TEDIT.KEYBINDINGS), and separately, a mapping between manipulations of a physical keyboard and the characters that are thereby transmitted to the system buffers (the system keyaction tables). (The last is not the only way that characters can be inserted into the buffer--the screen-buttons operate by figuring out which characters from the Tedit bindings they can BKSYSBUF in order to trigger the associated actions.) To be clearer, I will get "CHAR" out of the TEDIT names: TEDIT.CHARACTIONS and TEDIT.CHARBINDINGS. With respect to your question about the particular characters like Function,103 or Meta,^B, what should happen if they are transmitted should be defined by their charbindings (if any). Function,103=Function,C may currentlymap to some action, inherited from the old tables, and that code may have been transmitted by hitting one of the edit-keys on a Dandelion keyboard. But there may not be an obvious way, or any way, of getting that character by operating on a modern keyboard. Meta,^B, on the other hand, is something that can be entered at the keyboard, and it was specified in the original Dorado charbindings for BOLD.ON . But I didn't install those bindings at loadup, one reason being that the relationship between the on and off toggles seemed a little odd. You might think that Meta,^b would turn bold on and Meta,^B would turn it off (shift generally meaning "not"), but control-x and shift-control-x for any x transmit the same character code. The convention for the Dorado charbindings seems to be that Meta,^B and Meta,^b both turn it on, and the adjacent-on-the right Meta,N/Meta,n turn it off. And similarly for I and O, etc. Are these keys always adjacent on international keyboards? I don't think those conflict with any of the other bindings, so I suppose no harm would be done by including them at the start. Would that be better? |
|
I actually don't have any specific preferences for bindings, as long as they work on my keyboard. My problem is I don't know what bindings do what. |
|
I can add another little interface function that provides a list of all the bindings in a given readtable. Maybe in both directions: for every key with a mapping in the table, what action it maps to; for every action with a mapping in the table, which keys map to it. The functions there now let you ask about one key or action at a time. |
|
I replaced KEY with CHAR to avoid the confusion with keyactions. I added functions TEDIT.GET.ALL.CHARACTIONS and TEDIT.GET.ALL.CHARBINDINGS, so you can get a list of all the keys that map to a given action and the key-to-action mappings of all the keys in a readtable. I also added a function CHARNAME as an inverse to CHARCODE, so you can see the names of the codes (e.g. Meta,U instead of its current numerical value 341). Of course, a name (particularly aFunction name) doesn't always tell how you can type it. Some version of CHARNAME probably ought to move to LLREAD, along with CHARCODE.DECODE. |
|
Concerning opening TEdit with an empty document, would it be possible to have a behavior similar to what TEdit did previously, i.e. show an initial outline like the File Browser? Now the mouse pointer changes shape and a message in the prompt window advises to swipe an area. While this is okay with me, having some kind of outline is a clue that may help users less ecperienced with Medley as it's clear what needs to be done next. |
|
Here are some TEDITKEY actions that would be great to have bindings for in TEdit:
|
|
@pamoroso It would be good to look at the list of possible TEdit actions and see if the documentation makes it clear how you should add the key bindings for the actions you want to your personal init file. If that's not clear then there should be an issue for that against the documentation. The Interlisp philosophy is very much "we provide the mechanism, you use/configure it to do what you want." |
|
More documentation would be welcome. I was actually meaning to define such bindings in my own init file but didn't find direct mappings of those actions in the ones |
It;s now easy to install those actions...the problem is how to figure out the best assignments for the limited number of characters that make sense, are easy to type, and don't conflict with e.g what TTYIN also does. |
|
Microsoft Word has a pretty nice interface to define/redefine keys-to-commands. This could inspire/inform how it could be done for TEdit. Notice, that this shows any current key (character) assignments, and shows if the new key is already assigned to a command. This could build the form to assert the set of assignments, or a form to add to |
|
I think the interface functions are now there. You can clear out old assignments, add new assignments in your init (although maybe the TEDIT.INSTALL.CHARBINDINGS should take a CLEAR flag so it can all be wrapped up in one call. The problem is to decide how to allocate the characters to the actions. E.g. I'd like Meta-S to mean "Save", as in the operating system. But then what about Substitute? Possibly Meta,R for Replace. But then what about Redo? We need a better theory of the default assignments. |
As usual, lots of files. Mostly targeted at getting better, more declarative control over keybindings for different Tedit operations (plus random odd corrections along the way). I will document this in the release notes that will be added in the next day or so. (This replaces the functionality of EDITKEYS, TKDORADO, and TEDITKEY, which should go obsolete on the next round.)
A relatively minor user-interface change that got swept up in this is a new heuristic for the initial Tedit window region. When Tedit "gets" an existing file, it used to ask for the window region before it looked at the file. With this change it gets the file before it opens the window. It tries to use the file's formatting information, specifically the margins, to calculate the proper width for that file (text area plus line and splitting regions), and it calculates the height that it would take to display the first 20 lines. The user is asked just to locate the ghost region of that particular size, no sweeping out.
For TDRIBBLE, it uses the width and height of the current Exec. It uses a different heuristic when viewing Lisp source files, etc.
This may require some fine tuning, but I hope it makes for a smoother experience.