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? Because from https://orgmode.org/Changes.html I understand that Org mode 9.8 should at least support Emacs 28: Emacs 26 and Emacs 27 support has been dropped We maintain compatibility with the latest Emacs release, and two versions prior the latest. The latest is Emacs 30, so we drop everything before Emacs 28. Anyway, when compiling with Emacs 30.2 above warnings do not appear. > I also didn't see what `org-inside-appearance' settings you are using. That was a bit further down in my original email: >> - (setq org-inside-appearance '(:unhide t)) * 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: >> - When I switch on `o-i-m' at point-max in the reference example and >> then move backward with C-b, I get in the *Message* buffer: >> >> cursor-sensor--detect: (wrong-type-argument integer-or-marker-p nil) [4 >> times] nor this one: >> - Ok, here is another thing I'd call a real bug. But I need a different >> example: nor this one: >> To clarify: I expect that the combo C-f C-b *before* the leading emph >> marker shows and hides again the markers (which it does) and C-b C-f >> *after* the leading emph marker also shows and hides the markers. >> Which it does not, I need C-b C-f and a second C-f. * 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. * 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. - 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. > 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. To be clear, visibly things go like this for me with (:cursor bar), where "[.]" denotes the block cursor and "|" the bar cursor: ========================= Foo[ ]bar0 bar1 bar2 baz. ========================= C-f ========================= Foo [b]ar0 bar1 bar2 baz. ========================= C-f ========================= Foo b|ar0 bar1 bar2 baz. ========================= C-b ========================= Foo |bar0 bar1 bar2 baz. ========================= 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. * 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. Start here: ========================= Foo bar0 bar1 bar|2 baz. ========================= C-f ========================= Foo bar0 bar1 bar2| baz. ========================= C-f ========================= Foo bar0 bar1 bar2 [b]az. ========================= 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: ========================= Foo bar0 bar1 of bar[2] baz. ========================= C-f ========================= Foo bar0 bar1 of bar2[ ]baz. ========================= Hm.
