bug#6204: vc-dir always splits the frame

bug#6204: vc-dir always splits the frame

[Glenn Morris]

Package: emacs
Severity: minor

emacs -Q
M-x dired RET /path/to/dir RET  ; -> dired uses the whole frame

emacs -Q
M-x cvs-examine /path/to/dir RET ;-> *cvs* uses the whole frame

emacs -Q
M-x vc-dir RET /path/to/dir RET ; -> vc-dir splits the frame and uses only half

I'd prefer it if vc-dir used the whole frame by default, like dired
and pcl-cvs do. I always end up having to delete-other-windows after
running vc-dir.

bug#6204: vc-dir always splits the frame

[Dan Nicolaescu]

Glenn Morris <rgm@gnu.org> writes:

> Package: emacs
> Severity: minor
>
> emacs -Q
> M-x dired RET /path/to/dir RET  ; -> dired uses the whole frame
>
> emacs -Q
> M-x cvs-examine /path/to/dir RET ;-> *cvs* uses the whole frame
>
> emacs -Q
> M-x vc-dir RET /path/to/dir RET ; -> vc-dir splits the frame and uses only half
>
> I'd prefer it if vc-dir used the whole frame by default, like dired
> and pcl-cvs do. I always end up having to delete-other-windows after
> running vc-dir.

The vc-dir behavior is not intentional, so please feel free to fix it.

bug#6204: vc-dir always splits the frame

[Glenn Morris]

Dan Nicolaescu wrote:

> The vc-dir behavior is not intentional, so please feel free to fix it.

Looking at cvs-examine suggests binding pop-up-windows to nil in the
vc-dir function will do.

I've given up trying to understand window management after bug#1806 though.

bug#6204: vc-dir always splits the frame

[Juri Linkov]

> I've given up trying to understand window management after
> bug#1806 though.

Yes, currently window management is a mess.

For instance, for a long time I've had in .emacs:

  (add-to-list 'same-window-buffer-names "*vc-dir*")

because I prefer buffers to appear in the same window.
I also have a lot of such lines for other packages:

  (add-to-list 'same-window-buffer-names "*Apropos*")
  (add-to-list 'same-window-buffer-names "*Buffer List*")
  (add-to-list 'same-window-buffer-names "*Colors*")
  (add-to-list 'same-window-buffer-names "*Command History*")
  (add-to-list 'same-window-buffer-names "*Diff*")
  (add-to-list 'same-window-buffer-names "*Proced*")
  ...

But I can't do the same for some other buffers, e.g. for the "*Locate*"
buffer, because `locate' uses `switch-to-buffer-other-window' instead of
`pop-to-buffer'.  I don't know why.

Now after let-binding `pop-up-windows' to nil around the `pop-to-buffer'
call, what if someone might want to restore the old behavior.
Is it possible for the user to add some setting in .emacs
to split the frame and display *vc-dir* in another window?
I don't know.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#6204: vc-dir always splits the frame

[martin rudalics]

 > Now after let-binding `pop-up-windows' to nil around the `pop-to-buffer'
 > call, what if someone might want to restore the old behavior.

I currently use the following semantics for `pop-up-windows':

---------------------------------------------------------------
Non-nil means `display-buffer' is allowed to make a new window.
A non-empty list specifies the windows `display-buffer' will
consider for splitting.  The following entries are supported
where "frame" refers to the frame chosen to display the buffer:

  largest ...... largest window
  lru .......... least recently used window
  selected ..... frame's selected window
  root ......... frame's root window

The default value t stands for the list `(largest lru)'.  This
means that `display-buffer' will first try to split the largest
window and, if that fails, the least recently used window.
---------------------------------------------------------------

The intended use is that an application calling `display-buffer'
or `pop-to-buffer' could bind this as

(let  ((pop-up-windows
	(if (eq pop-up-windows t)
	    application-dependent-value
	  pop-up-windows)))

that is, the default value can be overridden by the application,
user customizations are respected.

And obviously Lisp code should not call `switch-to-buffer' and
its colleagues.

martin

bug#6204: vc-dir always splits the frame

[Stefan Monnier]

>> Now after let-binding `pop-up-windows' to nil around the `pop-to-buffer'
>> call, what if someone might want to restore the old behavior.

Indeed.  A good way would be to provide a way to override pop-up-windows
(both nil and t) in special-display-regexps.  We already have
(same-window . t), so we only need to add the other half.

> The intended use is that an application calling `display-buffer'
> or `pop-to-buffer' could bind this as

> (let  ((pop-up-windows
> 	(if (eq pop-up-windows t)
> 	    application-dependent-value
> 	  pop-up-windows)))

> that is, the default value can be overridden by the application,
> user customizations are respected.

But maybe the user would like to follow the application's special
handling, even tho she modified her pop-up-windows for other reasons.
I think it's much better to use 2 separate variables, where the
user-controlled var is never modified by Elisp code.


        Stefan

bug#6204: vc-dir always splits the frame

[martin rudalics]

 >>> Now after let-binding `pop-up-windows' to nil around the `pop-to-buffer'
 >>> call, what if someone might want to restore the old behavior.
 >
 > Indeed.  A good way would be to provide a way to override pop-up-windows
 > (both nil and t) in special-display-regexps.  We already have
 > (same-window . t), so we only need to add the other half.

In Juri's `switch-to-buffer-other-window' case such options would be
useless anyway.

 >> The intended use is that an application calling `display-buffer'
 >> or `pop-to-buffer' could bind this as
 >
 >> (let  ((pop-up-windows
 >> 	(if (eq pop-up-windows t)
 >> 	    application-dependent-value
 >> 	  pop-up-windows)))
 >
 >> that is, the default value can be overridden by the application,
 >> user customizations are respected.
 >
 > But maybe the user would like to follow the application's special
 > handling, even tho she modified her pop-up-windows for other reasons.
 > I think it's much better to use 2 separate variables, where the
 > user-controlled var is never modified by Elisp code.

Applications that do care enough should either (1) use `split-window'
and `set-window-buffer' or (2) provide a separate customizable option
like `foo-pop-up-windows' and let the user decide whether this should
pop up a new window and where.

martin

bug#6204: vc-dir always splits the frame

[Glenn Morris]

Juri Linkov wrote:

> Now after let-binding `pop-up-windows' to nil around the `pop-to-buffer'
> call, what if someone might want to restore the old behavior.

C-x 2 M-x vc-dir        ; or whatever they use for cvs-examine

Window handling is obviously very complicated, and I think emacs-devel
is a better place to discuss general questions like these. (I have no
idea if bug#1806 can ever be closed; I'd rather this one did not go
the same way.)

bug#6204: vc-dir always splits the frame

[Juri Linkov]

> Window handling is obviously very complicated, and I think emacs-devel
> is a better place to discuss general questions like these. (I have no
> idea if bug#1806 can ever be closed; I'd rather this one did not go
> the same way.)

We need a simple customizable variable to define different window behaviors.
Perhaps improving `special-display-regexps' will do that.  After that
bug#1806 could be closed.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#6204: vc-dir always splits the frame

[Stefan Monnier]

>> Indeed.  A good way would be to provide a way to override pop-up-windows
>> (both nil and t) in special-display-regexps.  We already have
>> (same-window . t), so we only need to add the other half.
> In Juri's `switch-to-buffer-other-window' case such options would be
> useless anyway.

I was thinking of the OP's vc-dir case.

>> But maybe the user would like to follow the application's special
>> handling, even tho she modified her pop-up-windows for other reasons.
>> I think it's much better to use 2 separate variables, where the
>> user-controlled var is never modified by Elisp code.
> Applications that do care enough should either (1) use `split-window'
> and `set-window-buffer' or (2) provide a separate customizable option
> like `foo-pop-up-windows' and let the user decide whether this should
> pop up a new window and where.

If the buffer names are sufficiently regular and unique,
special-display-regexps can already provide the needed customizability
without any need for a new option.


        Stefan

bug#6204: vc-dir always splits the frame

[Juri Linkov]

>> Indeed.  A good way would be to provide a way to override pop-up-windows
>> (both nil and t) in special-display-regexps.  We already have
>> (same-window . t), so we only need to add the other half.
>
> In Juri's `switch-to-buffer-other-window' case such options would be
> useless anyway.

I replaced it with `pop-to-buffer' ;-)

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#6204: vc-dir always splits the frame

[martin rudalics]

 > I replaced it with `pop-to-buffer' ;-)

The sooner such occurrences get replaced, the sooner we find out how
often the OTHER-WINDOW switch is really needed in the Emacs sources.

martin

bug#6204: vc-dir always splits the frame

[martin rudalics]

 > If the buffer names are sufficiently regular and unique,
 > special-display-regexps can already provide the needed customizability
 > without any need for a new option.

What about cases where buffer names are not regular and unique?

Also, I'm afraid we currently ignore the fact that most users are simple
not prepared to invest their time in studying the semantics of an option
like `special-display-regexps'.

Finally, this and `special-display-buffer-names' are user options and we
again have the problem that an application binding that (or, worse,
permanently adding its buffer names to it) may conflict with users
expectations (or, worse, getting her the CHANGED outside Customize
annyoances).

martin

bug#6204: vc-dir always splits the frame

[Juri Linkov]

>  largest ...... largest window
>  lru .......... least recently used window
>  selected ..... frame's selected window
>  root ......... frame's root window
[...]
> ---------------------------------------------------------------
> The intended use is that an application calling `display-buffer'
> or `pop-to-buffer' could bind this as
>
> (let  ((pop-up-windows
> 	(if (eq pop-up-windows t)
> 	    application-dependent-value
> 	  pop-up-windows)))
>
> that is, the default value can be overridden by the application,
> user customizations are respected.

User customizations are respected here, but limited.

How the user is supposed to customize this behavior
on a per-application basis?

E.g. how to customize it to display "*vc-dir*" in another window,
but "*vc-diff*" in the same window?

It seems `special-display-buffer-names' is what we need.
It could support all values you mentioned above
on a per-application basis like:

  (("*buffer name*" (window . largest)))
  (("*buffer name*" (window . lru)))
  (("*buffer name*" (window . selected)))
  (("*buffer name*" (window . root)))

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#6204: vc-dir always splits the frame

[Juri Linkov]

>> If the buffer names are sufficiently regular and unique,
>> special-display-regexps can already provide the needed customizability
>> without any need for a new option.
>
> What about cases where buffer names are not regular and unique?

Then packages should provide separate commands to display
the buffer in the same window and in another window, e.g.
`Buffer-menu-this-window' and `Buffer-menu-other-window'.

> Also, I'm afraid we currently ignore the fact that most users are simple
> not prepared to invest their time in studying the semantics of an option
> like `special-display-regexps'.

There are simpler options `same-window-buffer-names' and
`same-window-regexps' that are very easy to understand
(a simple list of window names).

> Finally, this and `special-display-buffer-names' are user options and we
> again have the problem that an application binding that

No application should bind user customizable variables unless it's expected
by users (e.g. when a function name has the suffix `...-other-window'.)

> (or, worse, permanently adding its buffer names to it)

This is a legitimate way for an application to define
its default behavior.  Look for example at:

;;;###autoload (add-hook 'same-window-regexps "\\*info\\*\\(\\|<[0-9]+>\\)")

> may conflict with users expectations

When the default value conflicts with users expectations, the user
should be able to customize it, and user customizations should be
respected.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#6204: vc-dir always splits the frame

[Juri Linkov]

>> I replaced it with `pop-to-buffer' ;-)
>
> The sooner such occurrences get replaced, the sooner we find out how
> often the OTHER-WINDOW switch is really needed in the Emacs sources.

These settings should be customizable, not hard-coded in the source code.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#6204: vc-dir always splits the frame

[Stefan Monnier]

>> If the buffer names are sufficiently regular and unique,
>> special-display-regexps can already provide the needed
>> customizability without any need for a new option.
> What about cases where buffer names are not regular and unique?

Don't know: where are they?

> Also, I'm afraid we currently ignore the fact that most users are simple
> not prepared to invest their time in studying the semantics of an option
> like `special-display-regexps'.

The Custom :type could be improved to make it easier to specify common
parameters, indeed.

> Finally, this and `special-display-buffer-names' are user options and we
> again have the problem that an application binding that (or, worse,
> permanently adding its buffer names to it) may conflict with users
> expectations (or, worse, getting her the CHANGED outside Customize
> annyoances).

No elisp code should touch it.  It's exclusively for
user-customizations.  Applications should pass special args to
pop-to-buffer/display-buffer instead to specify its favorite
default behavior.


        Stefan

bug#6204: vc-dir always splits the frame

[Stefan Monnier]

> There are simpler options `same-window-buffer-names' and
> `same-window-regexps' that are very easy to understand
> (a simple list of window names).

I hate those for 2 reasons:
- they're very limited (can't be used to say "always in another window",
  or "maybe not the same window, but at least the same frame", ...).
- they're currently abused by elisp code.

>> (or, worse, permanently adding its buffer names to it)
> This is a legitimate way for an application to define
> its default behavior.  Look for example at:
> ;;;###autoload (add-hook 'same-window-regexps "\\*info\\*\\(\\|<[0-9]+>\\)")

This is exactly the kind of evil I don't want: such variables should
only ever be modified by the user.  And `add-hook' is an abuse here as
well since same-window-regexps is not a hook.


        Stefan

bug#6204: vc-dir always splits the frame

[Juri Linkov]

>> This is a legitimate way for an application to define
>> its default behavior.  Look for example at:
>> ;;;###autoload (add-hook 'same-window-regexps "\\*info\\*\\(\\|<[0-9]+>\\)")
>
> This is exactly the kind of evil I don't want: such variables should
> only ever be modified by the user.

I see what you mean.  An application does what its author wants to do
by default without touching user customizable variables, but the user
should be able to override that with `special-display-regexps' like

  ("*vc-dir*" . other-window)
  ("*vc-diff*" . same-window)
  ("*info*" . lru)
  ...

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#6204: vc-dir always splits the frame

[martin rudalics]

 > E.g. how to customize it to display "*vc-dir*" in another window,
 > but "*vc-diff*" in the same window?

The "same window" case is already handled by the "same-window-.." option
which prevails.

 > It seems `special-display-buffer-names' is what we need.
 > It could support all values you mentioned above
 > on a per-application basis like:
 >
 >   (("*buffer name*" (window . largest)))
 >   (("*buffer name*" (window . lru)))
 >   (("*buffer name*" (window . selected)))
 >   (("*buffer name*" (window . root)))

For the expert user all these can go to `special-display-function'.
What I had in mind is the average user who doesn't know about buffer
names or building regexps for them but cares sufficiently enough for
whether and where popup windows should be shown.

martin

bug#6204: vc-dir always splits the frame

[martin rudalics]

 >> Also, I'm afraid we currently ignore the fact that most users are simple
 >> not prepared to invest their time in studying the semantics of an option
 >> like `special-display-regexps'.
 >
 > There are simpler options `same-window-buffer-names' and
 > `same-window-regexps' that are very easy to understand
 > (a simple list of window names).

These are currently a pain to customize.

 >> Finally, this and `special-display-buffer-names' are user options and we
 >> again have the problem that an application binding that
 >
 > No application should bind user customizable variables unless it's expected
 > by users (e.g. when a function name has the suffix `...-other-window'.)

Agreed.

 >> (or, worse, permanently adding its buffer names to it)
 >
 > This is a legitimate way for an application to define
 > its default behavior.  Look for example at:
 >
 > ;;;###autoload (add-hook 'same-window-regexps "\\*info\\*\\(\\|<[0-9]+>\\)")

That's what I meant.  It messes up customization.

 >> may conflict with users expectations
 >
 > When the default value conflicts with users expectations, the user
 > should be able to customize it, and user customizations should be
 > respected.

I don't think a text like

  CHANGED outside Customize; operating on it here may be unreliable.

counts as an invitation to customize an option.

martin

bug#6204: vc-dir always splits the frame

[martin rudalics]

 >>> If the buffer names are sufficiently regular and unique,
 >>> special-display-regexps can already provide the needed
 >>> customizability without any need for a new option.
 >> What about cases where buffer names are not regular and unique?
 >
 > Don't know: where are they?

So what about the "If" in "If the buffer names are sufficiently regular
and unique"?  Could we use "Since" instead?

 >> Also, I'm afraid we currently ignore the fact that most users are simple
 >> not prepared to invest their time in studying the semantics of an option
 >> like `special-display-regexps'.
 >
 > The Custom :type could be improved to make it easier to specify common
 > parameters, indeed.

Did anyone (but you) ever write a `special-display-function'?

martin

bug#6204: vc-dir always splits the frame

[martin rudalics]

 >> There are simpler options `same-window-buffer-names' and
 >> `same-window-regexps' that are very easy to understand
 >> (a simple list of window names).
 >
 > I hate those for 2 reasons:
 > - they're very limited (can't be used to say "always in another window",
 >   or "maybe not the same window, but at least the same frame", ...).

And this will be our major pain.  The prefix "same-" is hardcoded :-(

 > - they're currently abused by elisp code.
 >
 >>> (or, worse, permanently adding its buffer names to it)
 >> This is a legitimate way for an application to define
 >> its default behavior.  Look for example at:
 >> ;;;###autoload (add-hook 'same-window-regexps "\\*info\\*\\(\\|<[0-9]+>\\)")
 >
 > This is exactly the kind of evil I don't want: such variables should
 > only ever be modified by the user.  And `add-hook' is an abuse here as
 > well since same-window-regexps is not a hook.

Precisely.

martin

bug#6204: vc-dir always splits the frame

[martin rudalics]

 > I see what you mean.  An application does what its author wants to do
 > by default without touching user customizable variables, but the user
 > should be able to override that with `special-display-regexps' like
 >
 >   ("*vc-dir*" . other-window)
 >   ("*vc-diff*" . same-window)
 >   ("*info*" . lru)
 >   ...
 >

The problem then is how to get rid of the same-window-... options.

martin

bug#6204: vc-dir always splits the frame

[Stefan Monnier]

>>>> If the buffer names are sufficiently regular and unique,
>>>> special-display-regexps can already provide the needed
>>>> customizability without any need for a new option.
>>> What about cases where buffer names are not regular and unique?
>> Don't know: where are they?
> So what about the "If" in "If the buffer names are sufficiently regular
> and unique"?  Could we use "Since" instead?

Well, it's "If" because I don't know that it's always the case.
And most likely it is not always the case.  But the exceptions are
rare, AFAICT.


        Stefan

bug#6204: vc-dir always splits the frame

[Stefan Monnier]

> The problem then is how to get rid of the same-window-... options.

What's difficult about it?


        Stefan

bug#6204: vc-dir always splits the frame

[martin rudalics]

 >> The problem then is how to get rid of the same-window-... options.
 >
 > What's difficult about it?

How would you proceed?

martin

bug#6204: vc-dir always splits the frame

[Stefan Monnier]

>>> The problem then is how to get rid of the same-window-... options.
>> What's difficult about it?
> How would you proceed?

1- fix all the Emacs code that modifies those vars.
2- declare the variable obsolete.
3- Tada!


        Stefan

bug#6204: vc-dir always splits the frame

[martin rudalics]

 >> How would you proceed?
 >
 > 1- fix all the Emacs code that modifies those vars.

IMHO the only way to do that is to (1) provide a new set of variables
Elisp code _is_ allowed to change and (2) have `display-buffer' use
these iff the respective buffer has no corresponding entry in the
special-display-... options.  If I do that and a buffer is now in the
(same-window . t) group of `special-display-regexps', how should
`Buffer-menu-switch-other-window' proceed with that buffer?  Bind
`special-display-regexps'?  Call `switch-to-buffer-other-window'?  So
far the special-display-... options had an excuse: If this variable
appears \"not to work\", ...

 > 2- declare the variable obsolete.
 > 3- Tada!

martin

bug#6204: vc-dir always splits the frame

[Stefan Monnier]

>>> How would you proceed?
>> 1- fix all the Emacs code that modifies those vars.
> IMHO the only way to do that is to (1) provide a new set of variables
> Elisp code _is_ allowed to change and (2) have `display-buffer' use
> these iff the respective buffer has no corresponding entry in the
> special-display-... options.

Rather than let-binding some Lisp-manipulated "config" var, I was
thinking of passing special parameters to display-buffer (I'd rather
avoid dynamic scoping whenever possible).  Other than that, yes that's
the idea.

> If I do that and a buffer is now in the (same-window . t) group of
> `special-display-regexps', how should
> `Buffer-menu-switch-other-window' proceed with that buffer?
> Bind `special-display-regexps'?  Call `switch-to-buffer-other-window'?
> So far the special-display-... options had an excuse: If this variable
> appears \"not to work\", ...

You mean how could the calling code till display-buffer whether to
"prefer <foo> unless overridden by the user's config" or to "obey <foo>
regardless of the user's config"?
I guess the special parameters passed to display-buffer would have to be
different for the two different cases.


        Stefan

bug#6204: vc-dir always splits the frame

[martin rudalics]

 > Rather than let-binding some Lisp-manipulated "config" var, I was
 > thinking of passing special parameters to display-buffer (I'd rather
 > avoid dynamic scoping whenever possible).

An additional argument is always fine with me.  So this part is solved.

 > You mean how could the calling code till display-buffer whether to
 > "prefer <foo> unless overridden by the user's config" or to "obey <foo>
 > regardless of the user's config"?

Precisely.

 > I guess the special parameters passed to display-buffer would have to be
 > different for the two different cases.

Fine with me too.

If the overriding case and the user option coincide in principle but the
user option has additional values like in the foo-other-frame case with
the user specifying certain frame parameters what shall we do?  Apply
the frame parameters?  Should the additional argument also allow such
frame parameters?  Should, as a rule, the potential argument's values be
identic to the values allowed by the option?

Remains the question how to make customizing monsters like
`special-display-regexps' simpler.  Currently we're heading in the
opposite direction :-(

martin

bug#6204: vc-dir always splits the frame

[Juri Linkov]

>> Rather than let-binding some Lisp-manipulated "config" var, I was
>> thinking of passing special parameters to display-buffer (I'd rather
>> avoid dynamic scoping whenever possible).
>
> An additional argument is always fine with me.

Why not use the existing argument `other-window'
of `pop-to-buffer' and `display-buffer'?

> Remains the question how to make customizing monsters like
> `special-display-regexps' simpler.

Very simple: allow users to override the argument `other-window' of
`pop-to-buffer' and `display-buffer' by the analogous parameter
`other-window' in `special-display-regexps', e.g.

  ("*vc-dir*" (other-window . t))
  ("*vc-diff*" (other-window . nil))
  ("*info*" (other-window . lru))
  ...

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#6204: vc-dir always splits the frame

[Stefan Monnier]

> If the overriding case and the user option coincide in principle but the
> user option has additional values like in the foo-other-frame case with
> the user specifying certain frame parameters what shall we do?  Apply
> the frame parameters?  Should the additional argument also allow such
> frame parameters?  Should, as a rule, the potential argument's values be
> identic to the values allowed by the option?

Yes, I'm picturing the special arg as (conceptually) two alists, and
that we'd combine with the user's own setting via something like

  (append override-params
          (lookup special-display-regexps)
          default-params)


-- Stefan

bug#6204: vc-dir always splits the frame

[Drew Adams]

> Rather than let-binding some Lisp-manipulated "config" var, I was
> thinking of passing special parameters to display-buffer (I'd rather
> avoid dynamic scoping whenever possible).

I'm not following this thread[*], and I agree that using explicit parameters is
usually better than using dynamic scoping. However, I do have a parenthetic
comment. ;-)

The downside to adding such parameters in a case where you modify existing
functions (esp. if used heavily in existing code) is that it can make it harder
for 3rd-party code to take advantage of the new feature and still work with
older versions that do not have the new parameters.

E.g. 

(let ((new-var ...))
 ... (foo) ... (foo) ... (foo) ...)

versus

...
(if xxx (foo) (foo new-param))
...
(if xxx (foo) (foo new-param))
...
(if xxx (foo) (foo new-param))
...

In the former case, all that's needed is to add a `let' binding.  And if there
is already a `let', then _nothing_ changes in the code except adding one more
binding.  It is nearly always the case that the variables to be added are be
specific to the function (`foo'), without conflict.

IOW, dynamic scoping is foot-loose and fancy-free, error prone, and can even
sometimes be dangerous.  But it does have its advantages.


---
* Why oh why do you insist on carrying on discussions of such general import as
changing the signature of `display-buffer' in a bug thread instead of in
emacs-devel?  It happens over and over again now.  Fundamental design-change
discussion takes place buried in a bug thread with a Subject line that is
unrelated.  Not good.  At the very least, once you've hashed out the choices for
the bug fix, send a proposal for any design changes to emacs-devel for general
discussion.

bug#6204: vc-dir always splits the frame

[martin rudalics]

 > Why not use the existing argument `other-window'
 > of `pop-to-buffer' and `display-buffer'?

Let's use it.  Shall we keep the semantics of t as "any window but the
selected one"?  And, shall we rename the argument?

 >> Remains the question how to make customizing monsters like
 >> `special-display-regexps' simpler.
 >
 > Very simple: allow users to override the argument `other-window' of
 > `pop-to-buffer' and `display-buffer' by the analogous parameter
 > `other-window' in `special-display-regexps', e.g.
 >
 >   ("*vc-dir*" (other-window . t))
 >   ("*vc-diff*" (other-window . nil))
 >   ("*info*" (other-window . lru))
 >   ...

We already have

"As a special case, if FRAME-PARAMETERS contains (same-window . t) ..."

so should we now say

"As another special case, if FRAME-PARAMETERS contains
(other-window . t) ..."

Also I've tried to rewrite the customization interface of
`special-display-regexps' without great success - it's all
too clumsy when the alternatives are nil, t, a list ...

That is, we need (1) a user-friendly doc-string for this and
(2) a user-friendly customization interface.

martin

bug#6204: vc-dir always splits the frame

[martin rudalics]

 > Yes, I'm picturing the special arg as (conceptually) two alists, and
 > that we'd combine with the user's own setting via something like
 >
 >   (append override-params
 >           (lookup special-display-regexps)
 >           default-params)

Good.  Now how do `pop-up-windows', `pop-up-frames', and
`display-buffer-reuse-frames' fit into this?  I suppose these are the
values for all buffers not mentioned by `special-display-regexps'.  What
if `pop-up-windows' is nil and "default-params" indicates that the
application wants to pop up a window (but does not insist).  Probably
`pop-up-windows' should prevail in this case.

But maybe we could do away with `pop-up-windows' and friends by adding a
default match-any-name expression to `special-display-regexps'?  This
would simplify doc-strings considerably.

martin

bug#6204: vc-dir always splits the frame

[martin rudalics]

 > The downside to adding such parameters in a case where you modify existing
 > functions (esp. if used heavily in existing code) is that it can make it harder
 > for 3rd-party code to take advantage of the new feature and still work with
 > older versions that do not have the new parameters.

I suppose that re-using the `other-window' argument of `display-buffer'
as Juri proposed will handle the problem you describe.

martin

bug#6204: vc-dir always splits the frame

[Stefan Monnier]

> "As a special case, if FRAME-PARAMETERS contains (same-window . t) ..."
> so should we now say
> "As another special case, if FRAME-PARAMETERS contains
> (other-window . t) ..."

We also have (same-frame . t), and we came to the conclusion at some
other point that we also want to have something like `nearby'
(i.e. other-window but close) or `near-minibuffer' (tho maybe `nearby'
is sufficient if near-minibuffer is only needed when the minibuffer is
the selected windows).

I feel like maybe these shouldn't be all separate parameters, but
instead we may want to have a single `where' parameter whose value could
then say `same-window', `other-window'.  OTOH we probably to be able to
specify some of the independently (I'm think mostly of `same-frame').

So maybe it should be split into `which-frame' which could be `same' or
`other' or nil, and then `where' which could be `same-window', or
`other-window', or `nearby', or nil.

Then we can even imagine in a distant future that the `other-frame' case
could pay attention to the `where' parameter to decide which other frame
to use and (if creating a new frame) where to place that frame.


        Stefan

bug#6204: vc-dir always splits the frame

[Stefan Monnier]

>> Yes, I'm picturing the special arg as (conceptually) two alists, and
>> that we'd combine with the user's own setting via something like
>> (append override-params
>> (lookup special-display-regexps)
>> default-params)

> Good.  Now how do `pop-up-windows', `pop-up-frames', and
> `display-buffer-reuse-frames' fit into this?

I'd force display-buffer-reuse-frames to t and forget about it ;-)

> I suppose these are the values for all buffers not mentioned by
> `special-display-regexps'.

Pretty much, yes.

> What if `pop-up-windows' is nil and "default-params" indicates that
> the application wants to pop up a window (but does not insist).
> Probably `pop-up-windows' should prevail in this case.

No, the application's choice should prevail because it's more specific.


        Stefan

bug#6204: vc-dir always splits the frame

[Drew Adams]

>  > The downside to adding such parameters in a case where you 
>  > modify existing functions (esp. if used heavily in
>  > existing code) is that it can make it harder
>  > for 3rd-party code to take advantage of the new feature 
>  > and still work with older versions that do not have the
>  > new parameters.
> 
> I suppose that re-using the `other-window' argument of 
> `display-buffer' as Juri proposed will handle the problem
> you describe.

Dunno. As I say, I haven't really been following this.

As a user and someone who has code that must work with multiple versions, I
would like existing calls to `display-buffer' (and to functions that call it) to
do the same thing across versions.

Any additional behavior that is specific to Emacs 24+ I would like to be able to
choose/determine/set in some other way than via the traditional `display-buffer'
signature.

A global variable is useful for that. The default value of the variable would be
such as to obtain the pre-24 behavior (IOW, that would be the default behavior).

If you instead add optional parameters at the end of the list, that's OK too -
same effect, as long as the default behavior (the behavior for the traditional
signature) is the same as (or very close to) the pre-24 behavior.

That way, someone who makes an ordinary, pre-24-style call to the function gets
the traditional behavior. It is only by making a non-pre-24 call or setting a
new variable to a non-default value that you get the new feature (whatever it
might be).

To me, that is the ideal way to handle this kind of thing. You might have some
specific needs and reasons that conflict with that ideal - dunno. For such a
case *especially*, I would encourage you to take the discussion to the wider dev
forum, emacs-devel. That's what it's for.

HTH.

bug#6204: vc-dir always splits the frame

[martin rudalics]

 >> "As a special case, if FRAME-PARAMETERS contains (same-window . t) ..."
 >> so should we now say
 >> "As another special case, if FRAME-PARAMETERS contains
 >> (other-window . t) ..."
 >
 > We also have (same-frame . t), and we came to the conclusion at some
 > other point that we also want to have something like `nearby'
 > (i.e. other-window but close) or `near-minibuffer' (tho maybe `nearby'
 > is sufficient if near-minibuffer is only needed when the minibuffer is
 > the selected windows).
 > I feel like maybe these shouldn't be all separate parameters, but
 > instead we may want to have a single `where' parameter whose value could
 > then say `same-window', `other-window'.  OTOH we probably to be able to
 > specify some of the independently (I'm think mostly of `same-frame').
 >
 > So maybe it should be split into `which-frame' which could be `same' or
 > `other' or nil, and then `where' which could be `same-window', or
 > `other-window', or `nearby', or nil.

What I don't understand yet is whether or how we want other-window state
that a window shall be split to get the other window or that another
window shall be reused.

Or shall window splitting and creation of new frames still be guided
entirely by `pop-up-windows' and `pop-up-frames'?

martin

bug#6204: vc-dir always splits the frame

[martin rudalics]

 > I'd force display-buffer-reuse-frames to t and forget about it ;-)

So make it obsolete?

 >> I suppose these are the values for all buffers not mentioned by
 >> `special-display-regexps'.
 >
 > Pretty much, yes.
 >
 >> What if `pop-up-windows' is nil and "default-params" indicates that
 >> the application wants to pop up a window (but does not insist).
 >> Probably `pop-up-windows' should prevail in this case.
 >
 > No, the application's choice should prevail because it's more specific.

I thought the idea was that an application can override a user's
customizations iff it explicitly states that.

So should `pop-up-windows' be considered a "weaker" option than
`special-display-regexps' wrt the argument of `display-buffer'?

martin

bug#6204: vc-dir always splits the frame

[Stefan Monnier]

> What I don't understand yet is whether or how we want other-window state
> that a window shall be split to get the other window or that another
> window shall be reused.

We could distinguish `new-window' from `other-window' (and maybe even
`old-window'?).


        Stefan

bug#6204: vc-dir always splits the frame

[Stefan Monnier]

>> No, the application's choice should prevail because it's more specific.
> I thought the idea was that an application can override a user's
> customizations iff it explicitly states that.

Yes and the users can still do that with special-display-regexps.
But pop-up-frames and pop-up-windows are really very vague global
preferences, whereas an application going through to trouble of
specifying default-params has decided that it usually deserves
special treatment.

> So should `pop-up-windows' be considered a "weaker" option than
> `special-display-regexps' wrt the argument of `display-buffer'?

Very much so, yes, since it's only a boolean value and applies to all
display-buffer calls, it's very non-discerning and carries very little
information about the user's preferences.

Some of the intention behind the `default-params' would be to get rid of
calls to switch-to-buffer (replaced by calls to pop-to-buffer with
a same-window default-param).  Such cases already disregard
pop-up-windows and pop-up-frames, so ignoring them w.r.t default-params
would be consistent with such a case.


        Stefan

bug#6204: vc-dir always splits the frame

[martin rudalics]

 >> I thought the idea was that an application can override a user's
 >> customizations iff it explicitly states that.
 >
 > Yes and the users can still do that with special-display-regexps.
 > But pop-up-frames and pop-up-windows are really very vague global
 > preferences, whereas an application going through to trouble of
 > specifying default-params has decided that it usually deserves
 > special treatment.

So we apparently want to support options like `pop-up-windows' and
`pop-up-frames' forever.  The proposed behavior from strongest to
weakest is therefore

(1) An overriding argument set by the application.

(2) The user setting for `special-display-regexps' (including regexps
     matching _any_ buffer).

(3) A non-overriding argument set by the application.

(4) Vague global preferences like `pop-up-windows'.

Shall applications continue to bind `pop-up-windows' and `pop-up-frames'
as they do now?  I suppose where they do now they should use (1) or (3)
instead.

 > Some of the intention behind the `default-params' would be to get rid of
 > calls to switch-to-buffer (replaced by calls to pop-to-buffer with
 > a same-window default-param).  Such cases already disregard
 > pop-up-windows and pop-up-frames, so ignoring them w.r.t default-params
 > would be consistent with such a case.

You mean all cases where the buffer argument of `switch-to-buffer' names
an existing buffer (probably all of them do, but I didn't check).

martin

bug#6204: vc-dir always splits the frame

[Stefan Monnier]

> So we apparently want to support options like `pop-up-windows' and
> `pop-up-frames' forever.

For the foreseeable future, at least, yes.

> Shall applications continue to bind `pop-up-windows' and `pop-up-frames'
> as they do now?  I suppose where they do now they should use (1) or (3)
> instead.

Exactly, they should use (3) or (1) depending on whether it is based on
some impression that it would be a better default for this particular
case, or whether it's in response to a specific user request
(e.g. calling find-file-other-window rather than find-file).

BTW, I'd be happy to get rid of all the foobar-other-window and
foobar-other-frame and instead provide new prefix commands that affect
the behavior of the next command, so instead of C-x 4 f, you'd do
something like C-x 4 and then C-x C-f.  We would probably then add some
special hack to make C-x 4 f still work as before.

>> Some of the intention behind the `default-params' would be to get rid of
>> calls to switch-to-buffer (replaced by calls to pop-to-buffer with
>> a same-window default-param).  Such cases already disregard
>> pop-up-windows and pop-up-frames, so ignoring them w.r.t default-params
>> would be consistent with such a case.
> You mean all cases where the buffer argument of `switch-to-buffer' names
> an existing buffer (probably all of them do, but I didn't check).

I mean all the calls to switch-to-buffer in Elisp code where the author
obviously didn't take into account the fact that there can be
minibuffer-only frames, or that the selected window can be dedicated,
etc...
IOW put switch-to-buffer in byte-compile-interactive-only-functions
which we currently can't do because we don't have a good replacement
for it yet.


        Stefan

bug#6204: vc-dir always splits the frame

[martin rudalics]

 >>> Some of the intention behind the `default-params' would be to get rid of
 >>> calls to switch-to-buffer (replaced by calls to pop-to-buffer with
 >>> a same-window default-param).  Such cases already disregard
 >>> pop-up-windows and pop-up-frames, so ignoring them w.r.t default-params
 >>> would be consistent with such a case.
 >> You mean all cases where the buffer argument of `switch-to-buffer' names
 >> an existing buffer (probably all of them do, but I didn't check).
 >
 > I mean all the calls to switch-to-buffer in Elisp code where the author
 > obviously didn't take into account the fact that there can be
 > minibuffer-only frames, or that the selected window can be dedicated,

`switch-to-buffer' is allowed to reuse a weakly dedicated window while
`display-buffer' isn't.  This gets complicated :-(

martin

bug#6204: vc-dir always splits the frame

[Stefan Monnier]

> `switch-to-buffer' is allowed to reuse a weakly dedicated window while
> `display-buffer' isn't.

Indeed, and that's on purpose.  It's basically that switch-to-buffer has
a strong `same-window' parameter.  I don't think display-buffer and
special-display-regexps have any way to specify such a request, so we'll
need to add it.

> This gets complicated :-(

It needs to be cleaned up, yes.


        Stefan

bug#6204: vc-dir always splits the frame

[martin rudalics]

 >> `switch-to-buffer' is allowed to reuse a weakly dedicated window while
 >> `display-buffer' isn't.
 >
 > Indeed, and that's on purpose.  It's basically that switch-to-buffer has
 > a strong `same-window' parameter.  I don't think display-buffer and
 > special-display-regexps have any way to specify such a request, so we'll
 > need to add it.

Where "add it" means to include it as argument, I presume.  Doesn't this
mean we'd have to find a way to specify this in `special-display-regexps'
too?

martin

bug#6204: vc-dir always splits the frame

[Stefan Monnier]

>>> `switch-to-buffer' is allowed to reuse a weakly dedicated window while
>>> `display-buffer' isn't.
>> Indeed, and that's on purpose.  It's basically that switch-to-buffer has
>> a strong `same-window' parameter.  I don't think display-buffer and
>> special-display-regexps have any way to specify such a request, so we'll
>> need to add it.
> Where "add it" means to include it as argument, I presume.  Doesn't this
> mean we'd have to find a way to specify this in `special-display-regexps'
> too?

Yes.


        Stefan