compilation-goto-locus, pop-up-windows, same-window-regexps

compilation-goto-locus, pop-up-windows, same-window-regexps

[Alex Schroeder]

I propose to change the end of compilation-goto-locus from this:

  ;; Show compilation buffer in other window, scrolled to this error.
  (let* ((pop-up-windows t)
	 ;; Use an existing window if it is in a visible frame.
	 (w (or (get-buffer-window (marker-buffer (car next-error)) 'visible)
		;; Pop up a window.
		(display-buffer (marker-buffer (car next-error))))))
    (set-window-point w (car next-error))
    (set-window-start w (car next-error))
    (compilation-set-window-height w)))

to this:

  ;; Show compilation buffer in other window, scrolled to this error.
  (when pop-up-windows
    ;; Use an existing window if it is in a visible frame.
    (let ((w (or (get-buffer-window (marker-buffer (car next-error)) 'visible)
		 ;; Pop up a window.
		 (display-buffer (marker-buffer (car next-error))))))
      (set-window-point w (car next-error))
      (set-window-start w (car next-error))
      (compilation-set-window-height w))))

What I am trying to achieve is this:

I want Emacs to use one window for each task, ie. when I read mail, in
one window, and write code in a second window, I don't Emacs to change
my window configurations.  I don't want Emacs to split my windows, and
I don't want Emacs to delete other windows.

This is why I started using the following settings.  Try it in emacs
-q.

(setq pop-up-windows nil
      same-window-regexps '("."))

Now run a grep command:

(grep "grep -n setq ~/.emacs")

The *grep* buffer should be the only visible window, now.  Hit RET on
one of the matches.  The window continues to show the grep buffer!

I am not very happy with this solution, however.  I think the best
solution would be to eliminate all occurences of binding
pop-up-windows.  We should look at these situations and decide what
the best way to handle them is -- without making new windows.

Alex.

Re: compilation-goto-locus, pop-up-windows, same-window-regexps

[Richard Stallman]

    I am not very happy with this solution, however.  I think the best
    solution would be to eliminate all occurences of binding
    pop-up-windows.  We should look at these situations and decide what
    the best way to handle them is -- without making new windows.

Where else is there a binding of pop-up-windows?

Re: compilation-goto-locus, pop-up-windows, same-window-regexps

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

>     I am not very happy with this solution, however.  I think the best
>     solution would be to eliminate all occurences of binding
>     pop-up-windows.  We should look at these situations and decide what
>     the best way to handle them is -- without making new windows.
>
> Where else is there a binding of pop-up-windows?

I did not look at all of them, I just ran 

grep pop-up-windows *.el */*.el

in the lisp directory...


If you agree with the general argumentation in my previous mail, then
I can go through these places and suggest what to do for each one.

Alex.

vcursor.el:588:  ;; the variables pop-up-windows and pop-up-frames are significant)
startup.el:986:	       (let ((pop-up-windows nil))
simple.el:4274:  (let ((pop-up-windows t))
printing.el:5403:			 pop-up-windows
pcvs.el:482:      (let ((pop-up-windows nil)) (pop-to-buffer cvsbuf)))))
pcvs.el:952:      (let ((pop-up-windows nil)) (pop-to-buffer cvsbuf)))))
pcvs-util.el:105:  (let ((pop-up-windows (or pop-up-windows pop-up-frames))
pcvs-util.el:108:	(and pop-up-windows
help.el:150:		    (pop-up-windows
frame.el:130:	 (let* ((pop-up-frames nil) (pop-up-windows t)
files.el:778:  (let ((pop-up-windows t))
electric.el:146:	 (pop-up-windows t)
ehelp.el:146:           (let ((pop-up-windows t))
ediff-util.el:3320:	(pop-up-windows t)
cus-start.el:237:	     (pop-up-windows windows boolean)
cus-edit.el:904:	      (pop-up-windows t)
cus-edit.el:1230:	(pop-up-windows t)
buff-menu.el:461:	(pop-up-windows t))
bookmark.el:1864:            (pop-up-windows t))
bookmark.el:1901:        (pop-up-windows t)
textmodes/bibtex.el:3421:          (let ((pop-up-windows t))
progmodes/compile.el:1914:      (let ((pop-up-windows t))
progmodes/compile.el:1935:  (let* ((pop-up-windows t)
progmodes/compile.el:1977:	  (let* ((pop-up-windows t)
play/decipher.el:716:        (pop-up-windows t))
net/ange-ftp.el:1473:	(pop-up-windows t))
mh-e/mh-comp.el:611:  (let ((pop-up-windows t))
mail/sendmail.el:1701:  (let ((pop-up-windows t)
mail/rmailsum.el:241:		   pop-up-windows (not pop-up-frames))
mail/reporter.el:342:      (and pop-up-windows (display-buffer reporter-eval-buffer)))
emacs-lisp/elint.el:665:  (let ((pop-up-windows t))
emacs-lisp/byte-opt.el:1456:;;;	  (let ((old-pop-ups pop-up-windows)
emacs-lisp/byte-opt.el:1457:;;;		(pop-up-windows flag))
emacs-lisp/byte-opt.el:1458:;;;	    (cond ((not (eq pop-up-windows old-pop-ups))
emacs-lisp/byte-opt.el:1459:;;;		   (setq old-pop-ups pop-up-windows)
emacs-lisp/byte-opt.el:1466:;;;	varbind pop-up-windows
emacs-lisp/byte-opt.el:1467:;;;	varref pop-up-windows
emacs-lisp/byte-opt.el:1472:;;;	varbind pop-up-windows
emacs-lisp/byte-opt.el:1475:;;; we break the program, because it will appear that pop-up-windows and
calendar/solar.el:894:                   (if pop-up-windows
calendar/calendar.el:1465:  (let* ((pop-up-windows t)
calendar/cal-x.el:124:    (let ((pop-up-windows nil)
gnus/message.el:4408:    (let ((pop-up-windows t)
gnus/message.el:4437:  (let ((pop-up-windows t)
calc/calc.el:1099:		(if (and pop-up-windows
calc/calc-yank.el:452:    (setq calc-one-window (and (one-window-p t) pop-up-windows))
calc/calc-yank.el:474:    (if (and (one-window-p t) pop-up-windows)

Re: compilation-goto-locus, pop-up-windows, same-window-regexps

[Richard Stallman]

    If you agree with the general argumentation in my previous mail, then
    I can go through these places and suggest what to do for each one.

I think that the question of whether to bind pop-up-windows or obey it
is specific for each instance where this happens.  The reason I made
compilation-goto-locus bind it was that I thought that for that
command users would prefer to split the screen, even users who in most
cases do not.  If that is true, binding pop-up-windows there was a
good idea.  Otherwise, it was not.

It would be the same kind of question for each other such place.
The answers might not necessarily be the same.

I think the right solution is to bind pop-up-windows to
(or pop-up-windows compilation-error-pop-up-windows)
where compilation-error-pop-up-windows is a new user option.
That will make everyone happy.  Want to do that?

Perhaps some other similar commands could use a similar solution.

Re: compilation-goto-locus, pop-up-windows, same-window-regexps

[Stefan Monnier]

>     If you agree with the general argumentation in my previous mail, then
>     I can go through these places and suggest what to do for each one.
> 
> I think that the question of whether to bind pop-up-windows or obey it
> is specific for each instance where this happens.  The reason I made
> compilation-goto-locus bind it was that I thought that for that
> command users would prefer to split the screen, even users who in most
> cases do not.  If that is true, binding pop-up-windows there was a
> good idea.  Otherwise, it was not.
> 
> It would be the same kind of question for each other such place.
> The answers might not necessarily be the same.
> 
> I think the right solution is to bind pop-up-windows to
> (or pop-up-windows compilation-error-pop-up-windows)
> where compilation-error-pop-up-windows is a new user option.
> That will make everyone happy.  Want to do that?

I think there's a better solution: use special-display-buffer-names.
You can (for example) specify

  (push '("*Compilation*" (same-window . t)) special-display-buffer-names)

to cause (pop-to-buffer "*Compilation*") to prefer reusing the current window.

I think using a system along those lines is much better than introducing
hundreds of foo-bar-pop-up-windows and foo-bar-pop-up-frames.

Of course special-display-buffer-names is intended for
users and should initially be nil.  So we should create a new var like
special-display-defaults.  Also I think there's currently only ways
to say "stay in the same frame" or "stay in the same window" but no ways
to say "use another window" or "use another frame".


	Stefan

Re: compilation-goto-locus, pop-up-windows, same-window-regexps

[Alex Schroeder]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> I think there's a better solution: use special-display-buffer-names.
> You can (for example) specify

At the moment I don't think that would help me.  I only use one Emacs
frame (and the doc string says "List of buffer names that should have
their own special frames.").  The doc string refers me to
same-window-regexps, and that I have already set to (".") -- but as
described in my first message of this thread, using this setting for
same-window-regexps and pop-up-windows nil still results in some
strange effects.

Alex.

Re: compilation-goto-locus, pop-up-windows, same-window-regexps

[Stefan Monnier]

> > I think there's a better solution: use special-display-buffer-names.
> > You can (for example) specify
> 
> At the moment I don't think that would help me.  I only use one Emacs
> frame (and the doc string says "List of buffer names that should have
> their own special frames.").

The docstring should be improved, obviously.

> The doc string refers me to same-window-regexps,

This predates the (same-window . t) parameter which came together
with the (same-frame . t) parameter.
I actually happen to dislike same-window-(regexps|buffer-names) because:
- It is more difficult to remove an element from a list than to add one.
  So I prefer adding ("*foo*" (same-window . nil)) over removing "*foo*"
  especially since "\\*fo" or even "." might have caused "*foo*" to be
  kept on the same window.
- it is declared as a defcustom but it is updated by packages,
  so not only custom gets all confused but it's difficult for a user
  to change the variable (especially remove entries) since she might
  have to do it in an eval-after-load.
- same-window-* takes precedence over special-display-*, which makes
  the above two points that much more painful.

> and that I have already set to (".") -- but as
> described in my first message of this thread, using this setting for
> same-window-regexps and pop-up-windows nil still results in some
> strange effects.

I think the strange effects are due to places that bind pop-up-windows
rather than rely on the special-display-* (or same-window-*) functionality.


	Stefan

Re: compilation-goto-locus, pop-up-windows, same-window-regexps

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

> I think the right solution is to bind pop-up-windows to (or
> pop-up-windows compilation-error-pop-up-windows) where
> compilation-error-pop-up-windows is a new user option.  That will
> make everyone happy.  Want to do that?

Perhaps.

Why is does the name of the option contain "error"?  After all,
compilation-goto-locus is also used for grep, for example.

Let us first establish if we really need:

1. one such new variable for every sitatuation
2. one such new variable for some of these sitatuations
3. one new variable for all situations

Personally, I only need one new variable, and I'd probably like it for
*all* situations: (and pop-up-windows important-pop-up-windows).  I
would like to add such a new variable to Emacs, and use it wherever
pop-up-windows is bound to t at the moment.

important-pop-up-windows would default to t, setting both
pop-up-windows and important-pop-up-windows to nil would achieve the
behaviour I want.

Let me explain why I am pretty sure that I think I really never want
to split windows:

When I work with Emacs at the moment, I often have 6 or 7 windows open
in one frame, and I only use one frame.

Undoing a split usually involves C-x o C-x 0 -- and even them I am not
always sure that C-x o takes me to the correct window and that C-x 0
does not enlarge some other window instead of restoring the original
window configuration.  So every pop-up interrupts my work flow.

I used to think that C-x r w 1 (store window config in register) was
the way to get back easily to complex window configurations, but it
turned out to not work.  For one, it remembered buffer positions,
which is bad if you have a window showing a buffer that grows (shell,
sql, irc), or if you have a window that may show different buffers at
different times (gnus group, gnus summary, gnus article, or message).

Alex.

Re: compilation-goto-locus, pop-up-windows, same-window-regexps

[Richard Stallman]

    I used to think that C-x r w 1 (store window config in register) was
    the way to get back easily to complex window configurations, but it
    turned out to not work.  For one, it remembered buffer positions,

Perhaps we should add a way of restoring a window configuration
that does not restore the positions.

Re: compilation-goto-locus, pop-up-windows, same-window-regexps

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

>     I used to think that C-x r w 1 (store window config in register) was
>     the way to get back easily to complex window configurations, but it
>     turned out to not work.  For one, it remembered buffer positions,
>
> Perhaps we should add a way of restoring a window configuration
> that does not restore the positions.

I don't think that is enough, because when I want a "Gnus" window,
that window might hold the group buffer, the summary buffer, an
article, or a new message I am writing.

I still think that pop-up-windows should just do what the doc-string
says:  "*Non-nil means display-buffer should make new windows."

Is there anybody that uses a nil value for pop-up-windows and likes
the way it works now (eg. sometimes the window is split after all)?
Perhaps we should investigate why people set pop-up-windows to nil,
and what their experiences are.

If people like it, I suggest we go back to my suggestion:

> Personally, I only need one new variable, and I'd probably like it for
> *all* situations: (and pop-up-windows important-pop-up-windows).  I
> would like to add such a new variable to Emacs, and use it wherever
> pop-up-windows is bound to t at the moment.

> important-pop-up-windows would default to t, setting both
> pop-up-windows and important-pop-up-windows to nil would achieve the
> behaviour I want.

If people don't like it, then we just remove the local bindings of
pop-up-windows.  Of course we'd still think carefully about every
such occasion, but we'd agree that in general pop-up-windows should
do what the doc-string says it does.

Alex.

Re: compilation-goto-locus, pop-up-windows, same-window-regexps

[Richard Stallman]

    >     I used to think that C-x r w 1 (store window config in register) was
    >     the way to get back easily to complex window configurations, but it
    >     turned out to not work.  For one, it remembered buffer positions,
    >
    > Perhaps we should add a way of restoring a window configuration
    > that does not restore the positions.

    I don't think that is enough, because when I want a "Gnus" window,
    that window might hold the group buffer, the summary buffer, an
    article, or a new message I am writing.

I don't see precisely how that relates to the issue; could you spell
out the connection?

Re: compilation-goto-locus, pop-up-windows, same-window-regexps

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

>     >     I used to think that C-x r w 1 (store window config in register) was
>     >     the way to get back easily to complex window configurations, but it
>     >     turned out to not work.  For one, it remembered buffer positions,
>     >
>     > Perhaps we should add a way of restoring a window configuration
>     > that does not restore the positions.
>
>     I don't think that is enough, because when I want a "Gnus" window,
>     that window might hold the group buffer, the summary buffer, an
>     article, or a new message I am writing.
>
> I don't see precisely how that relates to the issue; could you spell
> out the connection?

"store window config in register" stores both the buffer and the
position per window.  The way I work, I care neither about the exact
position *nor* about the exact buffer in the context of Gnus.  The
reason is that I have a window for "reading mail", in it, different
buffers are shown at different times (group, summary, article,
message).  When I start working, I store the window configuration in
a register.  Later, I compiled code (which splits a window) and read
some mail (which splits the window), etc.  And now I want to restore
the window configuration.  In the Gnus window, however, I don't want
to see the buffer that was shown there at the time I stored the
window configuration.  I want to see the buffer that is most
appropriate (the one furthest down in the hierarchy) buffer.  In
fact, It should do something along the lines of my switch-to-gnus
function:

    (defun switch-to-gnus ()
      "Switch to a Gnus related buffer.
    Candidates are buffers starting with
     *mail or *reply or *wide reply
     *Summary
     *Group*
    If no candidate exists, start Gnus."
      (interactive)
      (let (candidate
            priority
            (tests '(("^\\*\\(mail\\|\\(wide \\)?reply\\)" . 1)
                     ("^\\*Article" . 2)
                     ("^\\*Summary" . 3)
                     ("^\\*Group" . 4))))
        (dolist (buf (buffer-list))
          (dolist (test tests)
            (when (and (string-match (car test) (buffer-name buf))
                       (or (not priority) (< (cdr test) priority))
                       (> (buffer-size buf) 0))
              (setq candidate buf
                    priority (cdr test)))))
        (if (buffer-live-p candidate)
            (switch-to-buffer candidate)
          (gnus))))

As you can see, this problem is difficult to solve in a generic way,
because the same problem arises when I work in a multi-file project.
When I want to undo the effect of window splitting due to compilation
and grepping, I really want to get the most recently used buffer for
the project -- not the buffer current at the time a window
configuration was stored in a register.

This is why I feel that Emacs should not touch the window
configuration if the user has indicated via some variable that the
window configuration is very important.

Alex.

Re: compilation-goto-locus, pop-up-windows, same-window-regexps

[Robert J. Chassell]

Alex Schroeder <alex@gnu.org> wrote:

   "store window config in register" stores both the buffer and the
   position per window.  The way I work, I care neither about the exact
   position *nor* about the exact buffer ...

It sounds to me that you are seeking what GNOME/sawfish calls a
`group'.  As far as I know, GNU Emacs does not handle groups.  (I have
never used groups.)

However, they are an interesting idea.  As far as I can see, groups
can be instantiated in two overlapping ways:

  * as a cluster of windows in one frame, such as GNUS *Group*,
    *Summary* and *Article*.

  * as a cluster of frames (each with one or `grouped' windows)
    together and in the same relative position, as in SCWM.

(A third way would be `everything related to a project'.)

I would think that one of the `theme' functions should provide this
(or these) among other features.

   .... When I want to undo the effect of window splitting due to
   compilation and grepping, I really want to get the most recently
   used buffer for the project -- not the buffer current at the time a
   window configuration was stored in a register.

What you want is an additional kind of undo.  A `within the current
type of group' undo:  not an undo that pops the buffer pointer from
the current stack, but one that pops the stack of `significant buffers
for the current context'.

Challenging ideas.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: compilation-goto-locus, pop-up-windows, same-window-regexps

[Alex Schroeder]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> It sounds to me that you are seeking what GNOME/sawfish calls a
> `group'.  As far as I know, GNU Emacs does not handle groups.  (I have
> never used groups.)

> What you want is an additional kind of undo.  A `within the current
> type of group' undo:  not an undo that pops the buffer pointer from
> the current stack, but one that pops the stack of `significant buffers
> for the current context'.

> Challenging ideas.

It depends.  I gave a rather long rationale for my wishes, and I gave
a rather short solution: Let pop-up-windows do what it is supposed to
do -- prevent window splitting -- and we'll see how it goes and
perhaps other things need fixing thereafter.

Certainly groups and other fancy window manipulation might be
interesting, but just as you said -- I never used them.  I never use
such fancy stuff because it is hard to form accurate mental models,
and it is hard to design good user interfaces for these things.

Back when I used an ordinary window manager, I used frames to "group"
stuff.  I had a Gnus frame, an IRC frame, a programming frame, etc.

Now I switched to a very limited window manager -- essentially it
looks like a big terminal emulater.  There is just one (big) frame
visible at all times.  So I started to use Emacs window managing to
lay out the things the way I want them, and I mangled the Gnus window
management configuration such that Gnus presents me with one buffer
only, and does not touch the existing window configuration (there
still is the occasional problem, but that is stuff that can be fixed
as well, and I will report that to the Gnus mailing list).

What I'm trying to say is that we should not let ourselves get
distracted by possible neat solutions to my problem, when a very
simple and limited solution might solve my problem.  Perhaps other
people have other problems, and it might be nice to solve them, too,
but they did not submit bug reports (yet), and so we can postpone that
for later.  All IMHO, of course.

Alex.

Re: compilation-goto-locus, pop-up-windows, same-window-regexps

[Robert J. Chassell]

   ... I gave a rather short solution: Let pop-up-windows do what it
   is supposed to do -- prevent window splitting -- and we'll see how
   it goes and perhaps other things need fixing thereafter.

I am not quite sure I understand your suggestion.  The
`pop-up-windows' variable does not seem to be frame-oriented at all.

   Back when I used an ordinary window manager, I used frames to "group"
   stuff.  I had a Gnus frame, an IRC frame, a programming frame, etc.

Ah ... like running multiple instances of Emacs, each devoted to a
topic.  (As it happens, I am running four different instances right
now.)

Are you suggesting that I should be able to run one instance of Emacs,
but have a frame for my mail related buffers, a frame for my Emacs
Lisp related buffers, a frame for my CVS and compilation related
buffers, and so on?

This would require implementing a new function that might be called
`keep-same-frame'.  My current CVS/compilation `group' consists of
three buffers:  `how-to-emacs', `*cvs*', and `*compilation*'.

So, should I be able to run

    (keep-same-frame "how-to-emacs" "*cvs*")

and create a grouping of those two buffers, and then later run

    (keep-same-frame-addition "*compilation*")

to add to that grouping?

    What I'm trying to say is that we should not let ourselves get
    distracted by possible neat solutions to my problem, when a very
    simple and limited solution might solve my problem. ...

Good point.  But I don't see any simple solution, other than running
different instances of Emacs.  But I am often blind to what Emacs can
already do.  Does anyone know of a simple and limited solution to the
current problem?

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: compilation-goto-locus, pop-up-windows, same-window-regexps

[Alex Schroeder]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Good point.  But I don't see any simple solution, other than running
> different instances of Emacs.  But I am often blind to what Emacs can
> already do.  Does anyone know of a simple and limited solution to the
> current problem?

Not yet -- specially since RMS pointed out another class of problems
for my simple solution:  Long messages.  Sometimes Emacs uses a buffer
to display information about another buffer instead of the echo area
-- eg. "You are using an unsafe coding system to save character
X...  The other window shows this character X" (more or less).  Now if
you only show one of these buffers, the error message makes no sense
without seeing character X in the other buffer, and seeing only
character X in a buffer without the message is also useless.  A
similar, but less serious problem is the idea of a help message when
writing bug reports.  With a "one-window-at-all-times" setup, you will
see either the help text, or the mail buffer, but not both.

I must think a bit more about this, since the simple solution seems to
have some drawbacks.  At first I thought I could solve the problem
with appropriate stacking of buffers -- eg. if you first see a help
message talking about the bug report, and you hit q and then you see
the mail buffer, then it still sort-of makes sense.  But the error
message about the unsafe coding system is a killer -- just stacking
the information is not enough, because in that situation you must
answer a question (choose a safe coding system) without having the
chance to look at the "next" buffer.

Anyway, back to the second part of your message -- what can Emacs
already do in this area?  I tried to collect some ideas floating
around:

Note that I used frames to group windows and buffers belonging to a
group in earlier days.  People like Oliver Scholz have implemented (I
don't know the current status) code that modifies buffer-switching
functions to only allow buffers "in the same group", and these groups
where somehow tied to a frame.  That makes frames dedicated to
particular tasks easier to use, because you won't get lost in your
long list of unrelated buffers when you switch buffers.

Other related stuff Emacs already does:

special-display-buffer-names creates new frames for particular
buffers.

same-window-buffer-names controls whether a certain buffer is shown in
the current window or in some "other" window (possibly creating new
ones).

gnus-window-configuration specifies the configuration of buffers to
use for a variety of typical situations while reading mail and news.
These window configurations replace the current window configuration
of a frame, so having a dedicated Gnus frame works.  Since I wanted a
dedicated Gnus *window*, I attempted to create a
gnus-window-configuration setting that always shows only one buffer at
all times.

"La solution existe!" -- Alex.

Re: compilation-goto-locus, pop-up-windows, same-window-regexps

[Oliver Scholz]

Alex Schroeder <alex@gnu.org> writes:
[...]

> People like Oliver Scholz have implemented (I don't know the current
> status) code that modifies buffer-switching functions to only allow
> buffers "in the same group", and these groups where somehow tied to
> a frame. That makes frames dedicated to particular tasks easier to
> use, because you won't get lost in your long list of unrelated
> buffers when you switch buffers.

Current status: I haven't found a good user interface yet (something
that someone not familiar with Elisp could use and that is at the same
time flexible enough to be useful). This turned out to be the hard
part. It is still on my TODO, though. But not exactly at the top of
it.

    Oliver
-- 
Oliver Scholz               7 Germinal an 211 de la Révolution
Taunusstr. 25               Liberté, Egalité, Fraternité!
60329 Frankfurt a. M.       http://www.jungdemokratenhessen.de
Tel. (069) 97 40 99 42      http://www.jdjl.org

Re: compilation-goto-locus, pop-up-windows, same-window-regexps

[Richard Stallman]

    Is there anybody that uses a nil value for pop-up-windows and likes
    the way it works now (eg. sometimes the window is split after all)?

We cannot tell this by asking the small number of people on this list.
It would be necessary to conduct a poll.

    Perhaps we should investigate why people set pop-up-windows to nil,
    and what their experiences are.

If we find a large number of people on this list who use pop-up-windows,
then their views on this question would provide a significant sample.
But if they are few, we need a larger sample.

    Personally, I only need one new variable, and I'd probably like it for
    *all* situations: (and pop-up-windows important-pop-up-windows).  I
    would like to add such a new variable to Emacs, and use it wherever
    pop-up-windows is bound to t at the moment.

This can't hurt, so perhaps this is the best way.

Re: compilation-goto-locus, pop-up-windows, same-window-regexps

[Stefan Monnier]

>     Personally, I only need one new variable, and I'd probably like it for
>     *all* situations: (and pop-up-windows important-pop-up-windows).  I
>     would like to add such a new variable to Emacs, and use it wherever
>     pop-up-windows is bound to t at the moment.
> This can't hurt, so perhaps this is the best way.

It's going to change a lot of code, so it had better be a good
solution rather than a quick fix.
What's is an "important" pop-up-window ?


	Stefan

Re: compilation-goto-locus, pop-up-windows, same-window-regexps

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

> We cannot tell this by asking the small number of people on this list.
> It would be necessary to conduct a poll.

I agree.  I'd prefer it if we find a solution that does not require a
poll.  :)

>     Personally, I only need one new variable, and I'd probably like it for
>     *all* situations: (and pop-up-windows important-pop-up-windows).  I
>     would like to add such a new variable to Emacs, and use it wherever
>     pop-up-windows is bound to t at the moment.
>
> This can't hurt, so perhaps this is the best way.

Good.

Stefan Monnier <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> It's going to change a lot of code, so it had better be a good
> solution rather than a quick fix.
> What's is an "important" pop-up-window ?

I have no idea.  Personally, I think that pop-up-windows should have
top priority and that elisp authors should never override it.  If we
assume that some people will set both pop-up-windows and
important-pop-up-windows to nil, then these people will start
complaining about sub-optimal user interfaces anyway, and some of
these places will get even more fixes, to be honest.

The pragmatic approach, however, is this:  I suggest that all the
places where somebody else decided to bind pop-up-windows to t are
considered "important" because at least one person considered it
important enough to write extra code.

With this approach, people that have set pop-up-windows to nil and
like the current approach are not disturbed, while people like me are
a bit better off, eventhough further changes will be desirable for
some of these places.

Alex.

Re: compilation-goto-locus, pop-up-windows, same-window-regexps

[Stefan Monnier]

> > We cannot tell this by asking the small number of people on this list.
> > It would be necessary to conduct a poll.
> 
> I agree.  I'd prefer it if we find a solution that does not require a
> poll.  :)
> 
> >     Personally, I only need one new variable, and I'd probably like it for
> >     *all* situations: (and pop-up-windows important-pop-up-windows).  I
> >     would like to add such a new variable to Emacs, and use it wherever
> >     pop-up-windows is bound to t at the moment.
> >
> > This can't hurt, so perhaps this is the best way.
> 
> Good.
> 
> Stefan Monnier <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> 
> > It's going to change a lot of code, so it had better be a good
> > solution rather than a quick fix.
> > What's is an "important" pop-up-window ?
> 
> I have no idea.  Personally, I think that pop-up-windows should have
> top priority and that elisp authors should never override it.  If we
> assume that some people will set both pop-up-windows and
> important-pop-up-windows to nil, then these people will start
> complaining about sub-optimal user interfaces anyway, and some of
> these places will get even more fixes, to be honest.
> 
> The pragmatic approach, however, is this:  I suggest that all the
> places where somebody else decided to bind pop-up-windows to t are
> considered "important" because at least one person considered it
> important enough to write extra code.
> 
> With this approach, people that have set pop-up-windows to nil and
> like the current approach are not disturbed, while people like me are
> a bit better off, eventhough further changes will be desirable for
> some of these places.

But it still only gives a binary option between the current behavior
and the one you want.  If that's really all we want for now, I'd
recommend we change the code that uses pop-up-windows (mostly
display-buffer) so that it obeys an extra variables.
That gives you the same result without touching anybody else's code.


	Stefan