From: "Drew Adams" <drew.adams@oracle.com>
To: "'Chong Yidong'" <cyd@gnu.org>, <emacs-devel@gnu.org>
Subject: RE: Marking old window variables obsolete
Date: Thu, 9 Aug 2012 07:12:57 -0700 [thread overview]
Message-ID: <6863B68E762149B28EF9C1A159D441A3@us.oracle.com> (raw)
In-Reply-To: <87fw7wpfid.fsf@gnu.org>
> The new display-buffer machinery still supports the following
> variables:
>
> special-display-buffer-names
> special-display-regexps
> special-display-frame-alist
> special-display-function
> same-window-buffer-names
> same-window-regexps
> display-buffer-reuse-frames
>
> I think we can mark these as obsolete for 24.2. Any objections?
>
> There's also pop-up-frames and pop-up-windows, but I think we
> can wait a few releases before marking those as obsolete.
FWIW and for the record, I disagree with _all_ of that proposal. Please do not
do this. There should be _no_ hurry to do anything of the sort. Why can't you
wait a few releases - or more - for all of the above?
In fact, I would like to see these variables continued anyway, as (to me, at
least), a much simpler, alternative way to customize buffer display. If the
variables have fancy equivalents in the new machinery, fine. Let users choose:
fancy or simple, super-general or (presumably) more limited.
I do not claim _any_ expertise in this area - far from it. And that's one
reason I ask that the simple approach be kept (as well as the more complex).
You might be able to do more and better with the new system - or as you say
"machinery" (usine a gaz?), but it does not seem (to me) to be so
straightforward (simple) to use.
It is still not clear to me how to - easily - replace the above user options,
and I use them heavily. The doc regarding the new machinery, if not the
machinery itself (can't speak to that), is impenetrable, for me.
I'm sorry to say that, and I tried to raise the doc problem early, but I still
do not see a clear explanation. Perhaps that is just a reflection of how
complicated the machinery is - I can't judge, for lack of understanding.
Just one, dumb user - who happens to actually _use_ the simple variables you are
in a hurry to toss overboard.
(Out of curiosity, I wonder how much those who came up with the new machinery
ever actually used those variables. I don't argue that the machinery is bad or
is implemented badly - on the contrary, I am convinced that Martin and others
did a great job. But I wonder about its use value and ease of use, at least for
some users.)
next prev parent reply other threads:[~2012-08-09 14:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-09 9:43 Marking old window variables obsolete Chong Yidong
2012-08-09 14:12 ` Drew Adams [this message]
2012-08-09 16:01 ` Eli Zaretskii
2012-08-09 16:10 ` Drew Adams
2012-08-09 16:53 ` Eli Zaretskii
2012-08-09 18:16 ` Drew Adams
2012-08-09 18:37 ` Óscar Fuentes
2012-08-09 21:51 ` Drew Adams
2012-08-09 19:28 ` Eli Zaretskii
2012-08-09 21:53 ` Drew Adams
2012-08-10 6:18 ` Eli Zaretskii
2012-08-09 14:53 ` Stefan Monnier
2012-08-09 15:57 ` Eli Zaretskii
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6863B68E762149B28EF9C1A159D441A3@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=cyd@gnu.org \
--cc=emacs-devel@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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.