RE: Jumping to C source from *Help*

["Drew Adams" <drew.adams@oracle.com>]

FWIW, I agree. I use frames instead of windows for nearly everything, by
default. For special buffers I use dedicated frames: (unsplittable . t).

Because (IMO) Emacs (20, at least - I don't know 21) is somewhat biased
toward windows & against frames, I've redefined a few of the built-in
functions slightly to play better with frames. One of those functions was
switch-to-buffer (as mentioned previously).

  - Drew

-----Original Message-----
From: emacs-devel-bounces+drew.adams=oracle.com@gnu.org
[mailto:emacs-devel-bounces+drew.adams=oracle.com@gnu.org]On Behalf Of
Glenn Morris
Sent: Monday, April 19, 2004 5:41 PM
To: rms@gnu.org
Cc: juri@jurta.org; Glenn Morris; emacs-devel@gnu.org;
monnier@iro.umontreal.ca; storm@cua.dk
Subject: Re: Jumping to C source from *Help*

Richard Stallman wrote:

> The question is, is this a bug, or is it just a case of "So don't do
> that, then."

Well, if that was not a rhetorical question, and if I understand
correctly that the issue is "ought one to put a dedicated window in an
unsplittable frame", then IMO it doesn't seem like such a crazy thing
to do.

As I alluded to in a previous mail it already happens in at least one
place in Emacs, namely the calendar if one has (setq calendar-setup
'calendar-only). I tried changing the calendar frame to no longer be
unsplittable and the results were not satisfactory.

>From an abstract point of view it seems like something Emacs ought to
be able to deal with when multiple frames are available. Perhaps the
effort required would outweigh the benefits - I wouldn't know.

Strangely, if in my previous example I use t for the second argument
of set-window-dedicated-p, rather than 'foo (say), then there is no
problem. This approach also works for the calendar frames, so I'll
change them to do that. Weird though.