emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Better handling of window margins


From: Joost Kremers
Subject: Re: Better handling of window margins
Date: Wed, 02 Dec 2015 20:52:51 +0100
User-agent: mu4e 0.9.15; emacs 24.5.2

On Wed, Dec 02 2015, Eli Zaretskii <address@hidden> wrote:
>> Date: Wed, 02 Dec 2015 18:43:47 +0100
>> From: martin rudalics <address@hidden>
>> CC: address@hidden
>> 
>>  >   . for splitting the window with "C-x 2" and "C-x 3", the mode could
>>  >     simply invoke the correct splitting function itself
>> 
>> When two modes simultaneously use the margins, which splitting function
>> would be chosen?
>
> It's up to the mode that wants to support splitting in any non-trivial
> manner.  The mode knows exactly what are its needs, so it is free of
> the guesswork.
>
> In any case, the same problem exists if this is somehow guessed.  The
> infrastructure cannot know enough about the modes to make a decision.

Speaking as a minor-mode author, I would expect Emacs to provide a
default that handles the known cases in a reasonable manner, the known
cases IMHO being those I described. If someday someone comes up with a
use for the margins that cannot be handled properly, it makes sense to
allow the default to be overridden.

>>  >   . for splitting the window as result of some command calling
>>  >     display-buffer, we could expect the modes to customize the
>>  >     display-buffer-* variables to control how the window is split (if
>>  >     there are currently no features/variables to that effect, we should
>>  >     add them)
>> 
>> When two modes simultaneously use the margins, which buffer display
>> function would be chosen?
>
> The same problem exists with the proposed solution, doesn't it?

If the value of `set-window-margins-function' is a single function, then
probably the function provided by the last mode to be activated in a
buffer.

Isn't that a potential problem?

-- 
Joost Kremers
Life has its moments



reply via email to

[Prev in Thread] Current Thread [Next in Thread]