Jens Schmidt <[email protected]> writes:
> On 2026-05-02 02:04, J.D. Smith wrote:
>
>> Jens Schmidt <[email protected]> writes:
>
>>> - I get warnings when compiling with Emacs 28, which is my default
>>> for *compiling* Org mode (but not for executing it):
>>>
>>> Compiling single /home/jschmidt/work/org-mode/lisp/org-inside.el...
>>>
>>> In toplevel form:
>>> org-inside.el:135:1: Warning: variable ‘_’ not left unused
>>> org-inside.el:145:1: Warning: variable ‘_’ not left unused
>>> org-inside.el:153:1: Warning: variable ‘_’ not left unused
>>>
>>> In end of data:
>>> org-inside.el:110:12: Warning: the function ‘set-window-cursor-type’ is
>>> not
>>> known to be defined.
>>> org-inside.el:104:24: Warning: the function ‘window-cursor-type’ is not
>>> known
>>> to be defined.
>
>> Thanks for your thoughts. I'm sorry, I should have mentioned this
>> requires Emacs v30+.
>
> Ah! But would org-inside be part of Org mode itself? Which Org mode
> version?
As Ihor mention, Org v10 (presumably to ship with Emacs v32?).
> Anyway, when compiling with Emacs 30.2 above warnings do not appear.
Great. We could potentially enable partial support on v29; see my other
message.
> * Test Setup
>
> Anyway, to have a clear setting, let's repeat all that with:
>
> - Org mode commit 4f8deec3e50c1ec7c339924e0bd719ee02b4944a on your
> branch.
>
> - Compiled with Emacs 30.2 (official tar ball) like this:
>
> cd ~/work/org-mode
> make EMACS=/usr/local/emacs-30.2/bin/emacs
>
> - Examples executed with that very same Emacs 30.2 like this:
>
> cd ~/work/org-mode
> make EMACS=/usr/local/emacs-30.2/bin/emacs vanilla
>
> And to repeat from my original mail:
>
> - (setq org-hide-emphasis-markers t)
>
> - (setq org-inside-appearance '(:unhide t))
>
> - M-x org-inside-mode RET (per Org mode buffer)
>
> - Reference example:
>
> -------------------------
> Foo =bar0 bar1 bar2= baz.
> -------------------------
>
>
> * Many Bugs Gone!
>
> And ... no bugs to be seen with above setup! Not this one:
> nor this one:
> nor this one:
Good, thanks for checking this. If someone can replicate this test on
v31 and provide any backtraces I'd appreciate.
> * Emacs Master Being the Culprit
>
> So this is something related to Emacs master. And unfortunately I don't
> have the time to follow up on that myself, so probably you'd like to see
> why these bugs happen on master. Here is some information I have
> collected, though:
>
> With the following diagnostic patch:
>
> diff --git a/lisp/org-inside.el b/lisp/org-inside.el
> index 29ba9b6ed..a7cf38ff6 100644
> --- a/lisp/org-inside.el
> +++ b/lisp/org-inside.el
> @@ -115,6 +115,7 @@ To be set via the `cursor-sensor-functions' property on
> hidden-marker
> text. WIN and TYPE are the window and cursor movement type."
> (cond
> ((eq type 'entered)
> + (message "point: %d" (point))
> (let ((beg (1- (previous-single-property-change
> (1+ (point)) 'cursor-sensor-functions)))
> (end (next-single-property-change
>
> I can see that `org-inside--sensor' gets called in the example Org mode
> document at point 21 ("outside"!) in Emacs master when approaching the
> trailing emph marker from behind. Which is too early for your code,
> since the `next-single-property-change' rightfully returns nil when
> called at that point.
>
> With Emacs 30.2 however, `org-inside--sensor' gets called at point 20
> ("inside") and everything works out fine.
Thanks. That's strange (and unexpected). v31 did add a new sensor type
`moved' (which Ihor discovered), but I ignore that one. I also had
understood the issues you encountered were with v28, but here you are
mentioning they occur with v31? Can you confirm (or is it both)?
> * Remaining Issue
>
> So the only thing left from my previous mail is actually this one:
>
>>> Obviously, I prefer my mode's behavior, since it lets me easily add
>>> text on all sides of the markers.
>
>> But you can easily add text precisely outside the markers! If point
>> appears adjacent and the markers do not appear, you can be confident you
>> are outside the markers. Inside/Outside. That's the mental model of
>> org-inside.
>
> I see and I understand that mental model (and in Emacs 30.2 it behaves
> consistently as well :-). But then my mental model is different, and we
> likely have to disagree here. Two arguments I can see in favor of my
> mental model:
>
> - I find it inconvenient or even slightly creepy to add text before the
> leading emph marker when I don't see it. Even if I might know that it
> is there.
Keep in mind the default intended use here is not un-hiding the markers,
but altering cursor and/or face so you don't have to. In that case you
never see the markers, unless they are malformed. I basically /never/
see markers, because I usually use key bindings to apply them[1] to
existing text.
Right now you have to "guess" where an insertion will fall: inside or
outside. `org-inside' takes the guesswork out, without the jarring
re-wrapping that occurs with unhiding/rehiding. It's the best of both
worlds (IMO).
> - ISTR that org-appear uses also my mental model, so you'd might have a
> hard time winning its users. If that was your plan.
No, it wasn't. To make sure I understand your mental model, let me
restate it: if an insertion at point would appear either inside the
hidden markers OR /directly adjacent to/ (but outside) them, markers are
revealed. You can see why that wouldn't work at all in the default "not
un-hiding case": the point of maximum ambiguity would remain.
>> The reason why makes more sense when you just change the
>> cursor or add a face, like '(:face (:underline "magenta")).
>
> I see. I tried these settings but I find it slightly inconvenient that
> for these I cannot directly navigate to the character, say, after the
> leading emph marker when coming from before that.
> So I have to do the extra C-f C-b to move point to after the leading
> emph marker. Likewise for the trailing emph marker when I come from
> behind it.
Yes, that is expected, and is the small price paid to switch positions
at the point of ambiguity (with the gain of no jarring markers
appearing). If you think about it, you'll see that the only way to
disambiguate without marker un-hiding is based on this "direction of
approach":
Come from outside? Stay outside. Come from inside? Stay inside.
For people who do not want to pay this price and don't mind the markers
flashing on and off, that's what :unhide is for.
If you work with it for a little while, I think you'll find it becomes
quite natural. I've been using it for many months, and in other Apps
like Apple Notes or MS Word I get annoyed that I can't us the same
method to precisely extend (or adjoin without extending) some italic
text or so. They all have the "guess and hope" approach.
> * Plus One New Issue?
>
> Oh, and here is another one with (:cursor bar), not sure whether bug or
> intentional or whether I already started seeing pink elephants.
Pink elephants, but not entirely your fault ;).
> Start here:
>
> =========================
> Foo bar0 bar1 bar|2 baz.
> =========================
Here you are between `r' and `2' (quite self-evidently!).
> C-f
>
> =========================
> Foo bar0 bar1 bar2| baz.
> =========================
Now between `2' and ` ', as expected.
> C-f
>
> =========================
> Foo bar0 bar1 bar2 [b]az.
> =========================
Now you are between ` ' and `b'! Precisely where you moved.
> So point jumps from before the trailing emph marker to the position
> before the "b", which is one too far for my understanding? With
> `org-inside-mode' switched off things go like this, as expected:
There is no jump. The default block cursor is misleading to many,
because it appears point is /on/ a position in the buffer. In fact
point is at the left boundary of the block, between two characters. In
Emacs, point is never "on" a position, but is always /between/ two of
them. The bar makes this more explicit; you can think of the bar as the
block reduced to its left-most pixels. Try an intermediate width
'(:cursor (bar . 5)) or so to convince yourself of this.
Remembering this hidden fact[2] clarifies lots of subtle Emacs behavior.
> =========================
> Foo bar0 bar1 of bar[2] baz.
> =========================
Here you are between `r' and `2'.
> C-f
>
> =========================
> Foo bar0 bar1 of bar2[ ]baz.
> =========================
Now you are between `2' and ` '. One more C-f and you will have
repeated the same exact series of moves (just without the cursor
change):
> =========================
> Foo bar0 bar1 bar2 [b]az.
> =========================
[1] Check https://gist.github.com/jdtsmith/55e6a660dd4c0779a600ac81bf9bfc23
[2] Hidden is perhaps unfair, since the Elisp manual section
`(elisp)Positions>Point' makes this very clear:
> “Point” is a special buffer position used by many editing commands,
> ... Like other positions, point designates a place between two
> characters ... rather than a particular character. Usually
> terminals display the cursor over the character that immediately
> follows point; point is actually before the character on which the
> cursor sits.
