unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: martin rudalics <rudalics@gmx.at>, Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: RE: Documenting buffer display
Date: Tue, 23 Oct 2018 07:04:01 -0700 (PDT)	[thread overview]
Message-ID: <0900cd2f-cc4e-45ab-8da1-519bd3b75576@default> (raw)
In-Reply-To: <5BCEE2B5.9090205@gmx.at>

> I did not object to your changes when you made them because with Drew
> such objections inevitably lead to discussions why 'display-buffer'
> does it all wrong and why its earlier behavior was so much superior.

Seriously?  This is what the discussion has devolved to?

I object to this personal characterization - which borders
on ad hominem attack.

I never said anything about `display-buffer' getting
anything wrong, let alone getting it all wrong.  And I
never said that its earlier behavior was so much superior,
or even that it was superior, or even that it was as good.

On the contrary, several times, including more than once
in the current discussion, I've thanked you for the work
you've done on `display-buffer' and its doc.  It is an
improvement that users have more fine-grained control over
buffer display.  I think I've been quite clear about this.

The points I made that you might want to characterize as
objections are (1) the doc can use some improvement (and
your trying to improve it now is a good thing, not a bad
thing) and (2) I would like to see the simple conveniences
of `pop-to-frames' and `special-display-*' continue to be
supported and not discouraged.

If someone can't make such points without being branded
in the way you just did then there is little hope for a
constructive discussion.  Do you want only an echo
chamber, or do you welcome input that might help even
if it might disagree with your point of view in some
regards?

> Then why do we have all this dispute about 'display-buffer'?
> According to the majority of people because its documentation is
> confusing, wrong, incomplete, implicit, arcane or just bad.

Dunno whether it is a majority, but it's helpful that
you agree that this is a difficulty for at least some
of us.  (And I've never doubted that you agree about
this.  I know you recognize that this stuff is
complicated - in both behavior and explanation/doc.)

I, for one, am still at the state of being relatively
confused and ignorant.  I can't say that anything in
the doc is incorrect.  I expect that attempts to
clarify it are worthwhile, and I applaud them.
That's all.

FWIW, though I generally agree that the Emacs manuals
are mostly reference, we (Emacs generally, whether
officially or not) could use some more tutorial-like
presentations of using the various features provided
by `display-buffer'.  It is a powerful, complicated
construct, and its various possibilities deserve
more lead-you-by-the-hand exposure.

Somewhere.  Blogs, whatever, wherever.  Common use
cases presented and explicated.  That's one opinion.
The same thing is true for other complex areas, some
of which I've mentioned.  It wouldn't hurt to have
additional material out there that helps people to
better understand `display-buffer'.

I'm not saying that this is something that you guys
need to do.  I'm saying only that it is an area
where Emacs users could use more help, I think.
I think you might agree about this.

Hardly a day goes by, that one or more questions
related to this don't appear on Emacs Stack
Exchange or Reddit, for example.  And when I say
`display-buffer' I include questions about windows:
placement, which buffers, etc.



  parent reply	other threads:[~2018-10-23 14:04 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-20 12:20 Documenting buffer display martin rudalics
2018-10-20 13:21 ` Eli Zaretskii
2018-10-20 18:02   ` martin rudalics
2018-10-21 12:56     ` Eli Zaretskii
2018-10-22  9:06       ` martin rudalics
2018-10-22 13:55         ` Eli Zaretskii
2018-10-22 19:14           ` martin rudalics
2018-10-22 19:27             ` Eli Zaretskii
2018-10-23  8:58               ` martin rudalics
2018-10-23 11:26                 ` Pierre-Yves Luyten
2018-10-23 13:45                   ` martin rudalics
2018-10-23 17:40                   ` Stefan Monnier
2018-10-23 14:04                 ` Drew Adams [this message]
2018-10-23 18:18                   ` martin rudalics
2018-10-23 15:18                 ` Eli Zaretskii
2018-10-23 18:23                   ` martin rudalics
2018-10-23 19:07                     ` Eli Zaretskii
2018-10-24  9:44                       ` martin rudalics
2018-10-24 14:48                         ` Eli Zaretskii
2018-10-24 17:40                           ` martin rudalics
2018-10-24 18:25                             ` Eli Zaretskii
2018-10-25 20:42                             ` Juri Linkov
2018-10-23 15:52                 ` Alan Mackenzie
2018-10-23 18:25                   ` martin rudalics
2018-11-08 19:25                   ` martin rudalics
2018-10-22  1:39   ` Michael Welsh Duggan
2018-10-22  5:54     ` Eli Zaretskii
2018-10-20 15:22 ` Drew Adams
2018-10-20 18:02   ` martin rudalics
2018-10-20 18:24     ` Drew Adams
2018-10-21  8:22       ` martin rudalics
2018-11-04  9:06 ` martin rudalics

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=0900cd2f-cc4e-45ab-8da1-519bd3b75576@default \
    --to=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rudalics@gmx.at \
    /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).