Rmk185 tedit window and process glitches#2604
Conversation
|
It works as intended on Linux Mint 22.1 Cinnamon. The new default TEdit window works well but I'd appreciate a slightly taller initial window. |
|
To elaborate on my suggestion, the same default height TEdit uses for loading a supplied document (20 lines?) would be fine. |
|
Still looking good at commit 44d9da0. |
|
This PR is still hanging out there, so I added some files. This is trying to keep the secondary selection consistent when the mouse leaves, perhaps to scroll, and comes back, issue #2434 . Wheelscroll is stil problematic when the mode keys are down for a secondary. I'm not altogether clear, but I think the issue is that the wheelscroll comes through the keyboard but the secondary selection is runnning in the mouse. |
|
It still works with no issues at commit be6a6d0. |
|
If anything, it's worse on mouse interactions now. I started with
|
|
I think (but I'll check) that the secondary selection is remembered when the mouse leaves the window, so the screen is consistent with the data. But I don't think that Tedit is set up properly for the situation where the mouse goes out, isn't clicked anywhere, and then comes back in again without clicking. Probably needs a CURSORINFN, which it has never had. Or somehow recognize that not only are the mode keys the same but that there has been no clicking elsewhere to change the TTY process in the meantime. That is, you can move the mouse around the screen, let the keys go up and down, but behave as if the mouse never left if the keys are what they were before the mouse left and so act on the selection if the keys come up in the window.
Perhaps trickier to get intuitive behavior if the TTY process has moved away while the mouse was outside (e.g. clicked in the exec or another Sedit or Tedit), and then the mouse comes back with the same shift keys down. If you release, presumably the selection now should goto the (new) current tty, not the original Tedit with the secondary selection.
… On May 14, 2026, at 10:17 AM, Nick Briggs ***@***.***> wrote:
nbriggs
left a comment
(Interlisp/medley#2604)
<#2604 (comment)>
If anything, it's worse on mouse interactions now. I started with
open a TEDIT on any file
click in the line select area to set selection at beginning of any line
shift-hold-click to select copy source as a whole line
let the shift up -- it copies correctly duplicating the line
Do the same thing but while the shift is held down move the mouse outside the TEdit window to the left and then back into the TEdit window
release the shift -- no copy happens.
The shift-select source underline stays after releasing the shift, but disappears if another selection is made
—
Reply to this email directly, view it on GitHub <#2604 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJKN5G2HNHY7E3TOIUL42X5SDAVCNFSM6AAAAACYYRHN3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DINJSHE4DIMJVGI>.
You are receiving this because you authored the thread.
|
|
The new function \TEDIT.CURSORINFN is now applied when the mouse crosses over a Tedit window. If the window's process has the TTY, and if the stream has a secondary selection whose mode keys match the current keyboard modekeys, then without a new click this reenters the mouse-tracking function \TEDIT.BUTTONEVENTFN. The idea is to get back into the tracking loop with the state as it was when the mouse left the window and the loop gave up control. If the mode keys come up, the secondary selection should be applied, as if the mouse had never left. On this attempt, if the TTY/secondary selection conditions are not satisfied when the mouse comes back in, the secondary selection is turned off. Not sure about that--that perhaps should happen only if the window still has the TTY but the modekeys are different. I hope this eliminates the dangling secondary selections we have been seeing, and that the behavior is at least somewhat more intuitive. |
|
Nothing unexpected to report at commit 7e87f58. |
hold the (left) shift key down, and while holding it down move the mouse/cursor (always keeping it within the TEdit window) to the left margin of the document (where the cursor changes from NW pointing to NE pointing) and left-click with the mouse to select a whole line, all the while keeping the shift key down, then continue to step 4. |
|
I don't think this particular issue had to do with line selection, would have also been a problem with secondary word selection.
Line selection appears to raise a different issue, even for the primary selection. If you select in the body of the text and then, still holding the mouse down, you cross over the line select region on the way to the scroll bar or beyond, your selection gets extended on the fly to be the whole line (if left button) or paragraph (if middle button). That's probably not what you intend.
Probably the line selection (primary or secondary) should only happen when you explicitly click in the line select region, not when you happen to roll into it or across it.
You'd like to be able to select something (left or middle), scroll someplace else, and then right-click to extend from what you had selected before.
… On May 15, 2026, at 8:22 AM, Nick Briggs ***@***.***> wrote:
nbriggs
left a comment
(Interlisp/medley#2604)
<#2604 (comment)>
@pamoroso <https://github.com/pamoroso>
shift-hold-click to select copy source as a whole line
hold the (left) shift key down, and while holding it down move the mouse/cursor (always keeping it within the TEdit window) to the left margin of the document (where the cursor changes from NW pointing to NE pointing) and left-click with the mouse to select a whole line, all the while keeping the shift key down, then continue to step 4.
—
Reply to this email directly, view it on GitHub <#2604 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJM4Y54NOT4Y7RXBPBL424Y2JAVCNFSM6AAAAACYYRHN3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DINRRGA2DMNRXGM>.
You are receiving this because you authored the thread.
|
|
@nbriggs Thanks, this way I confirm the issue. |
|
New version works a little bit better. If you cross the scroll bar quickly it's OK, if you pause and let the scroll bar appear and then move back in to the window it doesn't. |
|
So, the situation is that you make a secondary selection, move out to the scroll bar with the copy key down, then move back in and release the copy key. The problem is that it then neither does the copy nor clears the screen? Prefereable it should do the first.
… On May 15, 2026, at 10:07 AM, Nick Briggs ***@***.***> wrote:
nbriggs
left a comment
(Interlisp/medley#2604)
<#2604 (comment)>
New version works a little bit better. If you cross the scroll bar quickly it's OK, if you pause and let the scroll bar appear and then move back in to the window it doesn't.
—
Reply to this email directly, view it on GitHub <#2604 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJLE7GMORRAHRSWYOE3425FDRAVCNFSM6AAAAACYYRHN3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DINRRG4ZTCNBTHA>.
You are receiving this because you authored the thread.
|
|
@rmkaplan - correct. It neither clears the secondary selection nor does the copy when the shift key is released. I don't think that whether the scroll bar activated or not should have any effect. |
|
Tedit was keeping control when the mouse went into its scroll bar, only giving up control when the mouse truly went outside. I removed that complexity in Tedit, the polling gives up control whenever the mouse leaves the window, the general window system seems to then notice whether it is hanging out in the control bar. That means that coming back from the scroll bar is the same as coming back from anywhere else. That seems to work, although sometimes it is sporadic in both cases for reasons I don't understand--maybe just my local coding environment. Let me know if it is inconsistent or unreliable. I also pushed a change to the way the line/paragraph selection works. Instead of being able to switch the line/text region in the middle of the tracking loop, it sets the region on entry, outside of tracking. The cursor changes when you move through the line-select region, but you have to click there to change the selection. Otherwise you would just pass through to the scroll bar and beyond. |
|
At commit 2485ddb I did a few shift-copy tests in a document and crossing the scroll bar worked better, i.e. the copy did occur when releasing the copy key. However, after executing the 
At that point Medley was unresponsive and didn't accept any mouse or keyboard input but still continued GCing every few seconds. |
|
I removed the cursorinfn when the window is closed, and also suppressed it if the textstream has gone away.
… On May 16, 2026, at 2:08 AM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2604)
<#2604 (comment)>
At commit 2485ddb <2485ddb> I did a few shift-copy tests in a document and crossing the scroll bar worked better, i.e. the copy did occur when releasing the copy key.
However, after executing the Quit command of the middle-click title bar menu TEdit forze for a few seconds and then this break window showed up (the TEdit window shows some duplicate text as a consequence of my tests; the document is a copy of lispusers/BITMAPFNS.TEDIT):
INTERLISP-ERROR
In ERROR:
ARG NOT TEXTOBJ
NIL
tedit-error.png (view on web) <https://github.com/user-attachments/assets/97a86685-fecf-4b4a-92b5-ba474574d853>
At that point Medley was unresponsive and didn't accept any mouse or keyboard input but still continued GCing every few seconds.
—
Reply to this email directly, view it on GitHub <#2604 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJOGLQIOVOBUBVNAYED43AVYTAVCNFSM6AAAAACYYRHN3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DINRWGQYTQMZRG4>.
You are receiving this because you were mentioned.
|
|
When the window is open and the mouse is over the window, what does
(WINDOWPROP (WHICHW) 'CLOSEFN) return?
… On May 16, 2026, at 11:42 AM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2604)
<#2604 (comment)>
If I use the right-click Close command and confirm when prompted the window closes with no issues.
—
Reply to this email directly, view it on GitHub <#2604 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJKOXAXJX3IFM4RZRFT43CY73AVCNFSM6AAAAACYYRHN3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DINRXG44DGMRQGA>.
You are receiving this because you were mentioned.
|
|
Also, (TRACE TEDIT.DEACTIVATE.WINDOW) before you Quit, does it return DON'T ?
… On May 16, 2026, at 11:50 AM, Ron Kaplan ***@***.***> wrote:
When the window is open and the mouse is over the window, what does
(WINDOWPROP (WHICHW) 'CLOSEFN) return?
> On May 16, 2026, at 11:42 AM, Paolo Amoroso ***@***.***> wrote:
>
>
> pamoroso
> left a comment
> (Interlisp/medley#2604)
> <#2604 (comment)>
> If I use the right-click Close command and confirm when prompted the window closes with no issues.
>
> —
> Reply to this email directly, view it on GitHub <#2604 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJKOXAXJX3IFM4RZRFT43CY73AVCNFSM6AAAAACYYRHN3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DINRXG44DGMRQGA>.
> You are receiving this because you were mentioned.
>
|
|
The value of 
Tracing 
|
|
One more question: Does it also behave this way in a fresh full sysout?
… On May 16, 2026, at 11:56 AM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2604)
<#2604 (comment)>
The value of (WINDOWPROP (WHICHW) 'CLOSEFN):
tedit1.png (view on web) <https://github.com/user-attachments/assets/dad37623-8e5a-4beb-b5b6-9014b8b8ee5f>
Tracing TEDIT.DEACTIVATE.WINDOW and Quitting:
tedit2.png (view on web) <https://github.com/user-attachments/assets/adf409be-8379-47a6-b9bf-3702c07127b8>
—
Reply to this email directly, view it on GitHub <#2604 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJLE4POF3QCZJU7F4P343C2VJAVCNFSM6AAAAACYYRHN3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DINRXHAYTGNRQHE>.
You are receiving this because you were mentioned.
|
|
Yes, same bahavior in a fresh full sysout launched with |
|
Another wild stab: Try
(ADVISE '\TEDIT.CLOSEPANE 'BEFORE '(SETQ DONTCLOSEW NIL))
… On May 16, 2026, at 12:07 PM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2604)
<#2604 (comment)>
Yes, same bahavior in a fresh full sysout launched with medley -v -r -: the TEdit window doesn't close when quitting.
—
Reply to this email directly, view it on GitHub <#2604 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJJRP5A5Y6BTPCKMVQ343C35ZAVCNFSM6AAAAACYYRHN3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DINRXHA2DANRQGM>.
You are receiving this because you were mentioned.
|
|
With the advice the window stays open indefinitely after quitting and nothing happens. 
|
|
Well, I'm stumped. The window goes away for me, as I expect, but not for you.
… On May 16, 2026, at 12:24 PM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2604)
<#2604 (comment)>
With the advice the window stays open indefinitely after quitting and nothing happens.
tedit-advised.png (view on web) <https://github.com/user-attachments/assets/fe769805-a0cb-43be-8f38-089fbc0a98f4>
—
Reply to this email directly, view it on GitHub <#2604 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJLF2HTWSTXM3ZVKZHT43C6ADAVCNFSM6AAAAACYYRHN3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DINRXHA3TQOBSGQ>.
You are receiving this because you were mentioned.
|
|
Here is some more data from inspecting the TEdit process and window after quitting: 
|
|
OK, I can get it to happen.
The window is dirty, so when you hit Quit it asks whether you are sure you want to quit.
You answer that question by clicking, either left (Yes) or something else (No).
If you do the answer-click inside the window, the window doesn't close. If you do the answer-click outside the window, it does.
… On May 16, 2026, at 1:51 PM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2604)
<#2604 (comment)>
Here is some more data from inspecting the TEdit process and window after quitting:
tedit-inspect.png (view on web) <https://github.com/user-attachments/assets/471a171f-b64d-4b26-a4f5-40638e36962a>
—
Reply to this email directly, view it on GitHub <#2604 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJKCBQO4HIWN3OZ6RI343DIGJAVCNFSM6AAAAACYYRHN3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DINRYGA4DCNRUHA>.
You are receiving this because you were mentioned.
|
|
So the situation is: open Tedit from the background, type a, click Quit, click Left in the window.
What seems to then happen is that the window is closed in the expected way. The quit marks the edit session as having finished, that causes the Tedit command loop to exit back to its process start-up function \TEDIT1, and that finishes everything up and closes the window.
\TEDIT1 then returns, presumably exiting the process...but someone else then reopens the window. If you
(ADVISE '\TEDIT1 'AFTER (DISMISS 2000 NIL T))
you will see that the window goes away (and is not OPENWP) and then comes back.
I see this behavior even if the new CURSORINFN is first removed from the window.
I don't know who else would have a handle on the window, or what process would then want to bring it back up.
… On May 16, 2026, at 2:15 PM, Ron Kaplan ***@***.***> wrote:
OK, I can get it to happen.
The window is dirty, so when you hit Quit it asks whether you are sure you want to quit.
You answer that question by clicking, either left (Yes) or something else (No).
If you do the answer-click inside the window, the window doesn't close. If you do the answer-click outside the window, it does.
> On May 16, 2026, at 1:51 PM, Paolo Amoroso ***@***.***> wrote:
>
>
> pamoroso
> left a comment
> (Interlisp/medley#2604)
> <#2604 (comment)>
> Here is some more data from inspecting the TEdit process and window after quitting:
>
> tedit-inspect.png (view on web) <https://github.com/user-attachments/assets/471a171f-b64d-4b26-a4f5-40638e36962a>
> —
> Reply to this email directly, view it on GitHub <#2604 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJKCBQO4HIWN3OZ6RI343DIGJAVCNFSM6AAAAACYYRHN3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DINRYGA4DCNRUHA>.
> You are receiving this because you were mentioned.
>
|
|
Another clue is whatever holds onto the window is not in master. |
|
Commit 1f56a56 fixes the quit issue and the window closes as expected. |
|
I don't entirely understand it, but it appears there was a race condition in the interaction between the session closing down and the mouse seeing the button in the window. In part the change that provoked this had to do with trying to work around the mismatch of arguments between the defined version of \TEDIT.BUTTONEVENTFN and the version that is created when that function is MODERNIZEd. For me, it now seems to behave as expected. |
|
At commit 3cf6234 it's still working as expected, including quitting. |
|
Still looking good at commit d5607d7. |
|
It would be good to get this merged before I open it up for some of the other selection issues that were discussed int he 5/17 meeting. I think this is an improvement over what's there, and this would establish a platform for the further changes. There is stuff in the Tedit code and documentation that I don't understand, and which make the implementation a little complicated...and I would like to remove. The documentation (Section 8) specifies that the last selection of various types are to be stored in global variables (e.g. TEDIT.SELECTION, TEDIT.SHIFTEDSELECTION, TEDIT.MOVESELECTION). What would these be used for? Also, the function TEDIT.SETSEL is documented as taking an OPERATION, which can be NORMAL, MOVE, COPY, PENDINGDEL, or DELETE. What would it mean to say that a selection is a MOVE or COPY selection? The documentation says that it would affect the highlighting of the selection (broken underline, maybe black...) but I don't see when or how the actual operation would be executed, since the target isn't specified. The screen may be consistent with the selection, but it is misleading about what might actually happen. And there are separate entries TEDIT.MOVE and TEDIT.COPY that take source and target selections and do the operation. (PENDINGDEL makes more sense--the selection itself would be the target for deletion on the next insertion). |
|
Those global variables are used by TEXEC - I haven't read the code, just noted that they're used there. |
|
Hmm, TEXEC has never worked, it's on the list to rethink.
… On May 18, 2026, at 11:56 PM, Nick Briggs ***@***.***> wrote:
nbriggs
left a comment
(Interlisp/medley#2604)
<#2604 (comment)>
Those global variables are used by TEXEC - I haven't read the code, just noted that they're used there.
It appears to change things in the globals, and then uses \\COPYSEL to perform an operation using one of the selections as source or destination.
—
Reply to this email directly, view it on GitHub <#2604 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJPOHYGLUVJLWQKYXP343QASTAVCNFSM6AAAAACYYRHN3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DIOBVGE3TKMBSGU>.
You are receiving this because you were mentioned.
|
|
Still no issues at commit a8b8f3f. |
nbriggs
left a comment
nbriggs
left a comment
There was a problem hiding this comment.
LGTM - working better than it was. Still things to fix... in another PR.
3 participants
Very few files for a Tedit PR...
TEDIT-FILE just fixes a bug in TEDIT.FORMATTEDFILEP for the earliest Tedit format version (version 0, early 1985). This showed up in the HCFILES tests #2598.
Trivial change for the initial window size, as requested by @nbriggs #2517. It now calls GETREGION instead of GETBOXREGION, passing the earlier parameters as minimum sizes. So it allows the user to drag out a region larger than the one that is heuristically suggested.
Of more subtlety, I noticed that if you have two formatting menus (e.g. charlooks and paralooks) above a main Tedit window and you close the one closest to the main, the one above it wasn't moving down to close the space. That had to do with the order of evaluate of closing the window and deactivating it, which this now hopefully gets right.
But I also noticed another oddity: If you have a menu open above the main, the PSW shows a process for the main and a process for the menu, as expected. If you close the main while the menu is open, both windows close, but only the menu's process disappears. The main's process still shows up in the PSW. If you close a main window when there is no menu, then the PSW is cleared.
The logic of deactivating was to close the window and then give the TTY back to the command loop of the main process, which was supposed to then return and presumably allow the process to go away. That apparently wasn't happening, for reasons unknown to me.
I changed the deactivation code (TEDIT.DEACTIVATE.WINDOW so that it kills the process immediately, by calling TEDIT.KILL which calls DEL.PROCESS directly. That seems to have cleaned things up.
This may also clean up something else that I have noticed: in my mode of running is to bring up a lot of transitory Tedit windows via the tf and ts commands in TEDIT-PF-SEE. I look at something, then close the window, expecting the process to go away. But after quite awhile I end up with a mysterious stack overflow. If I reset out of that, all of the old , closed windows pop back up with an "inactive" label. They are not useful--clicking on them blows them away. I surmise--correct me if I'm wrong--that the prior closing sequence was somehow taking those processes out of the PSW but they were still there and still holding on to stack space. (Perhaps there was a secret circular backlink between the stream, window, and process?)
I'm hoping that expliciting deleting the process will solve this problem (even if there is a backlink).