I appreciate your further review.
> "J.D. Smith" <[email protected]> writes: > > * Window Configurations [was: Another Sticky Bar Cursor] >> >> Interesting. I don't know how tabs are treated w.r.t. window change >> functions, but IMO they "should" fire buffer-locally for both entering >> and exiting the buffer (on tab change), so this global hammer should not >> be needed. I'd say this could be considered a bug/omission in v31. > > I tried to get my point through by delicate hints here and there, but > obviously have failed to do so. So here rather bluntly, hoping not to > lecture you more than needed: For future interactions, I find this type of language unhelpful. Concrete patches with brief justification are much more valuable. > - Tabs are special window configurations. Changing a tab just changes > the frame's window configuration. > > - From the documentation of window configurations, I cannot deduce that > changing one should run `window-buffer-change-functions'. Changing a > window configuration places a previously stored complete set of > windows and their buffers on the glass, but, at least in my > perception, the buffers inside these windows do not change. > > IOW and IMO, changing a buffer in a window happens on a different > scope than changing a window configuration in a frame. Your diagnosis is wrong, but so was my suggestion that this is a bug. The buffer-local hook of `window-buffer-change-functions' /does/ run on tab changes, as expected, so it handles all the usual cases. The issue you found is that non-active background tabs are not returned by `get-buffer-window-list', so the specific case of disabling the mode in an org-inside buffer in one tab can leave the now-unwanted overlay and altered cursor-type in background tabs "stranded". > * Window Configurations and Window Parameters > > And another interesting fact that I have mentioned only indirectly, by > referencing the documentation: > > - Window configurations (and the related window states) by default do > *not* store window parameters. See `window-persistent-parameters'. I am also surprised the `org-inside-overlay' parameter survives a round trip through a background tab (which is just a saved window configuration). The window-configuration objects are opaque structures and capture very detailed information; window-persistent-parameters applies to higher-level window-state. If you care to investigate and understand this, it could be valuable. In any case, I have bent to reality and now just add to the global hook for all emacs versions, which should fix the problem (and others we never yet identified in its class). > - So changing window configurations can nuke your window parameters, and > org-inside to some extent relies on these. I have not been able to > reproduce an org-inside bug out of that fact, mainly because - > contrary to the documentation - window parameters seem to be pretty > persistent in window configurations. The overlay can be lost and recreated any time it is needed, so that is no concern. The only issue is "stale" overlays sticking around in a hidden window configuration, which ideally would not be saved. The global hook should handle them. > * More "Natural" Cursor Movement? > >> I recall your misconstrual of where point is with block vs. bar cursors >> was the real issue here (which may happen to others; we still need to >> decide on suitable defaults). > > Not only. More disconcerting I find the fact that the sequence C-f C-b > (or C-b C-f) does not always bring me back to the same visible state as > previously. It /cannot/ do so. At a single apparent cursor position, there are two states. Approaching from the left and from the right is precisely how these two state are reliably accessed, with the visual appearance simply affirmative confirmation. >> I had considered this option and the advantages you listed, which I >> agree with for the most part. I even tried using it for a while. But I >> dismissed it. The invariant that one C-f = one cursor motion on screen >> is pretty sacred. > > For me, obviously, the fact that C-f C-b leaves the cursor in the same > visible state on the screen as previously is more sacred. But let's > agree to disagree here. That would entirely defeat the point of org-inside. Unless you unhide the markers, there exist two states at one apparent cursor position. That is the problem we are solving. Having two separate appearances when at that single (apparent) position, so as to easily disambiguate them is /the fundamental goal/ of this mode. The good news is what you appear to want seems to me to be quite easily accomplished: simply use org-inside with nil appearance, i.e. only for summoning markers on demand. > * Replacing Overlay Modifications Hooks and Cursor Sensors > > Not sure whether you are interested in that, but the following replaces > overlay modifications hooks and cursor sensors by a text-property-only > solution. Pros: Feels simpler. Reliably destroys the overlay when > needed (because for me the cursor sensors *do* fire when their text > properties are removed). Cons: Does not work OOTB on Emacs 31+. Plus I > haven't tested it as thoroughly as you (and I) did, so it might behave > differently from your approach in some cases. I'm not sure how this can work reliably, since you need to override the original text property when entering the inner (unhidden) text. An overlay does that naturally. Otherwise, you'll have several different active exits areas when hidden text is visible. Also, you need the CSF regions to be contiguous, because you can jump in/out from/to any position. Since we need to exit elsewhere from where we entered, we have to live-update the CSF region from within the CSF function itself; the overlay was the most convenient way to do this. > * The End > > Let's call it a day here, at least from my side. Thanks for your work > and for the discussion. Agreed. Thanks again.
