Want consistent keybindings (as part of Modernize)

[masinter]

"help wanted" is different than "good first time project". In this case, what we need is someone to research what key bindings are now and what they should be. Also for window actions, menus, etc.

I don't think the fact that Interlisp pre-dated Mac and Windows and Linux UI guidelines is important to preserve

Originally posted by @masinter in https://github.com/Interlisp/medley/issues/50#issuecomment-713083301

[masinter]

Between TTYIN, sedit, tedit compared to Linux, Mac, Windows, emacs set up user GREET settiable (undoably) consistent set of key bindings. It is impossible to be simultaneously consistent with multiple inconsistent things, but settable key handling should allow these:

• arrow keys (left, right, up/previous, down/next)
• DEL as "delete selection" or (if nothing selected) delete forward
• CR/Enter as (submit line) even if not at end
• control-A as "select all" or "go to beginning of line"
• control-K as "delete rest of line"

For extra credit: allow the input stream to be a stdin / pipe and output stream to be a terminal with character IO

[masinter]

• This issue has some overlap with other keyboard issues (European keyboards) but hopefully separable
• everyone has opinions about what their fingers are trained for. We need to make reconfiguration easy (even though the underlying mechanisms are complex.
• Some things are not implemented (deleting forward, arrow keys) and it isn't just a question of key bindings
• we should mainly look at what the browsers do because
• online users are running in a browser
  • browsers face the same developer dilemma of needing to support and document multiple different user preferences https://www.groovypost.com/tips/50-universal-web-browser-hotkeys/ https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent https://learn.microsoft.com/en-us/microsoft-edge/devtools-guide-chromium/customize/shortcuts https://support.apple.com/en-us/HT201236 https://support.google.com/chrome/answer/157179?hl=en&co=GENIE.Platform%3DDesktop

[masinter]

those links were pretty useless. Here's the beginning of a chart https://docs.google.com/spreadsheets/d/1FOkrr62TtEhhY49m9U0T_6bvqSGRQt9fBRtMDw0YKtY/edit#gid=642562870

[masinter]

I made good progress on the keystroke binding table: https://docs.google.com/spreadsheets/d/1FOkrr62TtEhhY49m9U0T_6bvqSGRQt9fBRtMDw0YKtY/edit#gid=79579844 and found the code for TTYIN which has lots of features I didn't know about, being assigned (hard wired) to odd keystrokes and tied up with some meta-key changes I found the table of SEdit key bindings nicely organized by function TEdit key bindings are still to be discovered. some keystrokes are owned by non-Lisp code (browser for online, windows, etc.) I tested in -nogreet LISP.Venuesysout. I didn't see cut copy or paste as those are in clipboard.

Next steps

• validate the information gathered
• complete the table
• make ttyin actions assignable
• (others as possible)
• settle on at least one but possibly more "consistent key-binding sets" for (mac/metakey) (online user) (common lisp/slime) key binding sets
• document and test

[masinter]

Another source of input, perhaps as much for other issues like the foreign keyboard problems, is the table in Maiko used to populate its key tables Please review https://github.com/Interlisp/maiko/blob/master/inc/XKeymap.h

It seems this is tuned for situations we don't have, and a solution will require at the very least updating this table.

[masinter]

https://www.oreilly.com/library/view/xlib-reference-manual/9780937175262/16_appendix-h.html seemed like a useful reference as well.

[nbriggs]

When reviewing XKeymap.h, you also need to read the code in https://github.com/Interlisp/maiko/blob/master/src/initkbd.c function make_X_keymap, which starts from the generic mapping in XKeymap.h and produces one specialized for the X server it is running against.

[rochus-keller]

Am I wrong to assume that the Medley system (i.e. not Maiko) has it's own keyboard state machine which essentially expects some kind of "scan code" of an original Dorado or whatever keyboard?

If yes, a simple mapping on scan code or virtual key code level doesn't solve the problem, because international keyboards have completely different key sequences to get a specific character than an ASCII keyboard (i.e. a proper translation has to translate key sequences, not just single key strokes); the present Maiko implementation only works, because the Sun and other keyboards used for US Unix like systems seem to be rather similar.

Anyways, does anyone have a scan code table (i.e. key code to meaning of the key) of the original keyboard the Medley Lisp code assumes?

[nbriggs]

I’m on my phone- pardon the brevity Read the code for the x11 keyboard handling in Maiko and look at the key table in the lisp source. Medley deals in unencoded key transitions not ascii codes. There are multiple mappings because dorado dandelion daybreak all had different keyboards, and office and scientific variants. Maiko tries to undo the encoding to map to the lisp keytable but can’t reliably determine the keyboard locale (thanks xquartz!) and has avoided dealing with things like xmodmap. I’ll be happy to say more when I’m back at a real computer this weekend.

[rochus-keller]

Ok, thanks; that's what I suspected. I will try to solve it in my Gingko branch based on SDL scan codes and SDL_TEXTINPUT. The keyboard locale is not the concern of Maiko, but of the client OS in use.

[nbriggs]

The SDL code is incomplete compared to the x11, and uses key top labels vs physical key like the X code. Also not the lisp code handles multi key down not just for shift like keys ( eg hold A down and click left mouse could generate a special character if desired)

[rochus-keller]

Meanwhile I implemented a solution in sdl.c which no longer depends on the specific keyboard layout of the client machine. For this purpose I have two mapping tables, one for the key strokes which lead to the supported printable characters, and one for the control etc. keys. Seems to work. Ginko can be used as a dropin replacement for ldesdl.

[rochus-keller]

@nbriggs : apparently some of the Lisp key code specifications in sdl.c were wrong; by trial and error I found the correct assignments, see this commit. There is stil one questionable assignment for the underscore, which prints a left arrow instead; I didn't find the code for the true underscore yet; am I right to assume that there is one at all?

[nbriggs]

Still mostly offline. The underscore is supposed to print as left arrow. Depends on which font you’re using. Did you look at (backslash)KEYNAMES in the lisp source? That shows the mapping of the bit index to the key

[rochus-keller]

The underscore is supposed to print as left arrow

Ok, then so be it; just wasn't sure whether my mapping is still incomplete, but it seems to work. I didn't try yet, but actually my version of sdl.c should also compile in the official source tree, in case you're interested.

Did you look at (backslash)KEYNAMES in the lisp source?

I would prefer navigating the Interlisp sources with a dedicated browser such as the one I've written for Smalltalk-80. But the source files in the medley/sources subdirectory seem to be encoded with some format (in contrast to the clos source files which are plain ascii); do you know where I can find the specification of this format, or do I have to derive it from the source code?

[masinter]

The "format" of Medley Interlisp source files are ultimately defined by the "reader environment" which is named in the DEFILE-FILE-INO t the top. This includes ^F^A font change fields, https://fles.interlisp.org/medley/ has all of the sources also printed to PDF.

Otherwise, the source files are best read into Medley and viwed with SEE command / filebrowser menu item.

[masinter]

the MANAGER LispUsers' file (FILESLOAD MANAGER) TEDIT(MANAGER.TEDIT) iw kine or like your class browser.

[MattHeffron]

https://fles.interlisp.org/medley/

Typo, should be: https://files.interlisp.org/medley/

[pamoroso]

@rochus-keller The lsee script can help view source files and describe formatting codes.

[rochus-keller]

Thank you all for your hints.

@masinter : the MANAGER LispUsers' file (FILESLOAD MANAGER) TEDIT(MANAGER.TEDIT) iw kine or like your class browser.

Unfortunately I'm not (yet) proficient enough to make decent use of the Medley tools; I just started to read the many books and to make experiments with the environment, but mostly I'm interested in exporing how the Lisp side of the system works to draw the right conclusions concerning the VM implementation. I also want to parse and cross-reference the source files; but I still can use the PDF to see how the file actually should look (see below).

@rmkaplan : The lsee script can help view source files and describe formatting codes.

Thanks for this hint; that solved the problem. I was now able to implement a quick source code viewer. But apparently some of the source code is written all on one line without any formatting; e.g. in the file COPYFILES the clause "(LAMBDA (FROMSPEC TOSPEC OPTIONS) ...", which is just 8113 characters on a line with no line breaks. How is this supposed to be presented by the editor?

[pamoroso]

The sources with those long code lines are typically generated by the FAST option of the MAKEFILE File Manager command, see page 326 of the Interlisp Reference Manual. The command saves code to a file.

The SEdit Lisp editor reformats the long lines, here's what COPYFILES looks like in the editor:

[nbriggs]

Paolo sort of hints at this, but more completely:

An Interlisp managed "source file" is not just a plain text representation of the code, it's more like a simple source database containing things like a reader environment, a textual representation of functions, variables, constants, and other extensible file objects. It is capable of preserving (EQness of) self-referential structures. It also contains a filemap (at the end) with pointers back to function definitions. When a value (be it a function definition, or some other object) is output on the file it may be pretty-printed, or it may be just printed without regard to human readability. Printing frequently includes font control - two bytes, 0x06 (ctrl-F) followed by a byte to select a font index from the current FONTSET when it's being displayed (the lsee script shows some of that).

People used the "PRETTYFILEINDEX" lispusers package if they were printing to get an indexed listing.

But... Interlisp is primarily a residential IDE - nobody who used (uses) it would expect to be looking at sources outside of Interlisp - none of the tools outside had nearly the power of what was available inside. There are multiple code editors, specialized over time, from the teletype editor (not TEDIT, that's the text editor), to display edit (DEDIT), to SEdit (the structure editor). As Paolo pointed out, the structure (program, value) you're editing is pretty-printed as you edit it.

Cross-referencing usage is done with MASTERSCOPE, which can analyze and answer all kinds of questions about function and variable usage (and how they're used (e.g., freely), and from a a definition on which file, and the call chain leading to the usage (or avoiding particular paths) and so on and so on - it's a real education watching Larry come up with queries to answer some knotty question!))

[rochus-keller]

Thanks for the information; I already started reading the file manager and some other sections of the Medley Language Reference book and try to make sense of it. I also found the Interlisp VM Specification which looks interesting. Is there actually a document somewhere about the history of the Maiko VM?

[nbriggs]

I can't comment on the original Interlisp VM Spec - that's before my time. There may be some e-mail messages related to the history of Maiko still extant, but not that I have access to. Larry and Arun might know. Fuji Xerox was heavily involved, and a series of Xerox groups and spinout companies. Maiko has had significant modifications since it was originally written (e.g., moving to support bigger Lisp virtual memory sizes, support for little-endian hosts as well as original big-endian, support for LP64 C environment as well as ILP32, various optimizations added (and removed)) and I don't know how much of that was written down, again... at least in ways/places we still have access to.

[nbriggs]

I'm looking at the mapping changes - at first glance they look reasonable, I'll check them against the \KEYNAMES bits when I have a chance and I'll make corresponding changes to the Maiko sdl.c - you've reformatted, not using the maiko/.clang-format that we've pretty much standardized on for all the C code [but which hasn't been uniformly (re)applied in some time]