Ignacio Casso San Román <[email protected]> writes: >> My feeling is that all these complications are not going to solve all >> possible problems with point changes. For example, there is point >> adjustment on invisible text that might trigger on redisplay or other >> things. > > I did not understand your example, but I agree that it's impossible to > solve all the potential issues if we allow complicated and unlikely > enough things. But I think that we have the chance here to fix a > likely enough scenario: invoking the agenda will split the window and > select the agenda buffer, and even if you didn't invoke it from an org > buffer, many actions in the agenda or even `org-agenda-follow-mode` > could open it in the non-selected window. Then you only need a user > defining a custom action on agenda items which requires moving point > to that entry and doing some completing-read for this to happen. If it > can be fixed without changing the behavior in the other cases and > without any other downside, I would try. Of course, I trust you more > on that last part (and you shouldn't trust me), as I don't think I > know enough about Emacs or Org internals. Still, I think my last > proposal looks safe. But if you think it's risky or not worth it, > let's leave it here, as I think we have invested too much time already > on this.
To say frankly, I have a gut feeling that introducing window shuffling into low-level routines will, sooner or later, backfire. More concrete concern is originating from digging the source code of select-window -- it will likely trigger a redisplay (or multiple) that opens a Pandora box of side effects, including frequent rendering (performance hit), and running unexpected Elisp code (Elisp constructs in the mode line, fontification, etc). Also, what you suggest feels generic enough to discuss with Emacs devs -- the problem you describe sounds like something to be addressed on the level of `save-excursion', not in Org mode code. >> The whole thing sounds to me like what we have with match >> data - we need to be aware that various functions may alter match data >> and take care to preserve it if we need to. Same with point position - >> functions dealing with redisplay and window configurations may alter >> point position, and that's something to be accounted for by the code >> calling those functions. > > Yes, but the match data issue is well documented and understood, and > this isn't. Also, the user won't know that some functions have > implicit redisplays (I for sure didn't when I used completing-read). Maybe you should request Emacs devs to document this problem then? (If they are reluctant to solve it). -- 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>
