For those of you who use `org-hide-emphasis-markers=t' (and not `org-appear'), I'm sure you've experience the phenomenon of not knowing where edits will go when point is "adjacent" to emphasized text. Is point inside or outside of the markers?
I recently worked up a small pair of advices to org fontification, to aid precise editing at the ends of emphasized text. So far it has proven very intuitive. The approach: 1. Apply `rear-nonsticky=(... invisible)' to both the front and back hidden markers. [1] 2. Change cursor (e.g. from box to bar), when edits would occur /inside/ the markers of the emphasized text. This requires placing a `cursor-sensor-functions' property on the entire emphasized text (save the leftmost marker). The `rear-nonsticky' property causes the display engine to place point on the RHS/LHS of the hidden markers depending on what side they are /approached from/ (from outside direction: stay out; from inside direction: stay in). The video linked below should make this clearer. This could potentially be a minor-mode — `org-hidden-cursor-mode' or so — which could allow customizing the "inside" cursor type/color, etc. It could apply to keywords, links, etc. as well. It would need to turn on `cursor-sensor-mode'. Find more details, the several lines of code implementing this for emphasized text, and a video demo, here: https://gist.github.com/jdtsmith/87ce361830466dd9ab2e304d17ddc2e4 Happy to contribute some code for this if you think it could be a good fit for Org. JD [1] I noticed this comment relating to rear-nonsticky at match-end 3: ;; FIXME: This would break current behavior with point ;; being adjusted before hidden emphasis marker when ;; using M-b. A proper fix would require custom ;; syntax function that will mark emphasis markers as ;; word constituents where appropriate. ;; https://orgmode.org/list/87edl41jf0.fsf@localhost ;; (org-rear-nonsticky-at (match-end 3)) I think this becomes a feature when cursor changes.
