Closed SPFabGerman closed 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.
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.
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?
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 ofsub1
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 inorg-appear--prev-frag
, we simply save the previouspoint
and reevaluate the element context in the post-command-hook. This way we can react to changes in the current fragment.