`looking-back' strange warning

`looking-back' strange warning

[Andreas Röhler]

M-x `byte-compile-file' warns:

... Warning: looking-back called with 1 argument, but
     requires 2-3


While its definition:

(defun looking-back (regexp &optional limit greedy)


Docu bug?

Cheers,

Andreas

GNU Emacs 25.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.23) of 2015-08-27

Re: `looking-back' strange warning

[Michael Heerdegen]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> M-x `byte-compile-file' warns:
>
> ... Warning: looking-back called with 1 argument, but
>     requires 2-3

> While its definition:
>
> (defun looking-back (regexp &optional limit greedy)

An advertised calling convention had been added to that definition:

(declare
   (advertised-calling-convention (regexp limit &optional greedy)
   "25.1"))

AFAIR it had been added because `looking-back' is much slower without a
LIMIT.

Michael.

Re: `looking-back' strange warning

[Tassilo Horn]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> M-x `byte-compile-file' warns:
>
> ... Warning: looking-back called with 1 argument, but
>     requires 2-3
>
> While its definition:
>
> (defun looking-back (regexp &optional limit greedy)
>
> Docu bug?

No, its definition contains

  (declare
   (advertised-calling-convention (regexp limit &optional greedy) "25.1"))

and that's what creates the warnings.  You can still use it without
LIMIT but you should not.  This probably means that in Emacs 33, LIMIT
will become a mandatory argument.

Bye,
Tassilo

Re: `looking-back' strange warning

[Dmitry Gutov]

On 09/30/2015 11:25 AM, Andreas Röhler wrote:

> Docu bug?

It's a feature: calling `looking-back' without LIMIT is slow, don't do 
that. The compiler is telling you that.

Re: `looking-back' strange warning

[Andreas Röhler]

Am 01.10.2015 um 08:50 schrieb Dmitry Gutov:
> On 09/30/2015 11:25 AM, Andreas Röhler wrote:
>
>> Docu bug?
>
> It's a feature: calling `looking-back' without LIMIT is slow, don't do 
> that.

Hmm, would volontier to make that fast instead - if write-permission is 
given :)

> The compiler is telling you that.
>

Thanks all!

Re: `looking-back' strange warning

[Tassilo Horn]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

>>> Docu bug?
>>
>> It's a feature: calling `looking-back' without LIMIT is slow, don't do that.
>
> Hmm, would volontier to make that fast instead - if write-permission
> is given :)

Looking at the code, I'd say `looking-back' is only slow if GREEDY is t
in which case the start of the match may be before LIMIT anyhow.  So I
don't see how providing a LIMIT would help too much, or is
`re-search-backward' already slow without LIMIT?  If so, then its own
documentation should tell so, too.

Bye,
Tassilo

Re: `looking-back' strange warning

[Andreas Röhler]

Am 01.10.2015 um 10:20 schrieb Tassilo Horn:
> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>
>>>> Docu bug?
>>> It's a feature: calling `looking-back' without LIMIT is slow, don't do that.
>> Hmm, would volontier to make that fast instead - if write-permission
>> is given :)
> Looking at the code, I'd say `looking-back' is only slow if GREEDY is t
> in which case the start of the match may be before LIMIT anyhow.  So I
> don't see how providing a LIMIT would help too much, or is
> `re-search-backward' already slow without LIMIT?

AFAIK thats it.

Also "greedy" seems not to work at all:

(defun foo3 ())

(progn (re-search-backward "o+" nil t 3)
        (message "%s" (match-beginning 0)))

The first "o" is reported as match-beginning.

Re: `looking-back' strange warning

[Tassilo Horn]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

>>>>> Docu bug?
>>>> It's a feature: calling `looking-back' without LIMIT is slow, don't do that.
>>> Hmm, would volontier to make that fast instead - if write-permission
>>> is given :)
>> Looking at the code, I'd say `looking-back' is only slow if GREEDY is t
>> in which case the start of the match may be before LIMIT anyhow.  So I
>> don't see how providing a LIMIT would help too much, or is
>> `re-search-backward' already slow without LIMIT?
>
> AFAIK thats it.
>
> Also "greedy" seems not to work at all:
>
> (defun foo3 ())
>
> (progn (re-search-backward "o+" nil t 3)
>        (message "%s" (match-beginning 0)))
>
> The first "o" is reported as match-beginning.

Is it intended that you don't use `looking-back' here?

But you are right that in the situation above, a string like "foo3"
should account for only one single match because the greedy regex "o+"
is allowed to consume any number of consecutive os.  But that doesn't
seem to work for backward searches, and that's probably the cause for
the weird extension mechanism in the greedy case for `looking-back'.

Well, it works fine with forward searches:

(progn (re-search-forward "fo+?" nil t)   ;non-greedy
       ;; (re-search-forward "fo+" nil t) ;greedy
       (message "%s %s" (match-beginning 0) (match-end 0)))

(defun fooooo4 ())
       ^ ^   ^
       | |   `--- end: greedy
       | `------- end: non-greedy
       `--------- beginning

Bye,
Tassilo

Re: `looking-back' strange warning

[Artur Malabarba]

It's not a bug. It's declared as demanding two arguments so that people
will use it.
M-x `byte-compile-file' warns:

... Warning: looking-back called with 1 argument, but
    requires 2-3


While its definition:

(defun looking-back (regexp &optional limit greedy)


Docu bug?

Cheers,

Andreas

GNU Emacs 25.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.23) of 2015-08-27

RE: `looking-back' strange warning

[Drew Adams]

> It's a feature: calling `looking-back' without LIMIT is slow, don't do
> that. The compiler is telling you that.

No, it is "warning" you that there are 2-3 "required" arguments, which is patently false.  This is a product bug, IMO.  Wrong message.

Letting you know how to improve performance or avoid slow performance is helpful information, but it is not a "warning" - there is no danger here.  And there is only one required argument.

Re: `looking-back' strange warning

[Dmitry Gutov]

On 10/01/2015 07:00 PM, Drew Adams wrote:

> Letting you know how to improve performance or avoid slow performance is helpful information, but it is not a "warning" - there is no danger here.  And there is only one required argument.

It's the first step toward making the LIMIT argument non-optional.

Re: `looking-back' strange warning

[Andreas Röhler]

Am 01.10.2015 um 19:56 schrieb Dmitry Gutov:
> On 10/01/2015 07:00 PM, Drew Adams wrote:
>
>> Letting you know how to improve performance or avoid slow performance 
>> is helpful information, but it is not a "warning" - there is no 
>> danger here.  And there is only one required argument.
>
> It's the first step toward making the LIMIT argument non-optional.
>

It's a wrong warning message - and a really bad style WRT users.

BTW the intendet use case doesn't exist - as Tassilo found out.
Backward move is slow - a limit doesn't change that, while the intendet 
change would provide a burden for the programmer. Beside the change 
would break a lot of code.

Re: `looking-back' strange warning

[Barry Margolin]

In article <mailman.176.1443721449.16064.help-gnu-emacs@gnu.org>,
 Drew Adams <drew.adams@oracle.com> wrote:

> > It's a feature: calling `looking-back' without LIMIT is slow, don't do
> > that. The compiler is telling you that.
> 
> No, it is "warning" you that there are 2-3 "required" arguments, which is 
> patently false.  This is a product bug, IMO.  Wrong message.
>
> Letting you know how to improve performance or avoid slow performance is 
> helpful information, but it is not a "warning" - there is no danger here.  
> And there is only one required argument.

The message specifically said "Warning:". How can you say it's not a 
warning?

You're right that the wording could be improved, maybe it should say 
that this calling sequence is deprecated.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: `looking-back' strange warning

[Dmitry Gutov]

On 10/01/2015 09:24 PM, Andreas Röhler wrote:

> BTW the intendet use case doesn't exist - as Tassilo found out.

I'm unconvinced, but I don't have the time to investigate it now.

If `looking-back' doesn't work as intended, or LIMIT doesn't help, you 
or he should file a bug with details.

Re: `looking-back' strange warning

[Andreas Röhler]

Am 01.10.2015 um 20:59 schrieb Dmitry Gutov:
> On 10/01/2015 09:24 PM, Andreas Röhler wrote:
>
>> BTW the intendet use case doesn't exist - as Tassilo found out.
>
> I'm unconvinced, but I don't have the time to investigate it now.
>
> If `looking-back' doesn't work as intended, or LIMIT doesn't help, you 
> or he should file a bug with details.

The short-coming is well-known and was answered years ago like "didn't 
have time yet to implement backward-moves according to forward-ones". 
Might also be is a comment in source like that.

WRT to limit: it is unrelated to the slowness.

Depending from the task it might be useful - keeping it optional seems TRT.

Re: `looking-back' strange warning

[Dmitry Gutov]

On 10/01/2015 10:55 PM, Andreas Röhler wrote:

> The short-coming is well-known and was answered years ago like "didn't
> have time yet to implement backward-moves according to forward-ones".
> Might also be is a comment in source like that.

Do you have a bug number?

> WRT to limit: it is unrelated to the slowness.

Yes, it is. Without limit, the function has to scan until the beginning 
the buffer, which is the slower the bigger the buffer is.

RE: `looking-back' strange warning

[Drew Adams]

> > > It's a feature: calling `looking-back' without LIMIT is slow, don't do
> > > that. The compiler is telling you that.
> >
> > No, it is "warning" you that there are 2-3 "required" arguments, which
> > is patently false.  This is a product bug, IMO.  Wrong message.
> >
> > Letting you know how to improve performance or avoid slow performance is
> > helpful information, but it is not a "warning" - there is no danger
> > here.  And there is only one required argument.
> 
> The message specifically said "Warning:". How can you say it's not a
> warning?

1. I said that it warns you.  In its form it is clearly a warning.

2. IMHO, this kind of information should not be presented as a warning.
   There is no specific danger involved, such as possible loss of data
   or material.

> You're right that the wording could be improved, maybe it should say
> that this calling sequence is deprecated.

Precisely.  It can even say that use of the optional argument(s) is
recommended.  It can even say that this can improve performance.
It can add any information it likes, including how it affects
performance or what alternatives are available.

But IMHO the message should not take the form of a warning.
Or else it should actually warn of something.  Currently it does not.

At least as important is that it should not tell users that there
are 2-3 required arguments.  There is only 1 required argument.

(It doesn't even make sense to talk about 2-3 required arguments.
Required arguments are required.  There is no choice of 2 or 3.)

It's a poor message that apparently represents excessive zeal
on the part of someone who discovered an anti-use case and
wanted to give users some guidance about avoiding it.  That
would be fine (great!), but this is not the way to do that (IMHO).

Re: `looking-back' strange warning

[Stefan Monnier]

> `re-search-backward' already slow without LIMIT?

Note that re-search-* performs a *search* whereas looking-at (and
looking-back) perform a *match*, which is expected to be quicker.

re-search-* is implemented by performing a *match* at every position and
stop at the first where a match is encountered.


        Stefan

Re: `looking-back' strange warning

[Stefan Monnier]

> 2. IMHO, this kind of information should not be presented as a warning.
>    There is no specific danger involved, such as possible loss of data
>    or material.

There is a clear and real danger that the code will stop working in
a future Emacs version.


        Stefan

Re: `looking-back' strange warning

[Stefan Monnier]

> Depending from the task it might be useful

You can pass (point-min) for the limit if that's what you want.
Making it optional Encourages people to think that looking-at is just
like looking-back, with the same performance characteristic, whereas
making it mandatory encourages people to put a reasonable limit and
hence avoid pathological behavior at the end of large buffers.


        Stefan

Re: `looking-back' strange warning

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> You can pass (point-min) for the limit if that's what you want.
> Making it optional Encourages people to think that looking-at is just
> like looking-back, with the same performance characteristic, whereas
> making it mandatory encourages people to put a reasonable limit and
> hence avoid pathological behavior at the end of large buffers.

My two cents: Even if you specify an optimal limit, `looking-back' can
still be unnecessarily slow.  For example,

   (looking-back "xy" 2)

is much slower than

    (and (> (point) 2)
         (save-excursion
           (goto-char (- (point) 2))
           (looking-at "xy")))

where "xy" stands for any plain string.


Michael.

Re: `looking-back' strange warning

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> You can pass (point-min) for the limit if that's what you want.
> Making it optional Encourages people to think that looking-at is just
> like looking-back, with the same performance characteristic, whereas
> making it mandatory encourages people to put a reasonable limit and
> hence avoid pathological behavior at the end of large buffers.

My two cents: Even if you specify an optimal limit, `looking-back' can
still be unnecessarily slow.  For example,

   (looking-back "xy" 2)

is much slower than

    (and (> (point) 2)
         (save-excursion
           (goto-char (- (point) 2))
           (looking-at "xy")))

where "xy" stands for any plain string.


Michael.

RE: `looking-back' strange warning

[Drew Adams]

> > 2. IMHO, this kind of information should not be presented as a warning.
> >    There is no specific danger involved, such as possible loss of data
> >    or material.
> 
> There is a clear and real danger that the code will stop working in
> a future Emacs version.

Blah.  That's what a deprecation notice is for.  It is not
what warnings are for.

And certainly not a self-proclaimed "warning" that incorrectly
and nonsensically states that "2-3" arguments are required
when only 1 is required.

RE: `looking-back' strange warning

[Drew Adams]

> Making it optional Encourages people to think that looking-at is just
> like looking-back, with the same performance characteristic,

Clarifying such things is what doc is for.  (Yes, and even
sometimes byte-compiler messages.)

> whereas making it mandatory encourages people to put a
> reasonable limit and hence avoid pathological behavior
> at the end of large buffers.

But you have _not_ made it mandatory.  Have you?

And yet you issue a "warning" saying that it is mandatory
(or whatever "2-3 required" arguments is supposed to mean).
False alarm.  (Circulez ; il n'y a rien a voir.)

There are many, many "best practices" that are handled
normally by documenting them, including many, many that
involve far more serious consequences than a slowdown from
leaving off a LIMIT argument for `looking-back'.  Really.

Programmers are used to such notes.  And even much more
important performance (and correctness and completeness)
guidelines are not blown out of proportion and dressed up
as phony "warnings".

(This "M'as-tu vu ?!!" is the equivalent of a flashy 1995
web page with loads of revolving animated GIFs.  Another
distraction in a sea of distraction.)

Not a big deal in any case, on its own.  But symptomatic
of a misguided approach to communicating such helpful
but non-critical info to users.

Sprinkling "**WARNING!!!**" everywhere, for even the
slightest bits of notable information, dilutes what real
warnings are about.  It decreases the signal-to-noise
ratio, and just "encourages" people to ignore such
messages altogether, which is not helpful and no doubt
not what was intended.

RE: `looking-back' strange warning

[Drew Adams]

> > You can pass (point-min) for the limit if that's what you want.
> > Making it optional Encourages people to think that looking-at is just
> > like looking-back, with the same performance characteristic, whereas
> > making it mandatory encourages people to put a reasonable limit and
> > hence avoid pathological behavior at the end of large buffers.
> 
> My two cents: Even if you specify an optimal limit, `looking-back' can
> still be unnecessarily slow.  For example,
>    (looking-back "xy" 2)
> is much slower than
>     (and (> (point) 2)
>          (save-excursion (goto-char (- (point) 2))
>                          (looking-at "xy")))
> where "xy" stands for any plain string.

Definitely.  And this is in fact a typical case of the
misuse: the string to check is often a literal, so its
length is known.

This is the first thing to mention about `looking-back',
in terms of performance: avoid it altogether, if you can.

Re: `looking-back' strange warning

[Andreas Röhler]

Am 02.10.2015 um 07:12 schrieb Drew Adams:
>> Making it optional Encourages people to think that looking-at is just
>> like looking-back, with the same performance characteristic,
> Clarifying such things is what doc is for.  (Yes, and even
> sometimes byte-compiler messages.)
>
>> whereas making it mandatory encourages people to put a
>> reasonable limit and hence avoid pathological behavior
>> at the end of large buffers.
> But you have _not_ made it mandatory.  Have you?
>
> And yet you issue a "warning" saying that it is mandatory
> (or whatever "2-3 required" arguments is supposed to mean).
> False alarm.  (Circulez ; il n'y a rien a voir.)
>
> There are many, many "best practices" that are handled
> normally by documenting them, including many, many that
> involve far more serious consequences than a slowdown from
> leaving off a LIMIT argument for `looking-back'.  Really.
>
> Programmers are used to such notes.  And even much more
> important performance (and correctness and completeness)
> guidelines are not blown out of proportion and dressed up
> as phony "warnings".
>
> (This "M'as-tu vu ?!!" is the equivalent of a flashy 1995
> web page with loads of revolving animated GIFs.  Another
> distraction in a sea of distraction.)
>
> Not a big deal in any case, on its own.  But symptomatic
> of a misguided approach to communicating such helpful
> but non-critical info to users.
>
> Sprinkling "**WARNING!!!**" everywhere, for even the
> slightest bits of notable information, dilutes what real
> warnings are about.  It decreases the signal-to-noise
> ratio, and just "encourages" people to ignore such
> messages altogether, which is not helpful and no doubt
> not what was intended.
>

Thanks Drew, that's it.

Stefan, that's bad gouvernants style. What about "respect users freedom" 
and blah?

Re: `looking-back' strange warning

[Michael Heerdegen]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> Stefan, that's bad gouvernants style. What about "respect users
> freedom" and blah?

I think the warning is necessary (to let people know that a call will be
wrong in a future release), as well is the advertised calling convention
per se (the user should be forced to think about the limit).

The only thing that is not optimal is the kind of how the information is
presented to the user: the wording is confusing.  It would better if it
would say something about a changed/obsoleted signature or so.

Apart from that, I don't see a problem.  The warning goes away if you
use the LIMIT arg everywhere, and that is easy to do and doesn't harm
even if you use older Emacs versions as well, on the contrary, I think
it is an improvement for most users doing that.

Michael.

Re: `looking-back' strange warning

[Stefan Monnier]

> But you have _not_ made it mandatory.  Have you?

Oh, so now you want me to make it mandatory right away and break 99% of
all existing users out there?


        Stefan

Re: `looking-back' strange warning

[Stefan Monnier]

> And certainly not a self-proclaimed "warning" that incorrectly
> and nonsensically states that "2-3" arguments are required
> when only 1 is required.

I'm glad those little annoyances keep you entertained.


        Stefan


PS: When you finally get bored with them, feel free to send a patch.

RE: `looking-back' strange warning

[Drew Adams]

> > But you have _not_ made it mandatory.  Have you?
> > And yet you issue a "warning" saying that it is mandatory
> 
> Oh, so now you want me to make it mandatory right away and
> break 99% of all existing users out there?

Mixed-up logic.  Only if the argument is mandatory should we
send a message that it is mandatory.  It's about the message.

RE: `looking-back' strange warning

[Drew Adams]

> > That's what a deprecation notice is for.  It is not what
> > warnings are for.  And certainly not a self-proclaimed
> > "warning" that incorrectly and nonsensically states that
> > "2-3" arguments are required when only 1 is required.
> 
> I'm glad those little annoyances keep you entertained.

Please reread the Subject line.  Someone else, not I, was
apparently annoyed or puzzled enough to ask what this
incomprehensible "warning" is all about.

It may be "little" to you, but it was important or confusing
enough for someone to ask here for help about it.  That's not
something to belittle or sneer at.

But no one asked what the corresponding deprecation notice
means.  That notice is clear enough.

If you feel that a byte-compiler message can also help
here, please consider just saying that not using LIMIT is 
deprecated.  That's all.  (Just a suggestion.)

Re: `looking-back' strange warning

[Stefan Monnier]

> deprecated.  That's all.  (Just a suggestion.)

I think you missed this part:

>> PS: When you finally get bored with them, feel free to send a patch.


        Stefan

Re: `looking-back' strange warning

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> `re-search-backward' already slow without LIMIT?
>
> Note that re-search-* performs a *search* whereas looking-at (and
> looking-back) perform a *match*, which is expected to be quicker.
>
> re-search-* is implemented by performing a *match* at every position
> and stop at the first where a match is encountered.

I see, so

  (looking-back "foobar")

will call

  (re-search-backward "\\(?:foobar\\)\\=")

which in turn will at best (if point is just right of a foobar
occurrence) move point backwards 6 times and perform a match each time.
In the worst case (if we're not right of a foobar occurrence) point
moves until (or LIMIT (point-min)) trying a match each time.  So yes, I
now get that `looking-back' is slow especially when no LIMIT near is
given.

And the extension if GREEDY is t is pretty much the same as what
`re-search-*' does too (but of course in C), right?  (But that
`looking-back' concats the regex each while iteration is needless
effort.)

Bye,
Tassilo

RE: `looking-back' strange warning

[Drew Adams]

> > If you feel that a byte-compiler message can also help
> > here, please consider just saying that not using LIMIT 
> > is deprecated.  That's all.  (Just a suggestion.)
> 
> I think you missed this part:
> >> PS: When you finally get bored with them, feel free to
> >> send a patch.

You think wrong, in this case.

Re: `looking-back' strange warning

[Tom Tromey]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

Stefan> You can pass (point-min) for the limit if that's what you want.
Stefan> Making it optional Encourages people to think that looking-at is just
Stefan> like looking-back, with the same performance characteristic, whereas
Stefan> making it mandatory encourages people to put a reasonable limit and
Stefan> hence avoid pathological behavior at the end of large buffers.

It could be made faster by reversing the regexp, then adding a mode to
regex.c to consider characters from the buffer in the reverse order.
Then the limit could remain optional.

Tom

Re: `looking-back' strange warning

[Stefan Monnier]

>> > is deprecated.  That's all.  (Just a suggestion.)
>> I think you missed this part:
>> >> PS: When you finally get bored with them, feel free to
>> >> send a patch.
> You think wrong, in this case.

Then why do you think sending such a suggestion could make
any difference?  Do you really think I still haven't understood what you
think Emacs should do?  I'm not *that* dumb!


        Stefan

Re: `looking-back' strange warning

[Stefan Monnier]

> It could be made faster

Oh yes.  But I think there are much better uses of people's time, e.g.:
- merge the concurrency branch into master ;-)
- replace the regexp engine with a non-backtracking one (if planned
  ahead, making this engine bi-directional would be easy, contrary to
  the amount of work needed to make the current code bidirectional).


        Stefan

RE: `looking-back' strange warning

[Drew Adams]

> > My two cents: Even if you specify an optimal limit, `looking-back' can
> > still be unnecessarily slow.  For example,
> >    (looking-back "xy" 2)
> > is much slower than
> >     (and (> (point) 2)
> >          (save-excursion (goto-char (- (point) 2))
> >                          (looking-at "xy")))
> > where "xy" stands for any plain string.
> 
> Definitely.  And this is in fact a typical case of the
> misuse: the string to check is often a literal, so its
> length is known.
> 
> This is the first thing to mention about `looking-back',
> in terms of performance: avoid it altogether, if you can.

BTW/FWIW -
I use this function in such cases, which can be pretty common:

(defun chars-before (chars)
  "Return non-nil if the literal string CHARS is right before point.
This is more efficient that `looking-back' for this use case."
  (let* ((len  (length chars))
         (idx  (1- len))
         (pt   (point)))
    (catch 'chars-before
      (dolist (char  (append chars ()))
        (unless (condition-case nil
                    (eq char (char-before (- pt idx)))
                  (error nil))          ; e.g. `bobp'
          (throw 'chars-before nil))
        (setq idx  (1- idx)))
      t)))

http://www.emacswiki.org/emacs/download/misc-fns.el

Re: `looking-back' strange warning

[Tassilo Horn]

Drew Adams <drew.adams@oracle.com> writes:

>> > My two cents: Even if you specify an optimal limit, `looking-back' can
>> > still be unnecessarily slow.  For example,
>> >    (looking-back "xy" 2)
>> > is much slower than
>> >     (and (> (point) 2)
>> >          (save-excursion (goto-char (- (point) 2))
>> >                          (looking-at "xy")))
>> > where "xy" stands for any plain string.
>> 
>> Definitely.  And this is in fact a typical case of the
>> misuse: the string to check is often a literal, so its
>> length is known.
>> 
>> This is the first thing to mention about `looking-back',
>> in terms of performance: avoid it altogether, if you can.
>
> BTW/FWIW -
> I use this function in such cases, which can be pretty common:
>
> (defun chars-before (chars)
>   "Return non-nil if the literal string CHARS is right before point.
> This is more efficient that `looking-back' for this use case."
>   (let* ((len  (length chars))
>          (idx  (1- len))
>          (pt   (point)))
>     (catch 'chars-before
>       (dolist (char  (append chars ()))
>         (unless (condition-case nil
>                     (eq char (char-before (- pt idx)))
>                   (error nil))          ; e.g. `bobp'
>           (throw 'chars-before nil))
>         (setq idx  (1- idx)))
>       t)))

This version is about 6 times faster in the t case and a still a bit
faster in the nil case where the char before point is already different
(which is the best case for your function).

(defun chars-before (chars)
  "Return non-nil if the literal string CHARS is right before point.
This is more efficient that `looking-back' for this use case."
  (let ((beg (- (point) (length chars))))
    (unless (< beg 0)
      (save-excursion
	(goto-char beg)
	(looking-at (regexp-quote chars))))))

Bye,
Tassilo

RE: `looking-back' strange warning

[Drew Adams]

> This version is about 6 times faster in the t case and a still a bit
> faster in the nil case where the char before point is already different
> (which is the best case for your function).
> 
> (defun chars-before (chars)
>   "Return non-nil if the literal string CHARS is right before point.
> This is more efficient that `looking-back' for this use case."
>   (let ((beg (- (point) (length chars))))
>     (unless (< beg 0)
>       (save-excursion
> 	  (goto-char beg)
> 	  (looking-at (regexp-quote chars))))))

OK.  Good to know.

See also bug #17284,
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17284,
where this has been discussed and I and others proposed
code for this.

You are welcome to contribute to that (short) bug thread,
or to otherwise try to get such a function added to Emacs.

Re: `looking-back' strange warning

[Tassilo Horn]

Drew Adams <drew.adams@oracle.com> writes:

>> This version is about 6 times faster in the t case and a still a bit
>> faster in the nil case where the char before point is already different
>> (which is the best case for your function).
>> 
>> (defun chars-before (chars)
>>   "Return non-nil if the literal string CHARS is right before point.
>> This is more efficient that `looking-back' for this use case."
>>   (let ((beg (- (point) (length chars))))
>>     (unless (< beg 0)
>>       (save-excursion
>> 	  (goto-char beg)
>> 	  (looking-at (regexp-quote chars))))))
>
> OK.  Good to know.
>
> See also bug #17284,
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17284,
> where this has been discussed and I and others proposed
> code for this.

Martin's version is faster than mine, so no need to propose it.

> You are welcome to contribute to that (short) bug thread,
> or to otherwise try to get such a function added to Emacs.

I think that function is not really a viable drop-in replacement for
typical `looking-back' calls.  The latter is most frequently used to
decide "am I behind some word or sequence of words, and I don't care
about whitespace?".

Bye,
Tassilo

Re: `looking-back' strange warning

[Andreas Röhler]

Am 03.10.2015 um 08:26 schrieb Tassilo Horn:
> Drew Adams <drew.adams@oracle.com> writes:
>
>>> This version is about 6 times faster in the t case and a still a bit
>>> faster in the nil case where the char before point is already different
>>> (which is the best case for your function).
>>>
>>> (defun chars-before (chars)
>>>    "Return non-nil if the literal string CHARS is right before point.
>>> This is more efficient that `looking-back' for this use case."
>>>    (let ((beg (- (point) (length chars))))
>>>      (unless (< beg 0)
>>>        (save-excursion
>>> 	  (goto-char beg)
>>> 	  (looking-at (regexp-quote chars))))))
>> OK.  Good to know.
>>
>> See also bug #17284,
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17284,
>> where this has been discussed and I and others proposed
>> code for this.
> Martin's version is faster than mine, so no need to propose it.
>
>> You are welcome to contribute to that (short) bug thread,
>> or to otherwise try to get such a function added to Emacs.
> I think that function is not really a viable drop-in replacement for
> typical `looking-back' calls.  The latter is most frequently used to
> decide "am I behind some word or sequence of words, and I don't care
> about whitespace?".
>
> Bye,
> Tassilo
>

Just for fun:

(defun looking-back-string (string)
   "Return non-nil if the literal STRING is right before point.
This is more efficient that `looking-back' for this use case."
   (string= string (ignore-errors (buffer-substring-no-properties (- 
(point) (length string)) (point)))))

RE: `looking-back' strange warning

[Drew Adams]

> > You are welcome to contribute to that (short) bug thread,
> > or to otherwise try to get such a function added to Emacs.
> 
> I think that function is not really a viable drop-in replacement for
> typical `looking-back' calls.  The latter is most frequently used to
> decide "am I behind some word or sequence of words, and I don't care
> about whitespace?".

I did not suggest that it should be a "drop-in replacement for
typical `looking-back' calls."

The intention is to have such a function for the quite common,
but special, use case of checking for a literal sequence of
chars just before point.  That is one thing that `looking-back'
is sometimes (too often, mistakenly) used for.

IOW, it's not a case of either-or.  There is a use for
`looking-back' other than the `chars-before' use case.

RE: `looking-back' strange warning

[Drew Adams]

> >> See also bug #17284,
> >> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17284,
> >> where this has been discussed and I and others proposed
> >> code for this.
> >
> > Martin's version is faster than mine, so no need to propose it.
> >
> >> You are welcome to contribute to that (short) bug thread,
> >> or to otherwise try to get such a function added to Emacs.
>
> (defun looking-back-string (string)
>    "Return non-nil if the literal STRING is right before point.
> This is more efficient that `looking-back' for this use case."
>    (string= string (ignore-errors
>                      (buffer-substring-no-properties
>                        (- (point) (length string)) (point)))))

Again, please consider posting your suggestion to the bug
thread, or otherwise try to get such a function added to Emacs
(emacs-devel@gnu.org).

Re: `looking-back' strange warning

[Stefan Monnier]

>> It could be made faster
> Oh yes.

BTW, one easyish way to make a "fast looking-back" would be the
following:
- take GNU ELPA's "lex" package.
- add function that reverses a lex regexp (these are rx.el style sexps,
  so such a reversal should be very easy to do).
- copy "lex-match-buffer" into a new "lex-match-buffer-backward"
  reversing the operations to go backward (we're talking about 30 lines
  of code only).
- put it all together "lex-parse-re -> mylex-reverse ->
  lex-compile -> lex-match-buffer-backward".

The result should be reasonably fast, assuming all the steps until
lex-compile can be done at compile-time (in my tests lex-match-buffer
was reasonably competitive with the regexp.c engine, even tho it's
written in Elisp).

Of course it won't be 100% compatible with looking-back.   E.g. lex.el
doesn't support backreferences and you can't extract the submatches.

        Stefan