unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alex Schroeder <alex@gnu.org>
Subject: Re: compilation-goto-locus, pop-up-windows, same-window-regexps
Date: Wed, 26 Mar 2003 23:33:23 +0100	[thread overview]
Message-ID: <87k7elu5ak.fsf@gnu.org> (raw)
In-Reply-To: <m18yBT2-000IeGC@rattlesnake.com> ("Robert J. Chassell"'s message of "Wed, 26 Mar 2003 14:01:24 +0000 (UTC)")

"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.

  reply	other threads:[~2003-03-26 22:33 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-16 10:43 compilation-goto-locus, pop-up-windows, same-window-regexps Alex Schroeder
2003-03-17  4:52 ` Richard Stallman
2003-03-17  9:14   ` Alex Schroeder
2003-03-17 23:24     ` Richard Stallman
2003-03-17 23:41       ` Stefan Monnier
2003-03-18  0:04         ` Alex Schroeder
2003-03-18  0:35           ` Stefan Monnier
2003-03-18  0:01       ` Alex Schroeder
2003-03-19  8:49         ` Richard Stallman
2003-03-21 22:52           ` Alex Schroeder
2003-03-24  2:05             ` Richard Stallman
2003-03-24 20:35               ` Alex Schroeder
2003-03-24 23:02                 ` Robert J. Chassell
2003-03-26  0:39                   ` Alex Schroeder
2003-03-26 14:01                     ` Robert J. Chassell
2003-03-26 22:33                       ` Alex Schroeder [this message]
2003-03-27 10:05                         ` Oliver Scholz
2003-03-24  2:05             ` Richard Stallman
2003-03-24 15:36               ` Stefan Monnier
2003-03-24 20:41               ` Alex Schroeder
2003-03-24 21:06                 ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k7elu5ak.fsf@gnu.org \
    --to=alex@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).