Default Keybindings "Cheat Sheet" first pass (Thoughts appreciated)

[pixel...@gmail.com]

It turns out that it's very easy for me to format the Google Docs spreadsheet into a table in Emacs' Org mode then paste it directly into TEdit. 

Just did a first pass with some metasyntatic variables for "groups". 
They don't mean nor group anything yet, just testing the notion.

Thoughts appreciated...

[Paolo Amoroso]

Great start. The table looks clean and easy to consult but some characters are garbled.

By the way, the manual of TEdit is available here https://drive.google.com/drive/folders/1ptvlX6ZEXsY6uL8qiNC4aaMpGsbqJ9RB?usp=drive_link

--
You received this message because you are subscribed to the Google Groups "Medley Interlisp core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lispcore+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lispcore/da185833-37c9-4d66-9f62-1474161340f2n%40googlegroups.com.

--

Paolo Amoroso | Blog | Mastodon

[pixel...@gmail.com]

Thanks Paolo,

I'll review that manual too for other important material.
I looked at my Cheat Sheet later and saw there were a few typos and tweaks to do yet...

[pixel...@gmail.com]

Here is the latest if anyone is interested.
I'll just attach the TEDIT file.

[Paolo Amoroso]

With the default Medley screen size TEdit picks by default a window size that's thinner than the line width, which wraps text and makes it look scrambled:

To view the document with no wrapping I need to resize TEdit so that it takes up most of the screen width:

Decreasing the font size to 8 points allows a smaller window with slightly reduced legibility:

To view this discussion visit https://groups.google.com/d/msgid/lispcore/a9d79667-3fd0-4b14-821f-3f04cf9cc522n%40googlegroups.com.

[Ron Kaplan]

It seems like the right margin isn't set on any of the paragraphs, so it defaults arbitrarily to 6 inches (432 points).

But it also seems like the maximum allowed by the margin bar is 1008 pts (14 inches), for no particular reason.  This appears to want to be about 1152 points (16 inches).

Maybe in the default (no margin setting) case, it should take the widest of, say, the first 20 lines instead of the largest margin anywhere in the document.  It's formatting those lines anyway, to calculate the initial height.

On Oct 18, 2025, at 4:00 AM, Paolo Amoroso <paolo....@gmail.com> wrote:

With the default Medley screen size TEdit picks by default a window size that's thinner than the line width, which wraps text and makes it look scrambled:

<sebinds1.png>

To view the document with no wrapping I need to resize TEdit so that it takes up most of the screen width:

<sebinds2.png>

Decreasing the font size to 8 points allows a smaller window with slightly reduced legibility:

<sebinds3.png>

To view this discussion visit https://groups.google.com/d/msgid/lispcore/CAGi1hztmCVx_wcC4TKduG9Un9D6qnPG%2B3mvn9ectRwnZRE%3DVrg%40mail.gmail.com.

[Larry Masinter]

There are several ways to address the concern and I/m not sure the choice is clear:  getting layout to adapt to the data and constraints is the "responsive" criteria for HTML web sites and tables. You could change the default screen size, the choice of default window size (for "modernized? windows). You could add a 'table' image object that was more responsive to the width it was given, and then reformat the text using it. But the table layout problem is over constrained. Could you format the text using right-aligned tab stops?

I think for issue #58 https://github.com/Interlisp/medley/issues/58 it might be better to enumerate the _current_ key bindings rather than the "default", if we decide to address issue #58 by incremental changes to the defaults (since no one has signed up to take on issue 58 per se).

https://LarryMasinter.net  https://interlisp.org

To view this discussion visit https://groups.google.com/d/msgid/lispcore/FCB44264-C6F4-4F35-B1D1-08D478374EA3%40post.harvard.edu.

[Ryan Burnside]

Sorry to reply late I've been a little bit busy this weekend! 

Yes, I'm still exploring the program and didn't correctly set the margins. I was working by stretching it out on my screen which was good enough for the time being. So I suppose yes if somebody's working on an old school resolution like 1024 by 768 it's going to be a problem. 

I did notice that the pages offered are limited to 3 or 4 sizes. I guess the first thing that strikes me as a new user is why they didn't provide a bottom scroll bar in the case of something like an A1 or A2 piece of paper. The top windows when I attached wouldn't have to scroll they can just stay their size.

Of course I'm totally shooting in the dark with this since I've not studied the source code.

Maybe you could get the pixel width by MAPping a string pixel width function to the text lines then APPLYing MAX to the list? Then provide a horizontal bottom scroll bar? But I don't know, that might dip into the current font issues.

I don't have too much of an opinion currently on modernizing the key bindings. But I will say that the notion of modern key bindings is different between current operating systems even for cutting and pasting. I personally am fine learning the system as it stands. I pretty much just jumped into Emacs and adopted the local culture. So that would be my current approach to Medley. I think as long as you have "in system" discoverability like I was trying to make here you don't necessarily need to make it look and act like Windows or Mac OS. One of my biggest complaints with Mac OS is that they have all these specialized keys to show hidden files and such and there's no menu nor listing that tells you about that. Well, guess I do have a bit of an opinion. ;)

For now I'm okay stretching my window manually.

I don't want people to think I'm trying to send everything I touch into eight directions! But it will be interesting to see how a different people use the system when we gain a bunch of users. I'm totally willing to hack some of these programs but I want to spend a bit more time studying the language. I think one of the greatest strengths of this system is the hackability. I saw similar in Emacs which is why I often hack on it.

Please excuse typos I'm tapping this into my phone with one eye open. ;)

[Ron Kaplan]

I put in a heuristic, a year of so ago, for Tedit to put up a likely initial window, based on the margins in the document and the height of the first up to 20 lines.  The idea was to help the user get a reasonably sized window at the open, to avoid dragging out too big or too small and then adjusting when the content shows up.

For the binding document, he margins weren't specified for any of the paragraphs, so Tedit (or the user) made an uninformed guess.  I have fiddled around with the heuristics, and a new version will do a better job in this situation.  When there are no paragraph margins in the document, it tries to get the width as well as the height by formatting the first 20 lines and using the line breaks to figure out the length of the longest line.  This only works for lines/paragraphs that are left-justified with ragged-right edges, and lines that actually do have explicit breaks.  It skips paragraphs/lines that are justified, centered, or right-justified--the breaks for those lines depend on the right margin, which is undefined.  In the worst case it will use the current screenwidth to bound the guess of an initial region.

I also fixed the margin bar to take out the 14 inch default.  It now goes out to the initial width, and if the window is later expanded the margin bar will also expand.  

As noted, the 14 inch default may have been motivated by standard page sizes, and that may have been appropriate in the day and age when printed hardcopy was the ultimate destination of many documents and screen viewers were not widely available.  But as mentioned in the discussion on imagefile types, the screen is much more frequently the target for document viewing, either in windows within Medley or in external pdf windows.  That's certainly true of man pages, PF of functions, seeing of source files...and also the likely scenario for this particular key-binding document--bring it up to read on the screen, and close it.

I won't push the changes to the initial window sizing and margin bar or the new imagefile interface until after the font PR is merged.

(As for horizontal scrolling, I think they had enough trouble in those days getting the vertical scrolling; horizontal was just a promissory note.  This would be much easier to do now, but it still requires some programming.)