* org-fast-todo-selection window behaviour?
@ 2019-10-20 18:43 Matt Price
2019-10-21 9:46 ` Carsten Dominik
0 siblings, 1 reply; 4+ messages in thread
From: Matt Price @ 2019-10-20 18:43 UTC (permalink / raw)
To: Org Mode
[-- Attachment #1: Type: text/plain, Size: 851 bytes --]
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!
[-- Attachment #2: Type: text/html, Size: 1020 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: org-fast-todo-selection window behaviour?
2019-10-20 18:43 org-fast-todo-selection window behaviour? Matt Price
@ 2019-10-21 9:46 ` Carsten Dominik
2019-10-23 18:10 ` Matt Price
0 siblings, 1 reply; 4+ messages in thread
From: Carsten Dominik @ 2019-10-21 9:46 UTC (permalink / raw)
To: Matt Price; +Cc: Org Mode
[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]
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 <moptop99@gmail.com> 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!
>
>
[-- Attachment #2: Type: text/html, Size: 1798 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: org-fast-todo-selection window behaviour?
2019-10-21 9:46 ` Carsten Dominik
@ 2019-10-23 18:10 ` Matt Price
2019-10-24 9:03 ` Carsten Dominik
0 siblings, 1 reply; 4+ messages in thread
From: Matt Price @ 2019-10-23 18:10 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Org Mode
[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]
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 <dominik@uva.nl> 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 <moptop99@gmail.com> 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!
>>
>>
[-- Attachment #2: Type: text/html, Size: 2466 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: org-fast-todo-selection window behaviour?
2019-10-23 18:10 ` Matt Price
@ 2019-10-24 9:03 ` Carsten Dominik
0 siblings, 0 replies; 4+ messages in thread
From: Carsten Dominik @ 2019-10-24 9:03 UTC (permalink / raw)
To: Matt Price; +Cc: Org Mode
[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]
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 <moptop99@gmail.com> 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 <dominik@uva.nl> 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 <moptop99@gmail.com> 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!
>>>
>>>
[-- Attachment #2: Type: text/html, Size: 3109 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-10-24 9:03 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-20 18:43 org-fast-todo-selection window behaviour? Matt Price
2019-10-21 9:46 ` Carsten Dominik
2019-10-23 18:10 ` Matt Price
2019-10-24 9:03 ` Carsten Dominik
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).