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
368 stars 19 forks source link

Add arbitrary user properties to SEDIT edit-contexts #604

Open rmkaplan opened 2 years ago

rmkaplan commented 2 years ago

There is curently no way for the user to hang arbitrary properties on an SEDIT edit-context. There is a PROPS argument to the call to SEDIT, but that only allows properties that are already built in. Before I added an entry GET-WINDOW, there wasn't even a way to get the window that the SEDIT had created, to hang properties that might be useful after the sedit was constructed.

But it would be useful also to add properties to the edit-context itself, because that's actually the value that the call to SEDIT produces. And it would be useful to specify properties in the call to SEDIT that might affect how the SEDIT is constructed, in particular for the user to be able to pre-specify the window or region to use.

So, add a PROPS field to the edit-context, initially populated from the already-present but extended PROPS argument to SEDIT, and provide functions GET-PROP and SET-PROP to manipulate user-specified properties (like windows, tedit streams, streams...).

Also, for better region management, extend SEDIT:GET-WINDOW-REGION to use the value of the property :REGION if present.

rmkaplan commented 2 years ago

The main motivation, right now, is to provide information to the Sedit construction, like the desired region, BEFORE the process, window, and edit-context have been created. This could be done by hash links and the like…but that’s not the way any of the other system components (Tedit, streams, windows) implement their property interfaces.

WIth respect to circularity, I think that there are so many back and forth pointers in Tedit and Sedit and their windows and processes that tghere are potential leaks all over the place., if objects are not shut down properly (and if the shut-down knows how to break the links). They just tend to happen at user-interface time-scales, so they never build up in a noticeable way.

The user could add a circular link in the sedit props field, but they could also do that in windowprops, streamprops, teditprops etc. This doesn’t create any new danger.

On Dec 5, 2021, at 12:26 PM, Larry Masinter @.***> wrote:

I don't understand any circumstance where this would be necessary. The general way to add an arbitrary property to anything is to use an alist or hashtable or property list. Or a process property. And I'm not sure we will ultimately want memorized window regions exactly aligned with sedit windows. Does this create circular structures that are not GC'd?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/604#issuecomment-986294478, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJK4WU3BAQ24IFTV3K3UPPDGXANCNFSM5JM7BFJQ.

masinter commented 2 years ago

I don't see what this change has to do with SEDIT. You want a (LispUsers?) package to manage windows a particular way (some people say they want a Tiled window manager, for example; there are lots of styles depending on what you're used to). Anyway, I would imagine some kind of generic SEdit-independent way of "asking for a region" with some supplied constraints where there's a FLG that turns on the feature and you can try it out.

I'd be concerned -- I think the constraints might not be so easy to get right as far as minimum sizes for elements of a constellation of windows. Like I'd 'like Filebrowser windows to Shape to Fit? How can you guarantee that the cached shape is the one I would draw out based on what else is on the screen.

I'm finding Modernize on move and shape when clicking window corners frustrating because I'm never quite sure it's going to work ... will the cached region be better in all circumstances? Modern window systems have grab-areas and change the mouse cursor.

rmkaplan commented 2 years ago

This particular change only has to do with SEDIT. SEDIT documents a function and suggest that the user can redefine if they want to have better control of SEDIT’s built in region management. But that solution was only thought out half way. Such a redefinition by itself is a no-op because SEDIT doesn’t provide a way for the user to pass parameters directly to their redefined region manager. The user would also have to redefine the top-level SEDIT entry (MOVD? etc.) to add an extra region/window argument, bound as a specvar, to make the parameters available at the bottom.

It can be set up that way, with a MOVD? for the top and a redefinition at the bottom. But I thought that a more general solution was to extend it by allowing specificion and access to arbitrary properties that can be used not only for region managers but for other purposes as well, for example to allow other large-scale applications to control how SEDIT behaves as a subcomponent.

The user can pick and choose between different region managers, presumably as Lispusers packages if we can’t agree on a default beyond the null manager that we have now. That’s a separate issue. But implementing any of them depends on being able to communicate intentions, and SEDIT isn’t set up for that.

So, this is not at all about any particular region-management constraints, it’s about the infrastructure needed to do anything easily and consistently. SEDIT is an outlier.

On the MODERNIZE corners, it works quite consistently for me, except for the EXEC window. As previously noted, the bottom corners don’t work if anything at all has been typed on the line. TTYIN has grabbed control of the mouse, someone with more courage than me has to figure out how to modify that. (I have also noticed that sometimes a new EXEC created from the background menu isn’t always MODERNIZED, even though I tried to catch that.) (But: if we are going to get into complaints about the EXEC, why not make it scrollable?)

Also, I have no objection to cursor switching, I just don’t know how to do that (and don’t particularly want to learn).

Again, let me say that most of these considerations are separate from the question of modifying SEDIT so that it can play nicely with whatever higher-level management strategy the user wants to deploy.

On Dec 5, 2021, at 11:11 PM, Larry Masinter @.***> wrote:

I don't see what this change has to do with SEDIT. You want a (LispUsers?) package to manage windows a particular way (some people say they want a Tiled window manager, for example; there are lots of styles depending on what you're used to). Anyway, I would imagine some kind of generic SEdit-independent way of "asking for a region" with some supplied constraints where there's a FLG that turns on the feature and you can try it out.

I'd be concerned -- I think the constraints might not be so easy to get right as far as minimum sizes for elements of a constellation of windows. Like I'd 'like Filebrowser windows to Shape to Fit? How can you guarantee that the cached shape is the one I would draw out based on what else is on the screen.

I'm finding Modernize on move and shape when clicking window corners frustrating because I'm never quite sure it's going to work ... will the cached region be better in all circumstances? Modern window systems have grab-areas and change the mouse cursor.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/604#issuecomment-986498489, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJJMRY3YNZNB3MYIEHTUPRO2FANCNFSM5JM7BFJQ.