unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: npostavs@users.sourceforge.net
Cc: 24353@debbugs.gnu.org, "Clément Pit--Claudel" <clement.pit@gmail.com>
Subject: bug#24353: 25.1.1: looking-back wrong info
Date: Sat, 3 Sep 2016 11:57:01 -0700 (PDT)	[thread overview]
Message-ID: <b6223e92-ae3b-4087-abf0-6b761f34aae4@default> (raw)
In-Reply-To: <87twdwal8a.fsf@users.sourceforge.net>

> > The right fix is to have the doc do three things:
> >
> > 1. Be honest about the signature.
> 
> Casting this as a moral issue (about "honesty") doesn't seem to be
> constructive.  Anyway, the whole point of advertised-calling-convention
> is to advertise a signature different from the actual implemented one.

It's not about morality.  It's about the signature being 
accurate/truthful/correct.  Substitute "accurate" if that makes
it clearer.  It's not a moral question.  It's about helping users
as best we can.  What's the most helpful thing to do here?
That's the question.

And yes, "the whole point of advertised-calling-convention is to
advertise a signature different from the actual implemented one."
The question is whether that is the right thing to do _here_.

It is a tool used sparingly.  As I said at the outset, "I have a
question as to why this was changed."  I question whether _this_
change is a good one - whether this is a good case for using
`advertised-calling-convention'.

> > 2. Recommend strongly that you use LIMIT.
> > 3. Say WHY you should use LIMIT: not doing so can lead
> >    to poor performance.
> 
> The doc string already says
>     LIMIT if non-nil speeds up the search by specifying a minimum
>     starting position, to avoid checking matches that would start
>     before LIMIT.

Right.  And is that not enough?

Emacs itself uses `looking-back' without LIMIT in several places.
Presumably those are places where it should NOT (or cannot) be
used (or else they should be corrected).  Why would we assume now
that other programmers use `looking-back' without LIMIT when they
should be providing LIMIT?  IOW, where's the problem?

> > Had #2 and #3 been in the doc when you (presumably) first
> > consulted it, you would likely have included LIMIT, and
> > there would be no need to "upgrade" your code now.
> >
> > Is there a reason to avoid using `looking-back', even if
> > LIMIT is provided?  It too should be mentioned in the doc.
> 
> The docstring already says
>     As a general recommendation, try to avoid using
>     ‘looking-back’ wherever possible, since it is slow.

I know.  That's why I asked the question.  It just says that
it is slow, without reference to LIMIT.  Doesn't seem to be
as helpful as it presumably could be.

But again, are we sure that programmers are misusing the function?
Or is this perhaps another case of if-it-aint-broke-dont-fix-it?





  reply	other threads:[~2016-09-03 18:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-02  8:48 bug#24353: 25.1.1: looking-back wrong info Andreas Röhler
2016-09-02  8:58 ` Eli Zaretskii
2016-09-02  9:57   ` Andreas Röhler
2016-09-02 10:04     ` Eli Zaretskii
2016-09-02 17:51       ` Drew Adams
2016-09-02 19:03         ` Eli Zaretskii
2016-09-02 20:10         ` Dmitry Gutov
2016-09-02 23:59           ` Drew Adams
2016-09-03  0:03             ` Dmitry Gutov
2016-09-03  0:10               ` Drew Adams
2016-09-03  0:14             ` npostavs
2016-09-03  0:15               ` Dmitry Gutov
2016-09-03  0:28               ` Drew Adams
2016-09-03 17:35             ` Clément Pit--Claudel
2016-09-03 18:10               ` Drew Adams
2016-09-03 18:24                 ` Clément Pit--Claudel
2016-09-03 18:31                 ` npostavs
2016-09-03 18:57                   ` Drew Adams [this message]
2016-09-04 13:08                     ` Michael Heerdegen
2016-09-03 17:50             ` Clément Pit--Claudel
2016-09-03 18:42               ` Drew Adams
2016-09-03 18:52                 ` Eli Zaretskii
     [not found] <<e554564c-50a0-8c71-3b79-183ffd54b9c3@easy-emacs.de>
     [not found] ` <<83lgzael08.fsf@gnu.org>
     [not found]   ` <<a404cb34-311e-3fb3-dde8-4340e57c97e5@easy-emacs.de>
     [not found]     ` <<83k2euehyc.fsf@gnu.org>
     [not found]       ` <<bf60cf1c-b9b9-4505-ab9f-d518dcf1725c@default>
     [not found]         ` <<83eg52dszc.fsf@gnu.org>
2016-09-02 20:03           ` 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=b6223e92-ae3b-4087-abf0-6b761f34aae4@default \
    --to=drew.adams@oracle.com \
    --cc=24353@debbugs.gnu.org \
    --cc=clement.pit@gmail.com \
    --cc=npostavs@users.sourceforge.net \
    /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).