* bug#6204: vc-dir always splits the frame
@ 2010-05-17 5:06 Glenn Morris
2010-05-17 7:27 ` Dan Nicolaescu
0 siblings, 1 reply; 50+ messages in thread
From: Glenn Morris @ 2010-05-17 5:06 UTC (permalink / raw)
To: 6204
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-17 5:06 bug#6204: vc-dir always splits the frame Glenn Morris
@ 2010-05-17 7:27 ` Dan Nicolaescu
2010-05-19 3:01 ` Glenn Morris
0 siblings, 1 reply; 50+ messages in thread
From: Dan Nicolaescu @ 2010-05-17 7:27 UTC (permalink / raw)
To: Glenn Morris; +Cc: 6204
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-17 7:27 ` Dan Nicolaescu
@ 2010-05-19 3:01 ` Glenn Morris
2010-05-19 21:31 ` Juri Linkov
0 siblings, 1 reply; 50+ messages in thread
From: Glenn Morris @ 2010-05-19 3:01 UTC (permalink / raw)
To: 6204-done
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-19 3:01 ` Glenn Morris
@ 2010-05-19 21:31 ` Juri Linkov
2010-05-20 9:45 ` martin rudalics
2010-05-20 18:33 ` Glenn Morris
0 siblings, 2 replies; 50+ messages in thread
From: Juri Linkov @ 2010-05-19 21:31 UTC (permalink / raw)
To: 6204
> 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/
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-19 21:31 ` Juri Linkov
@ 2010-05-20 9:45 ` martin rudalics
2010-05-20 17:14 ` Stefan Monnier
2010-05-22 23:50 ` Juri Linkov
2010-05-20 18:33 ` Glenn Morris
1 sibling, 2 replies; 50+ messages in thread
From: martin rudalics @ 2010-05-20 9:45 UTC (permalink / raw)
To: Juri Linkov; +Cc: 6204
> 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-20 9:45 ` martin rudalics
@ 2010-05-20 17:14 ` Stefan Monnier
2010-05-20 17:37 ` martin rudalics
2010-05-22 23:50 ` Juri Linkov
1 sibling, 1 reply; 50+ messages in thread
From: Stefan Monnier @ 2010-05-20 17:14 UTC (permalink / raw)
To: martin rudalics; +Cc: 6204
>> 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
^ permalink raw reply [flat|nested] 50+ messages in thread* bug#6204: vc-dir always splits the frame
2010-05-20 17:14 ` Stefan Monnier
@ 2010-05-20 17:37 ` martin rudalics
2010-05-21 20:15 ` Stefan Monnier
2010-05-21 20:51 ` Juri Linkov
0 siblings, 2 replies; 50+ messages in thread
From: martin rudalics @ 2010-05-20 17:37 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 6204
>>> 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-20 17:37 ` martin rudalics
@ 2010-05-21 20:15 ` Stefan Monnier
2010-05-22 8:50 ` martin rudalics
2010-05-21 20:51 ` Juri Linkov
1 sibling, 1 reply; 50+ messages in thread
From: Stefan Monnier @ 2010-05-21 20:15 UTC (permalink / raw)
To: martin rudalics; +Cc: 6204
>> 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
^ permalink raw reply [flat|nested] 50+ messages in thread* bug#6204: vc-dir always splits the frame
2010-05-21 20:15 ` Stefan Monnier
@ 2010-05-22 8:50 ` martin rudalics
2010-05-22 23:51 ` Juri Linkov
2010-05-23 0:52 ` Stefan Monnier
0 siblings, 2 replies; 50+ messages in thread
From: martin rudalics @ 2010-05-22 8:50 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 6204
> 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-22 8:50 ` martin rudalics
@ 2010-05-22 23:51 ` Juri Linkov
2010-05-23 0:55 ` Stefan Monnier
2010-05-23 12:14 ` martin rudalics
2010-05-23 0:52 ` Stefan Monnier
1 sibling, 2 replies; 50+ messages in thread
From: Juri Linkov @ 2010-05-22 23:51 UTC (permalink / raw)
To: martin rudalics; +Cc: 6204
>> 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/
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-22 23:51 ` Juri Linkov
@ 2010-05-23 0:55 ` Stefan Monnier
2010-05-23 0:59 ` Juri Linkov
2010-05-23 12:15 ` martin rudalics
2010-05-23 12:14 ` martin rudalics
1 sibling, 2 replies; 50+ messages in thread
From: Stefan Monnier @ 2010-05-23 0:55 UTC (permalink / raw)
To: Juri Linkov; +Cc: 6204
> 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
^ permalink raw reply [flat|nested] 50+ messages in thread* bug#6204: vc-dir always splits the frame
2010-05-23 0:55 ` Stefan Monnier
@ 2010-05-23 0:59 ` Juri Linkov
2010-05-23 12:15 ` martin rudalics
2010-05-23 12:15 ` martin rudalics
1 sibling, 1 reply; 50+ messages in thread
From: Juri Linkov @ 2010-05-23 0:59 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 6204
>> 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/
^ permalink raw reply [flat|nested] 50+ messages in thread* bug#6204: vc-dir always splits the frame
2010-05-23 0:59 ` Juri Linkov
@ 2010-05-23 12:15 ` martin rudalics
2010-05-23 13:32 ` Stefan Monnier
0 siblings, 1 reply; 50+ messages in thread
From: martin rudalics @ 2010-05-23 12:15 UTC (permalink / raw)
To: Juri Linkov; +Cc: 6204
> 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
^ permalink raw reply [flat|nested] 50+ messages in thread* bug#6204: vc-dir always splits the frame
2010-05-23 12:15 ` martin rudalics
@ 2010-05-23 13:32 ` Stefan Monnier
2010-05-23 19:04 ` martin rudalics
0 siblings, 1 reply; 50+ messages in thread
From: Stefan Monnier @ 2010-05-23 13:32 UTC (permalink / raw)
To: martin rudalics; +Cc: 6204
> The problem then is how to get rid of the same-window-... options.
What's difficult about it?
Stefan
^ permalink raw reply [flat|nested] 50+ messages in thread* bug#6204: vc-dir always splits the frame
2010-05-23 13:32 ` Stefan Monnier
@ 2010-05-23 19:04 ` martin rudalics
2010-05-24 14:07 ` Stefan Monnier
0 siblings, 1 reply; 50+ messages in thread
From: martin rudalics @ 2010-05-23 19:04 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 6204
>> The problem then is how to get rid of the same-window-... options.
>
> What's difficult about it?
How would you proceed?
martin
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-23 19:04 ` martin rudalics
@ 2010-05-24 14:07 ` Stefan Monnier
2010-05-25 15:36 ` martin rudalics
0 siblings, 1 reply; 50+ messages in thread
From: Stefan Monnier @ 2010-05-24 14:07 UTC (permalink / raw)
To: martin rudalics; +Cc: 6204
>>> 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
^ permalink raw reply [flat|nested] 50+ messages in thread* bug#6204: vc-dir always splits the frame
2010-05-24 14:07 ` Stefan Monnier
@ 2010-05-25 15:36 ` martin rudalics
2010-05-25 17:00 ` Stefan Monnier
0 siblings, 1 reply; 50+ messages in thread
From: martin rudalics @ 2010-05-25 15:36 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 6204
>> 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-25 15:36 ` martin rudalics
@ 2010-05-25 17:00 ` Stefan Monnier
2010-05-25 17:32 ` martin rudalics
2010-05-25 18:33 ` Drew Adams
0 siblings, 2 replies; 50+ messages in thread
From: Stefan Monnier @ 2010-05-25 17:00 UTC (permalink / raw)
To: martin rudalics; +Cc: 6204
>>> 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
^ permalink raw reply [flat|nested] 50+ messages in thread* bug#6204: vc-dir always splits the frame
2010-05-25 17:00 ` Stefan Monnier
@ 2010-05-25 17:32 ` martin rudalics
2010-05-25 18:01 ` Juri Linkov
2010-05-25 18:13 ` Stefan Monnier
2010-05-25 18:33 ` Drew Adams
1 sibling, 2 replies; 50+ messages in thread
From: martin rudalics @ 2010-05-25 17:32 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 6204
> 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-25 17:32 ` martin rudalics
@ 2010-05-25 18:01 ` Juri Linkov
2010-05-26 8:29 ` martin rudalics
2010-05-25 18:13 ` Stefan Monnier
1 sibling, 1 reply; 50+ messages in thread
From: Juri Linkov @ 2010-05-25 18:01 UTC (permalink / raw)
To: martin rudalics; +Cc: 6204
>> 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/
^ permalink raw reply [flat|nested] 50+ messages in thread* bug#6204: vc-dir always splits the frame
2010-05-25 18:01 ` Juri Linkov
@ 2010-05-26 8:29 ` martin rudalics
2010-05-26 13:54 ` Stefan Monnier
0 siblings, 1 reply; 50+ messages in thread
From: martin rudalics @ 2010-05-26 8:29 UTC (permalink / raw)
To: Juri Linkov; +Cc: 6204
> 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
^ permalink raw reply [flat|nested] 50+ messages in thread* bug#6204: vc-dir always splits the frame
2010-05-26 8:29 ` martin rudalics
@ 2010-05-26 13:54 ` Stefan Monnier
2010-05-26 14:49 ` martin rudalics
0 siblings, 1 reply; 50+ messages in thread
From: Stefan Monnier @ 2010-05-26 13:54 UTC (permalink / raw)
To: martin rudalics; +Cc: 6204
> "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
^ permalink raw reply [flat|nested] 50+ messages in thread* bug#6204: vc-dir always splits the frame
2010-05-26 13:54 ` Stefan Monnier
@ 2010-05-26 14:49 ` martin rudalics
2010-05-27 3:58 ` Stefan Monnier
0 siblings, 1 reply; 50+ messages in thread
From: martin rudalics @ 2010-05-26 14:49 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 6204
>> "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
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-25 17:32 ` martin rudalics
2010-05-25 18:01 ` Juri Linkov
@ 2010-05-25 18:13 ` Stefan Monnier
2010-05-26 8:30 ` martin rudalics
1 sibling, 1 reply; 50+ messages in thread
From: Stefan Monnier @ 2010-05-25 18:13 UTC (permalink / raw)
To: martin rudalics; +Cc: 6204
> 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
^ permalink raw reply [flat|nested] 50+ messages in thread* bug#6204: vc-dir always splits the frame
2010-05-25 18:13 ` Stefan Monnier
@ 2010-05-26 8:30 ` martin rudalics
2010-05-26 13:56 ` Stefan Monnier
0 siblings, 1 reply; 50+ messages in thread
From: martin rudalics @ 2010-05-26 8:30 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 6204
> 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-26 8:30 ` martin rudalics
@ 2010-05-26 13:56 ` Stefan Monnier
2010-05-26 14:51 ` martin rudalics
0 siblings, 1 reply; 50+ messages in thread
From: Stefan Monnier @ 2010-05-26 13:56 UTC (permalink / raw)
To: martin rudalics; +Cc: 6204
>> 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
^ permalink raw reply [flat|nested] 50+ messages in thread* bug#6204: vc-dir always splits the frame
2010-05-26 13:56 ` Stefan Monnier
@ 2010-05-26 14:51 ` martin rudalics
2010-05-27 4:04 ` Stefan Monnier
0 siblings, 1 reply; 50+ messages in thread
From: martin rudalics @ 2010-05-26 14:51 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 6204
> 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-26 14:51 ` martin rudalics
@ 2010-05-27 4:04 ` Stefan Monnier
2010-05-27 9:09 ` martin rudalics
0 siblings, 1 reply; 50+ messages in thread
From: Stefan Monnier @ 2010-05-27 4:04 UTC (permalink / raw)
To: martin rudalics; +Cc: 6204
>> 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
^ permalink raw reply [flat|nested] 50+ messages in thread* bug#6204: vc-dir always splits the frame
2010-05-27 4:04 ` Stefan Monnier
@ 2010-05-27 9:09 ` martin rudalics
2010-05-27 16:13 ` Stefan Monnier
0 siblings, 1 reply; 50+ messages in thread
From: martin rudalics @ 2010-05-27 9:09 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 6204
>> 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
^ permalink raw reply [flat|nested] 50+ messages in thread* bug#6204: vc-dir always splits the frame
2010-05-27 9:09 ` martin rudalics
@ 2010-05-27 16:13 ` Stefan Monnier
2010-05-27 17:26 ` martin rudalics
0 siblings, 1 reply; 50+ messages in thread
From: Stefan Monnier @ 2010-05-27 16:13 UTC (permalink / raw)
To: martin rudalics; +Cc: 6204
> 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
^ permalink raw reply [flat|nested] 50+ messages in thread* bug#6204: vc-dir always splits the frame
2010-05-27 16:13 ` Stefan Monnier
@ 2010-05-27 17:26 ` martin rudalics
2010-05-27 18:40 ` Stefan Monnier
0 siblings, 1 reply; 50+ messages in thread
From: martin rudalics @ 2010-05-27 17:26 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 6204
>>> 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-27 17:26 ` martin rudalics
@ 2010-05-27 18:40 ` Stefan Monnier
2010-05-28 9:19 ` martin rudalics
0 siblings, 1 reply; 50+ messages in thread
From: Stefan Monnier @ 2010-05-27 18:40 UTC (permalink / raw)
To: martin rudalics; +Cc: 6204
> `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
^ permalink raw reply [flat|nested] 50+ messages in thread* bug#6204: vc-dir always splits the frame
2010-05-27 18:40 ` Stefan Monnier
@ 2010-05-28 9:19 ` martin rudalics
2010-05-28 15:34 ` Stefan Monnier
0 siblings, 1 reply; 50+ messages in thread
From: martin rudalics @ 2010-05-28 9:19 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 6204
>> `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
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-28 9:19 ` martin rudalics
@ 2010-05-28 15:34 ` Stefan Monnier
0 siblings, 0 replies; 50+ messages in thread
From: Stefan Monnier @ 2010-05-28 15:34 UTC (permalink / raw)
To: martin rudalics; +Cc: 6204
>>> `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
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-25 17:00 ` Stefan Monnier
2010-05-25 17:32 ` martin rudalics
@ 2010-05-25 18:33 ` Drew Adams
2010-05-26 8:30 ` martin rudalics
1 sibling, 1 reply; 50+ messages in thread
From: Drew Adams @ 2010-05-25 18:33 UTC (permalink / raw)
To: 'Stefan Monnier', 'martin rudalics'; +Cc: 6204
> 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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-25 18:33 ` Drew Adams
@ 2010-05-26 8:30 ` martin rudalics
2010-05-26 14:26 ` Drew Adams
0 siblings, 1 reply; 50+ messages in thread
From: martin rudalics @ 2010-05-26 8:30 UTC (permalink / raw)
To: Drew Adams; +Cc: 6204
> 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-26 8:30 ` martin rudalics
@ 2010-05-26 14:26 ` Drew Adams
0 siblings, 0 replies; 50+ messages in thread
From: Drew Adams @ 2010-05-26 14:26 UTC (permalink / raw)
To: 'martin rudalics'; +Cc: 6204
> > 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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-23 0:55 ` Stefan Monnier
2010-05-23 0:59 ` Juri Linkov
@ 2010-05-23 12:15 ` martin rudalics
1 sibling, 0 replies; 50+ messages in thread
From: martin rudalics @ 2010-05-23 12:15 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 6204
>> 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-22 23:51 ` Juri Linkov
2010-05-23 0:55 ` Stefan Monnier
@ 2010-05-23 12:14 ` martin rudalics
1 sibling, 0 replies; 50+ messages in thread
From: martin rudalics @ 2010-05-23 12:14 UTC (permalink / raw)
To: Juri Linkov; +Cc: 6204
>> 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-22 8:50 ` martin rudalics
2010-05-22 23:51 ` Juri Linkov
@ 2010-05-23 0:52 ` Stefan Monnier
2010-05-23 12:14 ` martin rudalics
1 sibling, 1 reply; 50+ messages in thread
From: Stefan Monnier @ 2010-05-23 0:52 UTC (permalink / raw)
To: martin rudalics; +Cc: 6204
>> 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
^ permalink raw reply [flat|nested] 50+ messages in thread* bug#6204: vc-dir always splits the frame
2010-05-23 0:52 ` Stefan Monnier
@ 2010-05-23 12:14 ` martin rudalics
2010-05-23 13:31 ` Stefan Monnier
0 siblings, 1 reply; 50+ messages in thread
From: martin rudalics @ 2010-05-23 12:14 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 6204
>>> 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-23 12:14 ` martin rudalics
@ 2010-05-23 13:31 ` Stefan Monnier
0 siblings, 0 replies; 50+ messages in thread
From: Stefan Monnier @ 2010-05-23 13:31 UTC (permalink / raw)
To: martin rudalics; +Cc: 6204
>>>> 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-20 17:37 ` martin rudalics
2010-05-21 20:15 ` Stefan Monnier
@ 2010-05-21 20:51 ` Juri Linkov
2010-05-22 8:49 ` martin rudalics
1 sibling, 1 reply; 50+ messages in thread
From: Juri Linkov @ 2010-05-21 20:51 UTC (permalink / raw)
To: martin rudalics; +Cc: 6204, 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 replaced it with `pop-to-buffer' ;-)
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-20 9:45 ` martin rudalics
2010-05-20 17:14 ` Stefan Monnier
@ 2010-05-22 23:50 ` Juri Linkov
2010-05-23 12:13 ` martin rudalics
1 sibling, 1 reply; 50+ messages in thread
From: Juri Linkov @ 2010-05-22 23:50 UTC (permalink / raw)
To: martin rudalics; +Cc: 6204
> 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/
^ permalink raw reply [flat|nested] 50+ messages in thread* bug#6204: vc-dir always splits the frame
2010-05-22 23:50 ` Juri Linkov
@ 2010-05-23 12:13 ` martin rudalics
0 siblings, 0 replies; 50+ messages in thread
From: martin rudalics @ 2010-05-23 12:13 UTC (permalink / raw)
To: Juri Linkov; +Cc: 6204
> 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
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-19 21:31 ` Juri Linkov
2010-05-20 9:45 ` martin rudalics
@ 2010-05-20 18:33 ` Glenn Morris
2010-05-21 0:16 ` Juri Linkov
1 sibling, 1 reply; 50+ messages in thread
From: Glenn Morris @ 2010-05-20 18:33 UTC (permalink / raw)
To: Juri Linkov; +Cc: 6204
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.)
^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#6204: vc-dir always splits the frame
2010-05-20 18:33 ` Glenn Morris
@ 2010-05-21 0:16 ` Juri Linkov
0 siblings, 0 replies; 50+ messages in thread
From: Juri Linkov @ 2010-05-21 0:16 UTC (permalink / raw)
To: Glenn Morris; +Cc: 6204
> 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/
^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2010-05-28 15:34 UTC | newest]
Thread overview: 50+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-17 5:06 bug#6204: vc-dir always splits the frame Glenn Morris
2010-05-17 7:27 ` Dan Nicolaescu
2010-05-19 3:01 ` Glenn Morris
2010-05-19 21:31 ` Juri Linkov
2010-05-20 9:45 ` martin rudalics
2010-05-20 17:14 ` Stefan Monnier
2010-05-20 17:37 ` martin rudalics
2010-05-21 20:15 ` Stefan Monnier
2010-05-22 8:50 ` martin rudalics
2010-05-22 23:51 ` Juri Linkov
2010-05-23 0:55 ` Stefan Monnier
2010-05-23 0:59 ` Juri Linkov
2010-05-23 12:15 ` martin rudalics
2010-05-23 13:32 ` Stefan Monnier
2010-05-23 19:04 ` martin rudalics
2010-05-24 14:07 ` Stefan Monnier
2010-05-25 15:36 ` martin rudalics
2010-05-25 17:00 ` Stefan Monnier
2010-05-25 17:32 ` martin rudalics
2010-05-25 18:01 ` Juri Linkov
2010-05-26 8:29 ` martin rudalics
2010-05-26 13:54 ` Stefan Monnier
2010-05-26 14:49 ` martin rudalics
2010-05-27 3:58 ` Stefan Monnier
2010-05-25 18:13 ` Stefan Monnier
2010-05-26 8:30 ` martin rudalics
2010-05-26 13:56 ` Stefan Monnier
2010-05-26 14:51 ` martin rudalics
2010-05-27 4:04 ` Stefan Monnier
2010-05-27 9:09 ` martin rudalics
2010-05-27 16:13 ` Stefan Monnier
2010-05-27 17:26 ` martin rudalics
2010-05-27 18:40 ` Stefan Monnier
2010-05-28 9:19 ` martin rudalics
2010-05-28 15:34 ` Stefan Monnier
2010-05-25 18:33 ` Drew Adams
2010-05-26 8:30 ` martin rudalics
2010-05-26 14:26 ` Drew Adams
2010-05-23 12:15 ` martin rudalics
2010-05-23 12:14 ` martin rudalics
2010-05-23 0:52 ` Stefan Monnier
2010-05-23 12:14 ` martin rudalics
2010-05-23 13:31 ` Stefan Monnier
2010-05-21 20:51 ` Juri Linkov
2010-05-22 8:49 ` martin rudalics
2010-05-22 23:54 ` Juri Linkov
2010-05-22 23:50 ` Juri Linkov
2010-05-23 12:13 ` martin rudalics
2010-05-20 18:33 ` Glenn Morris
2010-05-21 0:16 ` Juri Linkov
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.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).