Ihor Radchenko <[email protected]> writes:

> "J.D. Smith" <[email protected]> writes:
>
>>>  1. Subscript/superscript marker toggling
>>
>> A good idea.  I have pushed an implementation for sub/superscripts.  I
>> needed to add a new symbol `org-raise' to the invisibility spec, and add
>> a new hidden-text-functions type.
>>
>> Note that the plain variety, e.g.:
>>
>>   upper_lower
>>
>> has no positional ambiguity on the right hand side.  Point and cursor
>> have only one value there.  So no matter what, this behaves differently
>> than
>>
>>   upper_{lower}
>>
>> even if it looks the same in the buffer.  You can still /see/ where
>> insertions will go, but you can't alter in the same way by moving in
>> from one side or the other, except by appending a space or something not
>> allowable within a "bare" super/subscript.  I'm afraid there is no easy
>> way around this difference.
>
> I played a bit with this, and I find the current behavior a bit
> inconsistent.
> Consider
>
> This is foo_{bar} *foo* [[link]]
>
> 1. emacs -Q /path/to/example.org
> 2. M-x org-toggle-pretty-entities
> 3. M-x org-inside-mode
>
> When inside [[link]], the cursor is |
> However, when inside {bar}, the cursor is █.

I do not see this.  Naturally for *foo* to have inside status, you also
need to set org-hide-emphasis-markers=t.  Are you perhaps confused by
the fact that at the position where the `b` of `bar` seems to be
selected, you can have a █ cursor?  This is org-inside functioning
correctly: you have the point ambiguity there, and it indicates a
character inserted will /not/ be subscripted. If you put cursor between
b and a, do you see the bar style?

>>>  4. LaTeX fragment support
>> ...
>> Note that supporting sub/superscripts inside latex fragments is also not
>> possible at present, since those are not parsed separately by
>> org-element.  If a future version of org-element adds support
>> (i.e. sub/superscript are parsed /inside/ latex-fragment), these can be
>> supported.
>
> Can't you use latex-fragment + regexp check?

I suppose I could, but it would be a bit hackish given that we use org-element 
elsewhere.  I prefer to wait for that to improve. 

>>>  5. Configurable delay
>>>
>>> =org-appear-delay= (default =0.0=) introduces an idle-timer delay before
>>> showing hidden markers. The timer is cancelled if the cursor moves away
>>> before it fires. Useful for reducing visual noise during rapid
>>> navigation.
>>>
>>> org-inside uses cursor-sensor-functions, which fire instantaneously on
>>> entry/exit. No delay mechanism exists.
>>
>> A reasonable idea; added in `org-inside-unhide-delay', defaulting to
>> 1.0s (can consider 0.0).  Note that emacs v31 (and it's `moved' cursor
>> sensor type) is required for further delaying after each movement.
>
> Two observations:
>
> 1. It does not work for sub/superscripts

Again, I do not see this, it works for me.  Can you double-check and clarify?

> 2. I think it would make sense to have a delay for hiding as well.
>    WDYT?

Not sure about this.  Depends on why people want to see the markup 
"automatically".  I personally feel like after I've moved on to something else 
and don't care anymore, re-flowing text (I use visual-line-mode) would annoy me.

>>>  10. Pre-command hook for specific commands
>>>
>>> org-appear's =pre-command-hook= hides elements before
>>> =org-fill-paragraph= and =org-ctrl-c-ctrl-c= execute, because these
>>> commands depend on column positions and would misbehave if hidden
>>> markers were temporarily visible.
>>
>> Can someone confirm this and describe a case in more detail?
>
> Try
> * *This* is a test heading with    :tag:
> and setup org-inside to unhide.
> Then, C-u C-c C-q on the heading will align differently depending on
> whether the stars are visible or not.

I see.  I fixed the fill paragraph one already, but there I could wrap
the function.  Can you recommend a general strategy here?  I'd prefer
not to run a function on every command.  Maybe org could run an
'org-pre-align-hook or some such before every command where it aligns
text, and we could add a function to it?  You could imagine this being
useful for other tools that want to affect the alignment.

Reply via email to