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>, emacs-devel <emacs-devel@gnu.org>
Subject: RE: `pop-up-frames' and binding/setting user options [was: Documenting buffer display]
Date: Tue, 23 Oct 2018 07:13:52 -0700 (PDT)	[thread overview]
Message-ID: <66b0ff55-af0d-42c0-80b1-87585e4c557f@default> (raw)
In-Reply-To: <5BCEE2C8.50008@gmx.at>

>  >> This command would be for usually popping up the bookmark in another
>  >> frame and the user would know that.  However, for certain, specified
>  >> bookmarks the user might want to use the selected frame instead and
>  >> still use the same command.
>  >
>  > Why would someone choose to use an `other-frame'
>  > command to get some behavior other than `other-frame'?
> 
> Because for a user 'other-frame' may be TRT for most bookmarks but not
> for a few specific ones.

Sure, we both acknowledged that.  But why would you
choose to use an `other-frame' command for those
specific bookmarks for which it is not TRT?  That's
the question.

>  > Each of those specific bookmark jump commands
>  > specifies a particular buffer-display behavior
>  > (except `bookmark-jump', which accepts a behavior
>  > argument).  Is that what you call the application
>  > overriding it?
> 
> No.  It's the way the command specifies the behavior: If it does so by
> binding a global variable, the result may be equivocal when the user
> has customized 'display-buffer-alist'.  If it does so by setting the
> ACTION argument, the result is unequivocal.

Specifics, please.  If by equivocal you mean here that
a user may not get what she expects sometimes then I
imagine that the answer is to not use that approach in
that case.

So far, you haven't shown (AFAICT) any difference
between binding `pop-up-frames' and imposing the same
behavior by passing an ACTION argument.  But if there
is a difference in some case then I'd think the answer
would be to use whichever of those approaches DTRT,
and not the other.

Is your argument against `pop-up-frames' only that
of a maintainer - not wanting to bother maintaining
support?  Or is it that you see it as a bad thing
for users to be able to use `pop-up-frames'?

Saying that in some case (which I haven't seen
demonstrated yet) it doesn't do the same thing that
passing an equivalent argument does, does not
invalidate its usefulness.  At most it would be an
argument for not using it in those hypothetical
problematic cases.



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

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-21 16:10 `pop-up-frames' and binding/setting user options [was: Documenting buffer display] Drew Adams
2018-10-21 17:01 ` Eli Zaretskii
2018-10-22  9:06 ` martin rudalics
2018-10-22 14:16   ` Drew Adams
2018-10-22 19:15     ` martin rudalics
2018-10-22 20:42       ` Drew Adams
2018-10-23  8:58         ` martin rudalics
2018-10-23 14:13           ` Drew Adams [this message]
2018-10-23 17:35             ` Stefan Monnier
2018-10-23 18:01               ` Drew Adams
2018-10-23 18:20                 ` Stefan Monnier
2018-10-23 18:28                   ` Stefan Monnier
2018-10-23 23:05                     ` Drew Adams
2018-10-23 22:57                   ` Drew Adams
2018-10-23 18:19             ` 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=66b0ff55-af0d-42c0-80b1-87585e4c557f@default \
    --to=drew.adams@oracle.com \
    --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).