special buffer frames again

special buffer frames again

[Tyler Smith]

Hi,

I'm working out the bumps in setting up my special buffer frames. So
far so good, except: if I c-x c-f to load a file, hit tab, the
completions frame opens up. However, after selecting the completion I
want, the window minimizes itself, and stays minimized for subsequent
calls to the special frame. With fluxbox, this means I can't see the
window without selecting its icon from the toolbar, which is awkward
with keyboard shortcuts, and basically requires me to use the
mouse. 

This also affects help windows. For example, if I c-h v, then use
completions to select the variable I want to see, and then exit the
help window with q, I end up with a completions frame and a help
frame, both minimized on the toolbar. They update themselves with
subsequent calls to help or completions, but don't restore themselves
to be visible when they do so.

If I c-x k the special frame it dies nicely, and when it is up I can
m-tab back and forth between the special buffer and the main emacs
frame as I want to.

How can I have this buffer either stay up or delete itself when I'm
done with it?

I'm running emacs21 on debian lenny with fluxbox. I've tried
window-dedicated-p, without effect, but couldn't find any other
variables that looked helpful.

Thanks!

Tyler

RE: special buffer frames again

[Drew Adams]

> I'm working out the bumps in setting up my special buffer frames. So
> far so good, except: if I c-x c-f to load a file, hit tab, the
> completions frame opens up. However, after selecting the completion I
> want, the window minimizes itself, and stays minimized for subsequent
> calls to the special frame. With fluxbox, this means I can't see the
> window without selecting its icon from the toolbar, which is awkward
> with keyboard shortcuts, and basically requires me to use the
> mouse.
>
> This also affects help windows. For example, if I c-h v, then use
> completions to select the variable I want to see, and then exit the
> help window with q, I end up with a completions frame and a help
> frame, both minimized on the toolbar. They update themselves with
> subsequent calls to help or completions, but don't restore themselves
> to be visible when they do so.
>
> If I c-x k the special frame it dies nicely, and when it is up I can
> m-tab back and forth between the special buffer and the main emacs
> frame as I want to.
>
> How can I have this buffer either stay up or delete itself when I'm
> done with it?
>
> I'm running emacs21 on debian lenny with fluxbox. I've tried
> window-dedicated-p, without effect, but couldn't find any other
> variables that looked helpful.

I hate to say it, but this is a general problem with Emacs, IMO. Emacs is
not very frames friendly, especially when it comes to displaying buffers
that it traditionally thinks of as "temporary". My impression is that those
who design and test Emacs generally do not test much using `pop-up-frames' =
t (separate frames), and they tend to use functions such as `bury-buffer' to
end use of a temporary window. The result, when you use frames, is
iconification of frames and other uglinesses, when all you want is for the
frame to be deleted.

I use `pop-up-frames' = t, and I've tweaked a number of Emacs primitives and
other basic functions to try to make things work better with frames. I've
used these tweaks for many years, and I think they take care of the problems
you describe, but I don't claim that everything is perfect. If you are
interested, either to try my code or to use it as inspiration for your own
tweaks, here are some links:

Doc: http://www.emacswiki.org/cgi-bin/wiki/OneOnOneEmacs
Code: http://www.emacswiki.org/cgi-bin/wiki/oneonone.el

If you don't want to take a look, at least keep this in mind: You will
probably need to redirect the focus of the frame that displays *Completions*
to the frame that has your minibuffer. That won't help your minimization
problems, but it will help with possible focus problems during completion.

HTH.

Re: special buffer frames again

[Tyler Smith]

On 2007-04-30, Drew Adams <drew.adams@oracle.com> wrote:
>
> I hate to say it, but this is a general problem with Emacs, IMO. 

It looks like others agree - I've now found two other projects that
tackle this project in different ways.

>  If you are
> interested, either to try my code or to use it as inspiration for your own
> tweaks, here are some links:
>
> Doc: http://www.emacswiki.org/cgi-bin/wiki/OneOnOneEmacs
> Code: http://www.emacswiki.org/cgi-bin/wiki/oneonone.el
>

I've taken a look, and it's very interesting. At the moment I'm
happiest with the way the R help buffers are treated by the ESS
version of special buffer frames. I've also played with the
framepop.el package, available via the emacs-goodies.el package in
Debian. Between these two packages and your code I imagine I'll be
able to hack up something to suit me, although it is apparently going
to take a bit of tinkering to get it just right.

Thanks for the pointers. I'll let you know what I come up with!

Cheers,

Tyler

Re: special buffer frames again

[Stefan Monnier]

> I hate to say it, but this is a general problem with Emacs, IMO.  Emacs is
> not very frames friendly, especially when it comes to displaying buffers
> that it traditionally thinks of as "temporary".  My impression is that
> those who design and test Emacs generally do not test much using
> `pop-up-frames' = t (separate frames), and they tend to use functions such
> as `bury-buffer' to end use of a temporary window.  The result, when you
> use frames, is iconification of frames and other uglinesses, when all you
> want is for the frame to be deleted.

Come on, Drew, you *do* know better.  At least one of the core maintainers
(i.e. yours truly) uses such a one-frame-per-buffer setup, so there is some
testing going on.  And more to the point, he specifically wants frames to be
iconified rather than deleted, so this issue of deletion/iconification is
100% orthogonal.

But yes, most other users of Emacs use few frames.  And I tend to believe
that they're more efficient for it, because unless you use a window-manager
that can be controlled efficiently from the keyboard (which basically
implies a tiled window-manager), managing frames is inefficient.

Me?  I don't even know how to touch type, so efficiency is clearly not
a concern ;-)


        Stefan

Re: special buffer frames again

[Tyler Smith]

On 2007-05-01, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> And more to the point, he specifically wants frames to be iconified
> rather than deleted, so this issue of deletion/iconification is 100%
> orthogonal.

If 'he' refers to me, then no, iconification is the one thing I don't
want to happen.

>
> But yes, most other users of Emacs use few frames.  And I tend to believe
> that they're more efficient for it, because unless you use a window-manager
> that can be controlled efficiently from the keyboard (which basically
> implies a tiled window-manager), managing frames is inefficient.
>

My window manager is Fluxbox, which allows for relatively efficient
bouncing between frames, as well as between desktops. The one thing I
can't do easily is recall an iconified frame. 

My typical work session on emacs lately involves an R buffer, a few R
scripts, multiple .tex buffers, various log/message buffers associated
with ESS and TeX, a shell buffer... This is usually displayed with one or
two windows, as I transfer info between buffers, particularly between
R and its scripts. iswitchb makes for relatively easy management of
all the various buffers, but having a help or completion buffer split
my screen is still annoying, and it would be much preferable to dump
these temporary buffers into a temporary frame, as long as I can then
control the behaviour of that frame. 

If you have any other suggestions that'd be great!

Thanks,

Tyler

Re: special buffer frames again

[Stefan Monnier]

> My typical work session on emacs lately involves an R buffer, a few R
> scripts, multiple .tex buffers, various log/message buffers associated
> with ESS and TeX, a shell buffer... This is usually displayed with one or
> two windows, as I transfer info between buffers, particularly between
> R and its scripts. iswitchb makes for relatively easy management of
> all the various buffers, but having a help or completion buffer split
> my screen is still annoying, and it would be much preferable to dump
> these temporary buffers into a temporary frame, as long as I can then
> control the behaviour of that frame.

Have you tried a scheme such as the one provided by framepop.el?
I.e. have a frame dedicated to such temporary buffers?


        Stefan

Re: special buffer frames again

[Tyler Smith]

On 2007-05-01, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> My typical work session on emacs lately involves ...
>
> Have you tried a scheme such as the one provided by framepop.el?
> I.e. have a frame dedicated to such temporary buffers?
>

I'm just starting to play with framepop. It seems to do almost
everything I want - the framepop frames behave nicely, and I've set
their parameters such that they appear in the size and location I want
them.

The only problem is that it is awkward to get into those frames, such
as when you want to follow hotlinks in a help buffer, or scroll
through a long list of possible completions. So far this seems
possible only when making a copy of the framepop (f2-c), but this
seems to break the framepop behaviour - ie killing the copy of the
framepop cycles through buffers instead of deleting the frame.

I do like the ability to raise and lower/invisible the framepop, which
nicely puts it out of the way when I'm done with it. The toggle option
is one-way on my system though - f2-z iconifies the frame, but a
subsequent f2-z fails to restore it.

At the moment framepop looks like the closest thing to what I want,
but it will take some time to either train myself to use it properly
or tweak it to suit my needs.

Cheers,

Tyler

RE: special buffer frames again

[Drew Adams]

> > I hate to say it, but this is a general problem with Emacs,
> > IMO.  Emacs is not very frames friendly, especially when it
> > comes to displaying buffers that it traditionally thinks of
> > as "temporary".  My impression is that those who design and
> > test Emacs generally do not test much using
> > `pop-up-frames' = t (separate frames), and they tend to use
> > functions such as `bury-buffer' to end use of a temporary
> > window.  The result, when you use frames, is iconification
> > of frames and other uglinesses, when all you
> > want is for the frame to be deleted.
>
> Come on, Drew, you *do* know better.  At least one of the core
> maintainers (i.e. yours truly) uses such a one-frame-per-buffer
> setup, so there is some testing going on.

And I'm thankful for that, Stefan.

I still have the impression that Emacs designers and testers "*generally* do
not test *much* using `pop-up-frames' = t." Emacs is generally unfriendly to
`pop-up-frames' = t, IMO. If the Emacs maintainers forced themselves to use
it for a week, I'll bet that a few changes (fixes) would be made ;-). I've
reported bugs that were obviously the result of not testing with `t', but
more needs to be done than fix the occasional oversight, IMO.

I don't say that `pop-up-frames' = t should be the default value or that
everyone should adopt it. I do think that testing does not reflect this use
case anywhere near as much as the nil case.

That it is tested a little less is OK, because most users use nil (although
perhaps that is also a result, not only a cause - many people just use
default values, and some who try `t' might give up because of annoyance).
But there are some basic problems that are not well addressed, I think,
because maintainers don't try enough stuff using `t'.

> And more to the point, he specifically wants frames to be
> iconified rather than deleted,

Yes, I'm aware that one Emacs developer does have that preference ;-).

As you and I have discussed, this can also depend on the window manager. In
Windows, for instance, animated iconification can be distracting, and it
stacks stuff in the task bar (even if grouped in one Emacs icon, on XP).

I never understood your preference, but I respect it. I'd like to stand over
your shoulder for an hour, to see how you use Emacs. I find it hard to
imagine that automatic iconification of frames that are no longer in use
would not be annoying, but I'm open to learning ;-).

Thought experiment: Imagine if Emacs windows were always iconified instead
of simply disappearing when you are done with them - do you think many users
would complain? I'll bet that such a feature would be removed within 48
hours.

> so this issue of deletion/iconification is 100% orthogonal.

I don't see how that follows, but have that your way.

FWIW, the OP specifically pointed to the annoyance of iconification - he was
looking for a way to eliminate that. Maybe you have a suggestion for him,
explaining how you avoid this annoyance - or how you avoid being annoyed by
it ;-)?

> But yes, most other users of Emacs use few frames.
> And I tend to believe that they're more efficient for it,
> because unless you use a window-manager that can be controlled
> efficiently from the keyboard (which basically implies a tiled
> window-manager), managing frames is inefficient.

Well, I won't get into a discussion now about keyboard vs mouse or use of
different window managers. I do accept that keyboard use is often more
efficient than mouse use, although direct access by a pointing device is
much faster for some manipulations. (Mouse haters: Please don't bother to
flame.)

I don't know why keyboard control of frames would require a tiled window
mgr - IOW, I don't understand you, here. One can control frames quite well
from the keyboard. I use the keyboard to move, resize, raise, lower, delete,
focus, and iconify frames - I rarely use the mouse to manipulate frames. (I
don't maximize/restore frames from the keyboard, however.) Can you elaborate
about what you meant?

> Me?  I don't even know how to touch type, so efficiency is clearly not
> a concern ;-)

I do touch-type, but I don't claim that that makes me particularly
efficient, with or without frames. I've known more than a few programmers
who use only one or two fingers and still type faster than I.

Yes, I too would point out that efficiency is not the only criterion.
Personally, I would prefer frames to Emacs windows for most things even if I
found that using them was less efficient.

People use Emacs differently, and they have different preferences. My point
is that much of Emacs is not designed/implemented so that it plays well with
`pop-up-frames' = t.

Re: special buffer frames again

[Stefan Monnier]

> I don't say that `pop-up-frames' = t should be the default value or that
> everyone should adopt it.  I do think that testing does not reflect this
> use case anywhere near as much as the nil case.

Of course.

>> And more to the point, he specifically wants frames to be
>> iconified rather than deleted,
> Yes, I'm aware that one Emacs developer does have that preference ;-).
> As you and I have discussed, this can also depend on the window manager.
> In Windows, for instance, animated iconification can be distracting, and it
> stacks stuff in the task bar (even if grouped in one Emacs icon, on XP).

Mine stack up in a "icon-manager", which is similar, except it's stacked
vertically rather than horizontally (and there's no grouping in menus when
size becomes a problem).

Maybe a more significant difference is that my window-manager is configured
to not auto-place new windows, so whenever Emacs creates a new frame I have
to manually place it.  So remembering placement is particularly important.

> I never understood your preference, but I respect it.  I'd like to stand
> over your shoulder for an hour, to see how you use Emacs.  I find it hard
> to imagine that automatic iconification of frames that are no longer in
> use would not be annoying, but I'm open to learning ;-).

I have 2 separate icon-managers: one for Emacs windows, and another for
the rest.  So my Emacs icon-manager acts as a "buffer list".  So I can just
select the relevant buffer with the mouse rather than use C-x b.

> Thought experiment: Imagine if Emacs windows were always iconified instead
> of simply disappearing when you are done with them - do you think many users
> would complain?  I'll bet that such a feature would be removed within 48
> hours.

I'm not sure I see the relation.  To me it's more like buffers: buffers can
be displayed or (not in which case they're like iconified, visible in the
buffer-list).  Some users are bothered by the ever growing list of buffers,
but they can always use C-x k when it's a problem.  And I do the same:
basically all my frames are "dedicated", so if I do C-x k, it deletes the
relevant frame.

In any case, the main problem for me with deletion of frames is the loss of
information (mostly placement).

> FWIW, the OP specifically pointed to the annoyance of iconification - he was
> looking for a way to eliminate that. Maybe you have a suggestion for him,
> explaining how you avoid this annoyance - or how you avoid being annoyed by
> it ;-)?

I don't think the problem is iconification, but it's the accumulation of
frames: so a better solution might be to reuse a special frame dedicated to
those temporary buffers.


        Stefan

RE: special buffer frames again

[Drew Adams]

> Maybe a more significant difference is that my window-manager is
> configured to not auto-place new windows, so whenever Emacs
> creates a new frame I have to manually place it.  So remembering
> placement is particularly important.

I see. That would make a big difference.

> I have 2 separate icon-managers: one for Emacs windows, and
> another for the rest.  So my Emacs icon-manager acts as a
> "buffer list".  So I can just select the relevant buffer
> with the mouse rather than use C-x b.

I see.

FWIW, when I do want to iconify a frame, I actually use my own
thumbnail-frame pseudo-icons, instead of iconifying to the Window task bar
(http://www.emacswiki.org/cgi-bin/wiki/FisheyeWithThumbs). So the behavior
is similar to that of other window mgrs: icons on the desktop vs in the task
bar. (But the "icons" are really frames, so I can stack them any way I want,
scroll, select text, monitor process progress, and so on.) This is not very
relevant here, however.

> > Thought experiment: Imagine if Emacs windows were always
> > iconified instead of simply disappearing when you are done
> > with them - do you think many users would complain?
> > I'll bet that such a feature would be removed within 48 hours.
>
> I'm not sure I see the relation.

`pop-up-frames' = t makes Emacs use frames instead of windows, by default.
If Emacs treated its windows the way it currently treats its frames (e.g.
iconify when done), then I think more people would realize how poorly Emacs
plays with `pop-up-frames' = t.

> To me it's more like buffers: buffers can be displayed or
> (not in which case they're like iconified, visible in the
> buffer-list).

The main annoyances with iconification are 1) distraction of seeing the
frame zoom into an icon (at least on Windows), and 2) visible presence of
the icons.

When a buffer is no longer displayed, it is not apparent anywhere - unless
you explicitly choose to show a list of buffers. If a buffer list were
always visible, taking up screen real estate, and if the displayed buffers
zoomed into that buffer list in an animated way whenever you undisplayed
them, then, yes, your analogy would fit, and undisplay of a buffer would be
as annoying as undisplay of a frame is now.

But buffers and Emacs windows don't suffer from these distractions - they
just disappear (Poof!). That's what should happen to most frames (including
*Help* and *Completions*), when you are finished with them (even
temporarily). Choosing a completion or hitting C-g or hitting q in *Help*
should never iconify the frame; it should just delete it.

As you mention, as long as a buffer exists, you can always redisplay it via
the buffer list - there is no reason to also have every undisplayed buffer
in an omnipresent icon list somewhere.

> Some users are bothered by the ever growing list of buffers,

Not I, in any case. But that is one reason I do iconify some frames (using
thumbnails). I use a short list of iconified buffers, and, for less
frequently used buffers, I explicitly call upon the long buffer list (or use
completion).

> but they can always use C-x k when it's a problem.

And that would be felt sooner to be a problem if the buffer list were
displayed continually, as are icons.

> And I do the same: basically all my frames are "dedicated",
> so if I do C-x k, it deletes the relevant frame.

Same here. And I've tweaked basic code so that the display of "temporary"
buffers also goes "Poof!" when it's done.

> In any case, the main problem for me with deletion of frames is
> the loss of information (mostly placement).

Yeah, that sounds like a bummer.

If your preference for auto-iconification is based mainly on your needing to
position frames manually, would you agree that frame deletion is generally
better for people who don't share that window-mgr limitation?

> > FWIW, the OP specifically pointed to the annoyance of
> > iconification - he was looking for a way to eliminate that.
> > Maybe you have a suggestion for him, explaining how you
> > avoid this annoyance - or how you avoid being annoyed by
> > it ;-)?
>
> I don't think the problem is iconification, but it's the accumulation of
> frames: so a better solution might be to reuse a special frame
> dedicated to those temporary buffers.

That might be worth considering, but there can often be multiple such
temporary buffers at any time. I, for instance often display *Help* during
minibuffer completion.

In any case, I think the problem the OP mentioned was not accumulation of
frames, but iconification, and the fact that the iconified frames remained
iconified when he tried to access them again. *Completions* and *Help* were
sitting there as icons, making it impossible to see what was in them without
explicitly deiconifying them. Here is what he said:

Tyler> This also affects help windows. For example, if I c-h v, then use
> completions to select the variable I want to see, and then exit the
> help window with q, I end up with a completions frame and a help
> frame, both minimized on the toolbar. They update themselves with
> subsequent calls to help or completions, but don't restore themselves
> to be visible when they do so.

and

> the window minimizes itself, and stays minimized...
> this means I can't see the window without selecting its icon...

Perhaps one improvement here would be to raise frames whenever their buffers
are updated. But that might not always be desirable, depending on the frame
and the context. Frame deletion still gets my vote.

Re: special buffer frames again

[Stefan Monnier]

> FWIW, when I do want to iconify a frame, I actually use my own
> thumbnail-frame pseudo-icons, instead of iconifying to the Window task bar
> (http://www.emacswiki.org/cgi-bin/wiki/FisheyeWithThumbs).  So the behavior
> is similar to that of other window mgrs: icons on the desktop vs in the task
> bar.  (But the "icons" are really frames, so I can stack them any way I want,
> scroll, select text, monitor process progress, and so on.) This is not very
> relevant here, however.

Note that my window-manager's "icon-manager" is just a list of window names:
no icon in sight.

> If your preference for auto-iconification is based mainly on your needing to
> position frames manually, would you agree that frame deletion is generally
> better for people who don't share that window-mgr limitation?

I wouldn't know since I don't use such a setup.  But I'd doubt it, because
even if placement is automatic, it's usually not ideal, so I'd still have
to re-place some of the windows over-and-over-again.

And actually, someone who uses such a setup recently complained on
emacs-devel about a change I made that caused the frame to be deleted rather
than iconified, so frame deletion doesn't seem good either.  IIRC this
someone was called "Drew Adams", maybe you know him ;-)

> In any case, I think the problem the OP mentioned was not accumulation of
> frames, but iconification, and the fact that the iconified frames remained
> iconified when he tried to access them again. *Completions* and *Help* were
> sitting there as icons, making it impossible to see what was in them without
> explicitly deiconifying them. Here is what he said:

Looks like a plain bug in Emacs or in the window manager, then.


        Stefan

RE: special buffer frames again

[Drew Adams]

> And actually, someone who uses such a setup recently complained on
> emacs-devel about a change I made that caused the frame to be
> deleted rather than iconified, so frame deletion doesn't seem good
> either.  IIRC this someone was called "Drew Adams", maybe you know him ;-)

Please; we disagreed in that thread, including disagreeing about what was
said in the previous thread (!). Please don't spread confusion to a third
thread (and another mailing list) that has been about something different.
*Backtrace* is not the same kind of "temporary" buffer as *Completions*:
it's not obvious when someone is finished with *Backtrace*.

I was clear from the beginning (my bug report after your changes) about my
own preferences for the *Backtrace* frame:

1. Emacs 20 and 21 were fine for this - just leave the frame alone, and let
users delete it when they're done with it.

2. Your change to have automatic iconification was annoying.

3. After discussion/negotiation, I was OK with deleting the frame
automatically, instead of iconifying it - but I still prefer the Emacs 20/21
behavior here.

IOW, you preferred auto-iconification of *Backtrace*; I preferred leaving
the frame for me to delete explicitly (`C-k' or `C-0'), and the compromise
was to delete the frame whenever the user hits `q'.

Different buffers have different uses and different criteria of "done".
*Help*, for instance, should be left as is until the user explicitly quits
(`q'), at which point its standalone frame should be deleted, not iconified.
Quitting *Backtrace* with `q' isn't equivalent, IMO. It doesn't signal that
the user is finished debugging; it means only that s?he wants to quit that
particular debugging invocation and return to top level. A standalone
*Completions* frame should be deleted (not iconified) whenever completion is
finished (e.g. `RET').

People have different practices; one is not wrong and the other right. It
would be good to 1) have reasonable default behavior that reflects what many
or most people want, but also 2) let users customize the behavior easily.
Perhaps we can agree on at least that much, and then look for ways to do
that?

An unconfigurable compromise, such as that for *Backtrace*, is bound to be
unsatisfactory all around, even if the best possible compromise is found.
Both you and I should be able to get the behavior we like for something like
*Backtrace*, without individually hacking the bowels of the source code.
Likewise, for *Help*, *Completions*, and so on.