Upfront: Thanks for your changes. You haven't pushed them yet, have you? At least I'm still up-to-date on e3ccd22 after a pull.
"J.D. Smith" <[email protected]> writes: >> Even w.r.t. "that small difference" when exiting an explicitly unhidden >> emph text to the rear end. That is, an explicitly unhidden emph text >> stays visible only while point is in a left-closed, right-opened >> interval like this: >> >> [=emphasized text=) > > By which you mean you cannot place point here ([X]): > > =emphasized text=[X] > > and have the markers remain visible? That's the situation we have (see > below). Yes. > Oh, I think I had intended to do so! Did you test with that enabled? Yes, I have, and with that the markers remain visible even with point just after the rear marker. > I agree that the symmetry of left-closed + right-closed makes the most > conceptual sense. In fact it works just fine with REAR-ADVANCE even > in v30. Although now testing I see the issue with that: when markers > are visible with point here: > > =emphasized text=[X] > > inserting new text extends the "inside" overlay and its styling (of > course; it's REAR-ADVANCE). I haven't tested inserting new text, but I was already half-afraid that there could be some unwanted side-effects of setting REAR-ADVANCE. > So maybe half-open is the lesser of two evils. In particularly since - realistically - you not very often would like to have point just after the rear marker. (Except to test org-inside, maybe.) > Understood. Seems fine to return a value; done. I just tried on > `org-ctrl-c-ctrl-c-hook' and it indeed works very well, and really fits > the "do something here" vibe of C-c C-c. /Great/ idea. Thanks, I'm glad I could bring home that idea. >> Probably Ihor had something like that in mind when he mentioned >> `org-reveal' up-thread. For example, o-i-t-h could be added to some new >> hook `org-fold-reveal-visibility-hook' which would get executed like >> this in `org-fold-reveal': >> >> diff --git a/lisp/org-fold.el b/lisp/org-fold.el >> index 58debf401..d08a14f9b 100644 >> --- a/lisp/org-fold.el >> +++ b/lisp/org-fold.el >> @@ -712,7 +712,8 @@ With a \\[universal-argument] \\[universal-argument] >> prefix, \ >> go to the parent and show the entire tree." >> (interactive "P") >> (run-hooks 'org-fold-reveal-start-hook) >> - (cond ((equal siblings '(4)) (org-fold-show-set-visibility 'canonical)) >> + (cond ((run-hook-with-args-until-success >> 'org-fold-reveal-visibility-hook)) >> + ((equal siblings '(4)) (org-fold-show-set-visibility 'canonical)) >> ((equal siblings '(16)) >> (save-excursion >> (when (org-up-heading-safe) > > Interesting idea. I don't use org-reveal so this could be done > separately. That is my problem as well - I know that having o-i-t-h feels good on C-c C-c, but I'm not sure how it feels in the org-reveal context. > Done. > Yes it did some extra work, for org-inside buffers shown in multiple > windows. I updated it to avoid that. > Thanks, had frames enabled for reset but not teardown. Thanks x 3. > Indeed, I have seen that behavior too. Exit overlays are important for > things like links that are more than one hidden char on each side. Font > lock does not remove the overlay, and it isn't really the place to look > for entities gone bad. > > I think I have a solution. I have now implemented an overlay > modifications-hooks function, which I use to detect (using org-element) > when the overlay should "self destruct". Please give a try. Looks good > in my tests. Will test after I get the latest commits. Here is another idea I came up with. It is completely untested and it may not even work. Plus I cannot say how it in practice compares to your solution. If it worked it would have probably the advantage of not using yet another hook type: - In `org-inside--sensor' and on enter, add another cursor sensor function `org-inside--detect-removal' to the text property span just entered - and only to that, do not add it to the overlay. - Now when font-locking removes the text property because markers or link markup have changed, I expect `org-inside--detect-removal' to get called with exit direction, what could be used to remove the overlay. - Otherwise, on regular exit, remove cursor sensor function `org-inside--detect-removal' again from the text property span just exited. > It occurred to me that some people may /like/ the earlier behavior, > since when you accidentally destroy a link/emphasis through edits, you > could still see a visual indication of where it was (if. you alter face, > e.g. add an underline). Hm. There is always C-_. > But I think the new behavior is less surprising overall. I could be > convinced to include a config option I wouldn't, but that's your decision. >> * Random and Completely New Review Notes Thanks for working on these, too, but here I'm also interested to see what exactly you have implemented, so I'll postpone my comments.
