[Top][All Lists]

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

bug#33870: 27.0.50; xref-goto-xref not configurable

From: martin rudalics
Subject: bug#33870: 27.0.50; xref-goto-xref not configurable
Date: Tue, 08 Jan 2019 10:25:10 +0100

> You may argue that by making them public *now* we are going to have a
> more deprecation problem if we decide to rename them again *in the
> future*.  I would agree with you there.

The DEDICATED argument of 'window--display-buffer' is a very gross
hack that nobody among us will understand in all its consequences.
Try to guess its semantics from the fairly underdocumented variable
'display-buffer-mark-dedicated' and how it's set by the various buffer
display actions - most of them copying the call scheme from another.

IIUC the idea is that a "reused" window should not be made dedicated
while a new window could be made dedicated.  So we could guess the
intention from the TYPE argument - unless it's 'reuse', dedicate the
window if asked for.  But we do not implement that consistently.

So before making this function public, we should resolve this calling
convention.  Personally, I'd proceed as follows:

(1) Deprecate the variable 'display-buffer-mark-dedicated'.

(2) Remove the DEDICATED argument from this function.

(3) Add a 'dedicated' action alist entry to implement the

And we should specify once and for all whether a window can remain or
become dedicated when our function displays another buffer in it.

And another thing: The term "reuse" has two meanings in the context of
buffer display: OT1H "reuse" stands for reusing a window showing one
and the same buffer like in 'display-buffer-reuse-window'.  In
'window--display-buffer', if TYPE equals 'reuse' this just means that
an existing window has been reused for showing BUFFER - that window
might have shown another buffer before.  This confusion would have to
be resolved as well before going public with this function.


reply via email to

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