unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: <help-gnu-emacs@gnu.org>
Subject: RE: special buffer frames again
Date: Tue, 1 May 2007 11:38:29 -0700	[thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICOEFPDMAA.drew.adams@oracle.com> (raw)
In-Reply-To: <jwvlkg8qy5z.fsf-monnier+gnu.emacs.help@gnu.org>

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

  parent reply	other threads:[~2007-05-01 18:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.20.1177976428.32220.help-gnu-emacs@gnu.org>
2007-05-01  1:53 ` special buffer frames again Tyler Smith
2007-05-01 17:02 ` Stefan Monnier
2007-05-01 18:11   ` Tyler Smith
2007-05-01 19:29     ` Stefan Monnier
2007-05-01 20:05       ` Tyler Smith
2007-05-01 18:38   ` Drew Adams [this message]
     [not found] <mailman.65.1178053867.32220.help-gnu-emacs@gnu.org>
2007-05-03 14:21 ` Stefan Monnier
2007-05-03 15:33   ` Drew Adams
     [not found] <mailman.54.1178045180.32220.help-gnu-emacs@gnu.org>
2007-05-01 19:33 ` Stefan Monnier
2007-05-01 21:04   ` Drew Adams
2007-04-30 19:33 Tyler Smith
2007-04-30 23:32 ` Drew Adams

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=DNEMKBNJBGPAOPIJOOICOEFPDMAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    --cc=help-gnu-emacs@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.
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).