Re: Recent changes in org-fold regarding emphasize visibility
Ihor Radchenko writes: > I have made changes in invisible edit handling. > Now, when using 'text-properties style, > org-fold-check-before-invisible-edits ignores folded links just like it > does with overlays style. > > The commit is 2e4ed52b1. Looks good; thank you Ihor! -- Daniel Fleischer
Re: Recent changes in org-fold regarding emphasize visibility
Daniel Fleischer writes: >> The question is what should be the logical behaviour of Org when editing >> text inside or at the border of these hidden text types? How should we >> interpret the values of org-catch-invisible-edits (nil error show >> show-and-error smart)? > > Not sure we need to reinterpret the settings; roughly they cover the > different options of what to do when you edit a hidden text: edit > anyways, throw an error, unfold but do nothing, unfold and do what you > wanted to do and the only thing I don't have an intuition about is the > smart option. > > BTW, there are no issues when the folding core style is "overlays". So > why not follow what happens in that case, even formalize it into tests? Reasonable. I have made changes in invisible edit handling. Now, when using 'text-properties style, org-fold-check-before-invisible-edits ignores folded links just like it does with overlays style. The commit is 2e4ed52b1. Let me know if you are getting the expected behaviour now. Best, Ihor
Re: Recent changes in org-fold regarding emphasize visibility
Ihor Radchenko [2022-05-07 Sat 12:22] wrote: > Now, we have different kinds of hidden text at hand: > - folded headlines/lists > - folded drawers > - folded blocks > - folded links/emphasis > > The question is what should be the logical behaviour of Org when editing > text inside or at the border of these hidden text types? How should we > interpret the values of org-catch-invisible-edits (nil error show > show-and-error smart)? Hi Ihor, Not sure we need to reinterpret the settings; roughly they cover the different options of what to do when you edit a hidden text: edit anyways, throw an error, unfold but do nothing, unfold and do what you wanted to do and the only thing I don't have an intuition about is the smart option. BTW, there are no issues when the folding core style is "overlays". So why not follow what happens in that case, even formalize it into tests? Best, -- Daniel Fleischer
Re: Recent changes in org-fold regarding emphasize visibility
Daniel Fleischer writes: > Ihor Radchenko writes: > >> Fixed on main by d2a459d25 > > I've tried the commit. I think there are still issues. E.g. given a > folded headline > > * Introduction...| > * Section > > Inserting text at that point will do the following thing depending on > `org-fold-catch-invisible-edits': > > - error : it inserts the text without unfolding; most dangerous. > - show : unfold, insert the text without displaying it; dangerous. > - show-and-error: unfold but inserts the text anyways. Thanks for testing! The problem here is that emphasis markers and links are also partially hidden and it is a good idea to check invisible edits there. It's just that they were ignored by org-catch-invisible-edits in the past. But not anymore. I afraid that it is impossible to follow the present docstring for org-catch-invisible-edits without mixing 'error/'show-and-error with 'smart. It's perfectly fine to insert text right after trailing ]] of the links, but, as you showed, not after folded headline contents. Now, we have different kinds of hidden text at hand: - folded headlines/lists - folded drawers - folded blocks - folded links/emphasis The question is what should be the logical behaviour of Org when editing text inside or at the border of these hidden text types? How should we interpret the values of org-catch-invisible-edits (nil error show show-and-error smart)? Best, Ihor
Re: Recent changes in org-fold regarding emphasize visibility
Ihor Radchenko writes: > Fixed on main by d2a459d25 I've tried the commit. I think there are still issues. E.g. given a folded headline * Introduction...| * Section Inserting text at that point will do the following thing depending on `org-fold-catch-invisible-edits': - error : it inserts the text without unfolding; most dangerous. - show : unfold, insert the text without displaying it; dangerous. - show-and-error: unfold but inserts the text anyways. Thanks, -- Daniel Fleischer
Re: Recent changes in org-fold regarding emphasize visibility
Daniel Fleischer writes: > (setq org-fold-catch-invisible-edits 'show-and-error) > > in order to prevent accidental write in the following places: > > :PROPERTIES:|... > > But now, hidden emphasize symbols are considered "folded" so when I > write: > > *Hello*| > > and about to press "space" I get a warning. > > I think this is a regression. I don't want to change the > `org-fold-catch-invisible-edits' variable to something else because I > worry more about accidental edits in real folded regions. I don't > understand why emphasize markers are treated as folded text. > > `org-hide-emphasis-markers` is set to non-nil. Fixed on main by d2a459d25 Best, Ihor
Recent changes in org-fold regarding emphasize visibility
There are some recent (week old) changes to org-fold that changes fold/emphasize behavior. Before the changes, I used to have (setq org-fold-catch-invisible-edits 'show-and-error) in order to prevent accidental write in the following places: :PROPERTIES:|... But now, hidden emphasize symbols are considered "folded" so when I write: *Hello*| and about to press "space" I get a warning. I think this is a regression. I don't want to change the `org-fold-catch-invisible-edits' variable to something else because I worry more about accidental edits in real folded regions. I don't understand why emphasize markers are treated as folded text. `org-hide-emphasis-markers` is set to non-nil. Best, -- Daniel Fleischer
