search

Interlisp / medley

The main repo for the Medley Interlisp project. Wiki, Issues are here. Other repositories include maiko (the VM implementation) and Interlisp.github.io (web site sources)
https://Interlisp.org
MIT License
369 stars 19 forks source link

GREET should run "without pagehold" #626

Open masinter opened 2 years ago

masinter commented 2 years ago

So many people want WITHOUT-PAGEHOLD in GREET.

I thought it was set up so that SITE-INIT was run "quiet" but the User's init file was noisy (and needed without pagehold. MEDLEYDIR is a 'site' so MEDLEYDIR-INIT; so is ONLINE, so ONLINE-INIT should be in the same directory as MEDLEYDIR-INIT. (PARC was a site, and PARC-INIT in 'greetfiles'. I'm OK with moving all the greetfiles somewhere else as long as hey are together.

There are two common ways of accomplishing without pagehold, one to (BKSYSBUF " ") insert some extra spaces into type-ahead buffer (how it was named on the PDP-10) because of what the PDP-10 TENEX operating system called the "sysbuf".

The other way is to use RESETSAVE and RESETLST to change the window's pagefullfn to NILL and put it back. This is thread safe if only one thread is using the window, I never got comfortable with the common lisp error system but I think this is what UNWIND does.

masinter commented 2 years ago

@fghalasz @stumbo for your consideration and opinion; @skaisler1 thank you for testing and reporting problems; it's what we need most. Please don't stop

fghalasz commented 2 years ago

I will fix up ONLINE-INIT and put it in MEDLEYDIR/greetfiles (a submit to the Medley repo on github). And I will change the online call to run-medley so that Medley directly loads ONLINE-INIT instead of MEDLEYDIR-INIT.

This is the right way to do it - the current scheme of running ONLINE-INIT in place of the user iNIT does not give the online user a chance to have a separate per-user INIT file (without editing ONLINE-INIT).

That being said, ONLINE-INIT is designed to be supplemental to MEDLEYDIR-INIT, so I will just have ONLINE-INIT load MEDLEYDIR-INIT.

Hopefully ONLINE-INIT calling MEDLEYDIR-INIT will all happen under the SITE-INIT quiet scheme.

Also: I already handled the ONLINE-INIT pagefull issue using a RESETVAR to set PRETTYHEADER to NIL. It worked to get rid of load messages and hence the pagefull issues. But it might not be a general solution.

rmkaplan commented 2 years ago

I updated to use the MEDLEYDIR-INIT, and now I get funky behavior during my GREET. Medley comes up and starts the greet, but then it hangs with this thing flipping back and forth about holding or releasing the shift key.

But holding or releasing the shift key doesn't do anything one way or the other, it just hangs. That may because of something else--something changed so that you now have to click in the medley window to start type in there, even if the caret is flashing.

But this is really funky. How do I turn it off, at least for greeting?

My Greet does a version bksysbuf so that it should never hang. But apparently bksysbuf doesn't matter with this new regime.

It seems also that this will hang screen by screen if I do any other long computation that produces lots of type out. So I have to sit there and keep poking the keyboard.

Maybe I don't understand how this is supposed to work

rmkaplan commented 2 years ago

Definitely, the keys don't go to the X window at start up unless you actually click in it (on a mac). So you have to blast through that issue before you can make any sense at all out of the pagehold.

I looked at the lispusers/pagehold.tedit. It says that it is supposed to work the old way, if there is anything in the buffer. That appears not to be true--it hangs even though there is an explicit BKSYSBUF.

masinter commented 2 years ago

there was a macro floating around (WITHOUT-PAGEHOLD ...) which reset the PAGEFULLFN of the terminal window. I'm not sure where it went. I think GREET should run WITHOUT-PAGEHOLD and probably noisy transcripts from FB-initiated compiles.

If we had scrollable exec windows we could eliminate pagehold completely. In the meanwhile let's take PAGEHOLD out of the MEDLEY init until there's some more clarity on which path to take.

rmkaplan commented 2 years ago

I agree, this is all a compensation for not having scrollable TTY windows. An automatic dribble file {NODIRCORE}? with some way of hooking it in to a TTY scroll function.

I have the WITHOUT.PAGEHOLD macro.

The one in lispusers wouldn’t be so confusing if input goes to the X window at start up, without needing a click. And it wouldn’t be so intrustive if it just said what to do without flashing. But maybe the interaction could be improved:

Don’t stop if you are under a WITHOUT.PAGEHOLD or the user has asserted something in the process (currently the BKSYSBUF, but something with a more obvious name).

But then have it look every once in a while (every page?) to see if some other particular key is down (say the ctrl key), and go into stop mode in that case. That is, a deliberate user action to stop it, so you don’t come back an hour later and find that nothing happened.

On Mar 5, 2022, at 10:59 AM, Larry Masinter @.***> wrote:

there was a macro floating around (WITHOUT-PAGEHOLD ...) which reset the PAGEFULLFN of the terminal window. I'm not sure where it goes. If we had scrollable exec windows we could eliminate pagehold completely. In the meanwhile let's just take PAGEHOLD out of the MEDLEY init until there's some more clarity on which path to take.

— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/626#issuecomment-1059815663, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJM452DGMRVETPDQ3KTU6OVJPANCNFSM5KCWJSOA. You are receiving this because you commented.

masinter commented 2 years ago

This should probably be a separate issue? I'm wondering if we could use the lispx history structure (which retains input and some limited subset of output) to make scrollable windows useful in conjunction with FIX.
Otherwise we might be trying to sync the dribble file to the history events?

masinter commented 2 years ago

The reason I wanted to not wait indefinitely for a PAGEHOLD is that if you're in a PAGEHOLD during a compile or makefile, it won't go into IDLE and going into IDLE is what triggers the online LOGOUT. If it doesn't log out it leaves ghost processes around when users just close their browser window.

rmkaplan commented 2 years ago

Seems like the problem is that IDLE shouldn’t do a logout if it went into idling because of a pagehold. The pagehold should set something that can be tested.

On Mar 5, 2022, at 11:46 AM, Larry Masinter @.***> wrote:

The reason I wanted to not wait indefinitely for a PAGEHOLD is that if you're in a PAGEHOLD during a compile or makefile, it won't go into IDLE and going into IDLE is what triggers the online LOGOUT. If it doesn't log out it leaves ghost processes around when users just close their browser window.

— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/626#issuecomment-1059821917, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJPUV6CSAVQOPJY6TATU6O22TANCNFSM5KCWJSOA. You are receiving this because you commented.

rmkaplan commented 2 years ago

If we created a NODIRCORE dribble file before the execution of each event, and attached that to the event, then at least we would have the information to show. Maybe with a new exec command (like FIX, REDO) that would bring up the dribble in a separate TEDIT-SEE window (with a reusable region). Quite unnatural, but maybe a first attempt at plugging the hole.

On Mar 5, 2022, at 11:44 AM, Larry Masinter @.***> wrote:

This should probably be a separate issue? I'm wondering if we could use the lispx history structure (which retains input and some limited subset of output) to make scrollable windows useful in conjunction with FIX. Otherwise we might be trying to sync the dribble file to the history events?

— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/626#issuecomment-1059821619, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJJ346LHYZISJYSYW7DU6O2Q7ANCNFSM5KCWJSOA. You are receiving this because you commented.

masinter commented 2 years ago

most of this discussion about PAGEHOLD is really about a separate feature request that would let us turn off(?) pagehold.

In unix shell which is scrollable, less and more still offer pagehold but it isn't the default for stdout

rmkaplan commented 2 years ago

We decided to remove the PAGEHOLD package from the ordinary MEDLEYDIR-INIT, and even remove it from the online init. It doesn't solve the LOGOUT problem, which is only a problem online, and in itself it provides terrible functionality. (Do you really want something to start going automatically, while the whole point of holding is so that you can look at it?)

By the same token, do we need the VT100 and VTCHAT in the ordinary MEDLEYDIR-INIT, or just online?

nbriggs commented 2 years ago

I don't think the VT100/VTCHAT belong in the MEDLEYDIR-INIT

masinter commented 2 years ago

removed PAGEHOLD and VTCHAT from MEDLEYDIR-INIT in PR #739, still leaves the problems that started this.

A simpler approach would just add a timeout to pagehold (say, 2 minutes? DWIMWAIT seconds?) without the blinking window.

With VTCHAT the idea was to minimize the difference between online and docker / medleydir. the vt100 emulation seems to work better with linux terminal than dm2500

rmkaplan commented 2 years ago

If you want to have a timeout for the online logout problem, set it at 30 minutes, and only load it in the online init file. And otherwise don’t change the current holding behavior—hold only if the input buffer is empty.

On Mar 9, 2022, at 4:07 PM, Larry Masinter @.***> wrote:

removed PAGEHOLD and VTCHAT from MEDLEYDIR-INIT in PR #739 https://github.com/Interlisp/medley/pull/739, still leaves the problems that started this.

A simpler approach would just add a timeout to pagehold (say, 2 minutes? DWIMWAIT seconds?) without the blinking window.

With VTCHAT the idea was to minimize the difference between online and docker / medleydir. the vt100 emulation seems to work better with linux terminal than dm2500

— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/626#issuecomment-1063503151, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJLX7QVWMNNBRAN5V4DU7E4LJANCNFSM5KCWJSOA. You are receiving this because you commented.