GNU bug report logs - #10507
24.0.92; Doc of `search-forward' (and backward)

Previous Next

Package: emacs;

Reported by: "Drew Adams" <drew.adams <at> oracle.com>

Date: Sat, 14 Jan 2012 22:39:01 UTC

Severity: minor

Found in version 24.0.92

Done: Chong Yidong <cyd <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10507 in the body.
You can then email your comments to 10507 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#10507; Package emacs. (Sat, 14 Jan 2012 22:39:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Drew Adams" <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 14 Jan 2012 22:39:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.92; Doc of `search-forward' (and backward)
Date: Sat, 14 Jan 2012 14:37:16 -0800
Both the doc in the Elisp manual and the doc string seem to be
incorrect, and this has apparently been the case for a very long time
(at least as far back as Emacs 20).
 
(search-forward "e" nil nil -1) searches BACKWARD for "e".
 
But the doc says that it searches FORWARD.
 
Furthermore, the doc says explicitly that the 4th arg MUST BE POSITIVE.
That is no only NOT the case, it is even the case that the Emacs lisp
code uses a negative value as the 4th arg.  See, e.g., `zap-to-char'.

In GNU Emacs 24.0.92.1 (i386-mingw-nt5.1.2600) of 2012-01-05 on MARVIN
 Windowing system distributor `Microsoft Corp.', version 5.1.2600
 configured using `configure --with-gcc (4.6) --no-opt --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include --ldflags
 -LD:/devel/emacs/libs/gnutls-3.0.9/lib'
 





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10507; Package emacs. (Mon, 16 Jan 2012 14:12:02 GMT) Full text and rfc822 format available.

Message #8 received at 10507 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 10507 <at> debbugs.gnu.org
Subject: Re: bug#10507: 24.0.92; Doc of `search-forward' (and backward)
Date: Mon, 16 Jan 2012 09:10:06 -0500
> Furthermore, the doc says explicitly that the 4th arg MUST BE POSITIVE.
> That is no only NOT the case, it is even the case that the Emacs lisp
> code uses a negative value as the 4th arg.  See, e.g., `zap-to-char'.

"MUST BE POSITIVE" doesn't mean that a negative argument will
be rejected.  So the doc is perfectly allowed to say "MUST BE POSITIVE"
even if the code handles negative values (it just means that negative
values are "NOT SUPPORTED").  And if some core code uses negative
values, that's a naughty breach of abstraction, but that's about it.

So I see no bug here.  If you want a change, please say which and why.


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10507; Package emacs. (Mon, 16 Jan 2012 14:53:01 GMT) Full text and rfc822 format available.

Message #11 received at 10507 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 10507 <at> debbugs.gnu.org
Subject: RE: bug#10507: 24.0.92; Doc of `search-forward' (and backward)
Date: Mon, 16 Jan 2012 06:51:16 -0800
> > Furthermore, the doc says explicitly that the 4th arg MUST 
> > BE POSITIVE.  That is no only NOT the case, it is even the
> > case that the Emacs lisp code uses a negative value as the
> > 4th arg.  See, e.g., `zap-to-char'.
> 
> "MUST BE POSITIVE" doesn't mean that a negative argument will
> be rejected.  So the doc is perfectly allowed to say "MUST BE 
> POSITIVE" even if the code handles negative values (it just
> means that negative values are "NOT SUPPORTED").  And if some
> core code uses negative values, that's a naughty breach of
> abstraction, but that's about it.

Words, even words like "must", can always be somewhat ambiguous.  But "must"
generally implies some sort of enforcement or negative consequences if not
respected.

"Should" is typically used when something is recommended but not prohibited or
enforced.  And if you say nothing at all about positive/non-positive then, as
you are wont to say, "all bets are off" - no statement about support, the user
knows nothing.

I think that most readers would expect in this case ("must") that an error is
raised if the arg is not positive - or at least that the function becomes a
no-op.

Compare the doc for `/': "The arguments must be numbers or markers."

> So I see no bug here.  If you want a change, please say which and why.

A negative arg is supported by the code; it is used by Emacs source code; and it
is useful.  Knowing about it will mean simpler code by users.  Please document
(and support) it.  Thx.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10507; Package emacs. (Mon, 16 Jan 2012 15:23:01 GMT) Full text and rfc822 format available.

Message #14 received at 10507 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 10507 <at> debbugs.gnu.org
Subject: Re: bug#10507: 24.0.92; Doc of `search-forward' (and backward)
Date: Mon, 16 Jan 2012 10:21:30 -0500
>> > Furthermore, the doc says explicitly that the 4th arg MUST 
>> > BE POSITIVE.  That is no only NOT the case, it is even the
>> > case that the Emacs lisp code uses a negative value as the
>> > 4th arg.  See, e.g., `zap-to-char'.
>> 
>> "MUST BE POSITIVE" doesn't mean that a negative argument will
>> be rejected.  So the doc is perfectly allowed to say "MUST BE 
>> POSITIVE" even if the code handles negative values (it just
>> means that negative values are "NOT SUPPORTED").  And if some
>> core code uses negative values, that's a naughty breach of
>> abstraction, but that's about it.

> Words, even words like "must", can always be somewhat ambiguous.  But "must"
> generally implies some sort of enforcement or negative consequences if not
> respected.

"MUST" here means it's prohibited to send a negative value.
That doesn't mean that if you do you'll get caught, nor how you'll get caught.

>> So I see no bug here.  If you want a change, please say which and why.
> A negative arg is supported by the code; it is used by Emacs source
> code; and it is useful.  Knowing about it will mean simpler code by
> users.  Please document (and support) it.  Thx.

That is a much better bug-report, thank you.


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10507; Package emacs. (Thu, 26 Jan 2012 15:50:02 GMT) Full text and rfc822 format available.

Message #17 received at 10507 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 10507 <at> debbugs.gnu.org, 'Stefan Monnier' <monnier <at> iro.umontreal.ca>
Subject: Re: bug#10507: 24.0.92; Doc of `search-forward' (and backward)
Date: Thu, 26 Jan 2012 23:48:41 +0800
"Drew Adams" <drew.adams <at> oracle.com> writes:

> A negative arg is supported by the code; it is used by Emacs source
> code; and it is useful.  Knowing about it will mean simpler code by
> users.  Please document (and support) it.  Thx.

Fixed, thanks.




bug closed, send any further explanations to 10507 <at> debbugs.gnu.org and "Drew Adams" <drew.adams <at> oracle.com> Request was from Chong Yidong <cyd <at> gnu.org> to control <at> debbugs.gnu.org. (Thu, 26 Jan 2012 15:50:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 24 Feb 2012 12:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 12 years and 89 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.