"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.
* C-c C-c Hook Afterthoughts
> Interesting. Does that happen for other contexts?
Probably not. So it might really just something I need to get used to.
* 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))
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?
* 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.
* 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.
* 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.
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 see the following advantages here:
- It can be made optional - if you like "your" behavior better, just
keep it.
- It cleanly keeps your philosophy of inside and outside.
- It makes both sides of the markers easily reachable as targets.
- It keeps the property of sequences "C-f C-b" and "C-b C-f" bringing
you back to your original point. (Which currently is not true around
markers.)
- It can be extended naturally to links as well.
I *still* have more to discuss, I hope you're not weary yet. But I
think small increments better keep the discussion flowing...
