> Will it solve the problem with ,@body somehow triggering window > configuration change?
Yes it will > 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. > 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).
