Hi Matt, :) Have you tried (setq org-use-fast-todo-selection 'expert) It is the least jarring implementation, and it is the setting I use. Carsten On Wed, Oct 23, 2019 at 8:10 PM Matt Price wrote: > Ah well. I find the new way jarring, but it doesn't seem to bother anyone > else, and as it's a one-line (2 character!) change for me I think I can > carry the diff in my init file for now. In any case it's a small issue I > think.An honour to find myself in disagreement with the org-founder! > > On Mon, Oct 21, 2019 at 5:47 AM Carsten Dominik wrote: > >> Hi Matt, >> >> I made this change, because I found the previous way jarring. The window >> with the selection information showed up in different places depending on >> what the current window setup is. With the new implementation, the info >> window is always in the same predictable place. After the selection is >> done, the old window setup is restored to exactly what it was.... >> >> Carsten >> >> On Sun, Oct 20, 2019 at 8:46 PM Matt Price wrote: >> >>> I've recently noticed a slightly frustrating behavour on the part of >>> org-todo that I think is new and maybe was introduced in mid-August with >>> >>> f1c030bed54737319aeb1d592e3340d6a48cea3a >>> >>> In a split frame,calling org-todo with org-use-fast-todo-selection >>> enabled, ~C-c C-t~ now calls ~delete-other-windows~ before popping up the >>> org-todo keywords window. Is this necessary? I find this behaviour >>> visually confusing and distracting, and a slowdown to my workflow. Would >>> it make sense to introduce some kind of defcustom for this? For now I'm >>> just commenting out line 10614 of org.el, but if others want to be able to >>> customize the behaviour I will submit a patch. >>> >>> Maybe there's a reason delete-other-window is necessary, but i don't see >>> it in the commit message nor immediately in the other parts of this >>> otherwise very well-documented commit >>> >>> Thanks! >>> >>>