Ihor Radchenko <[email protected]> writes:
> "J.D. Smith" <[email protected]> writes:
>>>>> 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.
>
> There is no plan for org-element to support parsing *inside* latex
> fragment. That would require us to implement a LaTeX parser, which is
> not something I consider reasonable for Org mode.
>
> If you want to use an existing API, consider
> `tex-font-lock-match-suscript' from tex-mode.
> It is not ideal, but it has a very simple logic we can reuse and
> probably port upstream into tex-mode itself.
> WDYT?
Instead I just reused the regexps `org-raise-scripts' uses, with
`org-inside-regexp'. Seems to work OK; see/test new commit.
To be honest, I find the sub/superscript support a little annoying,
because of the difference between a_{b} and a_b, which /appear/ the same
in the buffer, but behave subtly differently at their right boundary.
All of our other entities have hidden contents both before and after the
visible text, so this one stands out.
I've been thinking of gating the sub/super-script functionality behind a
custom var. Maybe I'm being picky; users can set
`org-use-sub-superscripts' to '{} if they hate "plain" sub-superscript
after all. Thoughts?
>>> 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.
>
> Unfortunately, this may surface beyond alignment. There are various
> places in Emacs where APIs return "visual" column or line width.
> I myself ran into multiple bugs where the interaction between
> hiding/unhiding things subtly changed the behavior.
>
> Trying to play wack-a-mole here is not a good idea in the long term. To
> the point that I'd prefer leaving this as a known bug instead of fixing
> just paragraph filling. So, please revert that fill paragraph change. It
> is complex and does not really solve the problem in all cases.
Done.
> The best suggestion I have beyond command hooks is the approach we took
> in `org-fold-catch-invisible-edits-commands' with user-customizeable set
> of commands to advice.
Oh boy. Better for users to just learn to toggle off unhiding before
doing sensitive visual-column aligmnent operations I think.
