Jens Schmidt <[email protected]> writes:
> "J.D. Smith" <[email protected]> writes:
>
>> Seems like we're converging here; would be useful to get a few more
>> people testing.
>
> I agree only on the latter, as you might see from yet another lengthy
> mail. And regarding the latter, have you considered asking Sacha to
> include testing of `org-inside' in the "Help Wanted" category on her
> blog? I guess that would have quite a reasonable reach.
I suspect the normal testing channels will be sufficient. If we
configure it as a default, many will come across it. In my experience
it's better to gather a number viewpoints; tailoring too much to a
single point of view can lead to over-tuning.
> * Another Sticky Bar Cursor
>
>>> Start with the usual incantation ("make repro", o-h-e-m (I've set the
>>> default to true already in Org's sources!), open test file, o-i-m, move
>>> into emphasis and ensure cursor is bar). Then:
>>>
>>> + C-x t 2
>>> + C-x t o
>>> + M-x org-inside-mode RET
>>> + C-x t o
>>> -> Cursor stays bar.
>>
>> I can't reproduce this. The cursor is removed for either; maybe it's a
>> recent change. I don't use inbuilt tabs but the native ones in my
>> build, which are just frames.
>
> Ok, here is some more information on that. I cannot reproduce that for
> Emacs 30.2, either, only for Emacs 31+. The reason is this one hook
> *non*-addition for Emacs 31+ in org-inside:
>
> ;; In v31+, buffer-local window-buffer-change-functions fire for a
> ;; buffer appearing AND disappearing from a window.
> (when (< emacs-major-version 31)
> (add-hook 'window-buffer-change-functions #'org-inside--frame-changed))
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.
Note that the buffer-local treatment of 'window-buffer-change-functions
is newly expanded:
*** 'window-buffer-change-functions' is run for removed buffers too.
The buffer-local version of 'window-buffer-change-functions' may be run
twice now: Once for the buffer removed from the respective window and
once for the buffer now shown in that window.
Are you interested in opening a report?
> The `window-buffer-change-functions' also fire when you change tabs. If
> I add `org-inside--frame-changed' to `window-buffer-change-functions'
> for Emacs 31 as well, that function gets called when I switch tabs,
> which cleans up the stray bar cursor.
>
> (Which also means that I *can* reproduce this issue on Emacs 30 when I
> remove above hook addition for Emacs 30.)
>
> I'll leave it to you whether and how you'd like to fix that. Probably
> employ `window-configuration-change-hook' in some way or other?
The goal is to remove the global hook.
> * Nested Emphases
>
> Are you aware that nested emphases or emphases in links do not work
> entirely as one might expect? To notice that, of course, o-i-a must
> include :face or :unhide. Reproduces in 30.2+.
>
> For example, if you manage to directly navigate to "bar" in the
> following example:
>
> *foo =bar= baz*
>
> *without* crossing the outer emphasis, then only =bar= gets overlayed
> (which is OK). But when you leave from =bar= to the inside of the outer
> emphasis, the overlay is not removed, since there is no difference in
> cursor sensor functions. Only when you leave the outer emphasis as
> well, the overlay on =bar= gets removed.
>
> Honestly, I'd leave that as is.
Hmm. What is the state of support for nested emphasis? I've never seen
it work well, except for bold/italic (which seems to work OK, though it
depends on which level you enter first).
Perhaps finding the *topmost* emphasis/link ancestor is the right
approach; can anyone recommend a way to do that?
Currently using:
(when-let* ((ctx (org-element-context)))
(org-element-lineage ctx '( link bold code italic verbatim
underline strike-through) t))
> * Overlays Not Removed When Breaking Emphasis
>
> You have implemented overlay removal if text properties get fontified
> away by using function `org-inside--overlay-modification' (thanks).
> There is one corner case that that modification tracking cannot catch,
> though: If you add, say, letter "a" before the leading marker of
>
> =foo=
>
> where the markers previously have been unhidden with C-c C-c. That
> breaks the emphasis, but since the modification happens outside of the
> overlay, it does not get noticed.
>
> Again, could be ignored as corner case IMO.
I do think that is sufficiently rare to be ignorable. Once you move off
it disappears, and things look sufficiently broken when in this state
anyway.
> * More "Natural" Cursor Movement?
>
> If you remember the beginning of this thread, you might recall that I
> have been whining because of the cursor "jumping" at emphasis markers.
> I took your explanation as given back then, but have reconsidered this
> since then, after I understood org-inside better. That jumping happends
> because of cursor adjustments around the markers. But there is really
> no need for that. Optionally and without too much effort (prototype
> available) one could have cursor movement like described below, which
> feels much more natural at least to me.
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).
> Assume o-i-a on default, input text is "foo =bar= baz". "[a]" means
> point is with block cursor before "a", "|a" likewise for bar cursor.
>
> We start like this, just before the leading equal sign:
>
> foo [b]ar baz
>
> C-f
>
> foo |bar baz
>
> C-b
>
> foo [b]ar baz
>
> That is, visibly point does not move - it stays before the "b". But it
> moves over the hidden marker and the cursor shape changes accordingly,
> giving you the indication whether you're outside or inside. Likewise
> for the trailing marker:
>
> foo bar| baz
>
> C-f
>
> foo bar[ ]baz
>
> C-b
>
> foo bar| baz
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. Breaking that is likely to give people strange "this
is broken" vibes; some people navigate entirely by C-b/f, for example.
The only "cost" of preserving natural cursor motion is the need to move
back one point if you want to edit text just inside. Since that's a
much rarer action than casually moving point through some hidden-marker
text, it makes the most sense to optimize for the latter.
To give you a clear sense of how I use this, I (nearly) NEVER actually
see the markers. I don't want to see them. I have key bindings that
emphasize the current symbol. And I can use org-inside to precisely
edit around the borders of hidden-markers without every revealing them.
In my usage, they are just a detail.
