awth13 / org-appear

Toggle visibility of hidden Org mode element parts upon entering and leaving an element
MIT License
369 stars 19 forks source link

Added support for sub and superscripts #3

Closed SPFabGerman closed 3 years ago

SPFabGerman commented 3 years ago

I added support for Sub- and Superscript markers. I used the new org-togglers branch, since the new infrastructure made it very easy to implement. (Thank you for that!)

I only encountered one small error: When you have something like word1_{sub1} word2 and then remove the {, the first letter of sub1 and the space between the words is hidden. (Since then it technically isn't a valid fragment anymore, so it hides the "previous" fragment, not knowing, that the brace disappeared and the characters moved.) I haven't found an elegant way to fix this. The only solution that I could think of, is to, instead of saving the element context in org-appear--prev-frag, we simply save the previous point and reevaluate the element context in the post-command-hook. This way we can react to changes in the current fragment.

awth13 commented 3 years ago

Thank you for the PR!

I don't see an easy fix for that bug as well - notably, it also affects other fragments, not only your contribution. If you delete stuff inside a fragment and then exit it, the package doesn't know that the fragment "boundaries" changed and deletes more than it should. Your suggestion of saving (point) to reevaluate prev-frag upon exit seems good, I'll think about how to implement this in an efficient way.

That being said, I noticed your sub/superscript handler in parse-elem checks if element has brackets and hard-codes visible-start/end based on that. This is unnecessary because all sub/superscript elements are guaranteed to have contents-begin and contents-end properties, which tell you the locations of visible-start/end. Would you mind changing that? You can refer to the code for links in parse-elem, except you don't have to check that contents-begin and contents-end exist.

SPFabGerman commented 3 years ago

Done. I have a question though: Why don't we use contents-begin / end for the emphasized words (bold, underline, ...) too? I noticed these have also the contents-begin / end set.

awth13 commented 3 years ago

Merged! Thanks again.

As for your question, this is because code and verbatim fragments (for some unknown reason) don't have the contents-begin/end properties. We could, of course, process emphasised and verbatim fragments separately but I decided that one less call to member is preferable.

P.S. I'm experimenting with allowing users to edit text inside fragments in the feature branch. If you could play around with it and leave your thoughts here, that would be great! I feel that simply disabling all modifications when inside a fragment is bad code but maybe it works?