all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Drew Adams <drew.adams@oracle.com>
Cc: larsi@gnus.org, 19421@debbugs.gnu.org
Subject: bug#19421: 25.0.50; doc string of `browse-url' must describe parameter ARGS
Date: Sat, 26 Dec 2015 11:11:51 +0200	[thread overview]
Message-ID: <83bn9dk208.fsf@gnu.org> (raw)
In-Reply-To: <8db0a3c8-08b4-40c3-93a8-23ec9fcd8174@default> (message from Drew Adams on Fri, 25 Dec 2015 15:07:06 -0800 (PST))

> Date: Fri, 25 Dec 2015 15:07:06 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 19421@debbugs.gnu.org
> 
> > > Please respect the GNU Emacs convention of
> > > specifying each of the parameters in the doc string.
> > > In this case, the doc for ARGS should mention option
> > > `browse-url-new-window-flag', among other things.
> > 
> > The doc string says
> > "Passes any ARGS to the browser function."
> 
> Yes, and that IS the bug.  The doc string does not specify
> parameter ARGS properly, helpfully, usefully.
> 
> And there is this part of the same bug report, also ignored:
> 
>   > Same thing for the other functions in browse-url.el that have
>   > an ARGS &rest parameter - e.g., `browse-url-default-browser'.

What would you like us to say about ARGS?  If you looked at the
functions that can be invoked by browse-url, you know that they either
ignore ARGS or (in a few cases) use ARGS to pass the NEW-WINDOW flag,
in which case the corresponding function documents that.

So this ARGS thingy is really for custom-written browser functions, in
which case whoever writes them should know what ARGS are for, and
should document that in the doc string of the function she writes.

> This bug has not been fixed - but you know that.
> 
> Why not fix it?  Why do you not respect the GNU Emacs conventions
> and its high standards of self-documentation?  What possible good
> reason do you have for not doing the right thing, here?

Do you want us to say that ARGS are ignored?  Is that what would in
your opinion fix this bug?

> As for `browse-url-default-browser', its doc string does not
> even have the lame excuse you used: 
> 
>   > The doc string says "Passes any ARGS to the browser function."
> 
> It says nothing at all about ARGS.

Because it is just a dispatcher -- it invokes other functions, which
mostly ignore ARGS altogether.

> At least in the latest Emacs 25 snapshot I have, which dates from
> 2015-12-04:
> 
> * This is the parameters lambda list: (URL &rest ARGS).
> 
> * This is how the parameters are described in the doc string:
> 
>    "When called non-interactively, optional second argument
>     NEW-WINDOW is used instead of 'browse-url-new-window-flag'."
> 
> That's it!  Nothing about parameter URL.

I don't think URL should need any explanations in a package that deals
with browsing URLs.  So this part is a red herring, IMO.

> This is a mess, even if it is a trivial mess to fix.  It is a
> shame to deliberately ignore such a simple, and obvious bug.

You should watch your language if you want your comments to be taken
seriously.  If every minor issue is "a mess" and "a shame", then what
words can you use for real problems?





  reply	other threads:[~2015-12-26  9:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-20 23:06 bug#19421: 25.0.50; doc string of `browse-url' must describe parameter ARGS Drew Adams
2014-12-20 23:49 ` Drew Adams
2015-12-25 19:02 ` Lars Ingebrigtsen
2015-12-25 23:07   ` Drew Adams
2015-12-26  9:11     ` Eli Zaretskii [this message]
     [not found]   ` <<8db0a3c8-08b4-40c3-93a8-23ec9fcd8174@default>
     [not found]     ` <<83bn9dk208.fsf@gnu.org>
2015-12-26 16:40       ` Drew Adams
2015-12-26 18:53         ` Eli Zaretskii
     [not found]   ` <<<8db0a3c8-08b4-40c3-93a8-23ec9fcd8174@default>
     [not found]     ` <<<83bn9dk208.fsf@gnu.org>
     [not found]       ` <<41cee0e8-d5b7-4b6d-8f5b-314c01142f3a@default>
     [not found]         ` <<8337uphwi4.fsf@gnu.org>
2015-12-26 22:19           ` Drew Adams
2015-12-27 16:06             ` Eli Zaretskii
     [not found]   ` <<<<8db0a3c8-08b4-40c3-93a8-23ec9fcd8174@default>
     [not found]     ` <<<<83bn9dk208.fsf@gnu.org>
     [not found]       ` <<<41cee0e8-d5b7-4b6d-8f5b-314c01142f3a@default>
     [not found]         ` <<<8337uphwi4.fsf@gnu.org>
     [not found]           ` <<10972dc0-33fa-4ff0-974e-96156500da7f@default>
     [not found]             ` <<83h9j3ho5r.fsf@gnu.org>
2015-12-27 16:55               ` 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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83bn9dk208.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=19421@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    --cc=larsi@gnus.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.