"J.D. Smith" <[email protected]> writes: >> 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?
No, I am pretty sure I saw what I described. But I can no longer reproduce on the latest org-inside branch and the latest Emacs master. Let's consider this to be a non-issue. >>>> 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? >>> 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? I cannot reproduce now either. Consider as non-issue. >> 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. Fair. It is not something I see as a blocker. >> 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. 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. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
