GNU bug report logs - #15120
24.3.50; (elisp) `Search-based Fontification': unspecified MATCHER cases

Previous Next

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

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

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.3.50; (elisp) `Search-based Fontification': unspecified MATCHER
 cases
Date: Sat, 17 Aug 2013 10:33:13 -0700 (PDT)

The doc string is good in this regard, but the Elisp manual is not.

The manual says that an element can be FUNCTION.  OK.

And it says, for (MATCHER . SUBEXP), that MATCHER can be a function.  OK.

But it does not say that for all of the other (MATCHER . *) patterns
MATCHER can also be a function.  In fact, for the others MATCHER is left
unspecified.

And for (MATCHER . SUBEXP-HIGHLIGHTER) the doc actually refers to a
"SUBEXP in MATCHER", which suggests, but does not specify, that MATCHER
in this case can be or perhaps even *must be* a REGEXP.

Follow the example of the doc string, or state somewhere that MATCHER,
in all that follows, can be either a regexp or a function...

IOW, make clear just what MATCHER can be, in general or in each of the
cases.



In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-08-07 on ODIEONE
Bzr revision: 113750 lekktu <at> gmail.com-20130808011911-0jzpc9xuncegg6x9
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 CFLAGS=-O0 -g3 LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15120 <at> debbugs.gnu.org
Subject: Re: bug#15120: 24.3.50;
 (elisp) `Search-based Fontification': unspecified MATCHER cases
Date: Fri, 07 Feb 2014 21:06:09 -0800

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

> The doc string is good in this regard, but the Elisp manual is not.
>
> The manual says that an element can be FUNCTION.  OK.
>
> And it says, for (MATCHER . SUBEXP), that MATCHER can be a function.  OK.
>
> But it does not say that for all of the other (MATCHER . *) patterns
> MATCHER can also be a function.  In fact, for the others MATCHER is left
> unspecified.
>
> And for (MATCHER . SUBEXP-HIGHLIGHTER) the doc actually refers to a
> "SUBEXP in MATCHER", which suggests, but does not specify, that MATCHER
> in this case can be or perhaps even *must be* a REGEXP.
>
> Follow the example of the doc string, or state somewhere that MATCHER,
> in all that follows, can be either a regexp or a function...
>
> IOW, make clear just what MATCHER can be, in general or in each of the
> cases.

I see what you mean, but if you read the page from the start to finish,
you see that it explains what all meta-syntactical are once.  It says
what MATCHER is the first time it talks about it, and then it just
describes what each new element is.  So I think the page is OK as is.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 15120 <at> debbugs.gnu.org
Subject: RE: bug#15120: 24.3.50; (elisp) `Search-based Fontification':
 unspecified MATCHER cases
Date: Sun, 9 Feb 2014 16:02:56 -0800 (PST)

> > The doc string is good in this regard, but the Elisp manual is
> > not.
> >
> > The manual says that an element can be FUNCTION.  OK.
> >
> > And it says, for (MATCHER . SUBEXP), that MATCHER can be a
> > function.  OK.
> >
> > But it does not say that for all of the other (MATCHER . *)
> > patterns MATCHER can also be a function.  In fact, for the others
> > MATCHER is left unspecified.
> >
> > And for (MATCHER . SUBEXP-HIGHLIGHTER) the doc actually refers to
> > a "SUBEXP in MATCHER", which suggests, but does not specify, that
> > MATCHER in this case can be or perhaps even *must be* a REGEXP.
> >
> > Follow the example of the doc string, or state somewhere that
> > MATCHER, in all that follows, can be either a regexp or a function...
> >
> > IOW, make clear just what MATCHER can be, in general or in each of
> > the cases.
> 
> I see what you mean, 

No, I don't think you do.

> but if you read the page from the start to finish,

I certainly did that.  Did you?

> you see that it explains what all meta-syntactical are once.

Not at all.

> It says what MATCHER is the first time it talks about it, and then it
> just describes what each new element is.  So I think the page is OK as
> is.

You are just not reading.

What it says, at the place where you apparently think that it
introduces MATCHER for the entire page, is this:

  "In this kind of element, MATCHER is..."
   ^^^^^^^^^^^^^^^^^^^^^^^

IN THIS KIND OF ELEMENT!  Why on Earth does it say that?

It is specifying what MATCHER means in the form `(MATCHER . SUBEXP)',
where SUBEXP must be...  And by taking the pains to specify
explicitly that this applies to this kind of element, the
suggestion is that it does NOT necessarily apply to the other
kinds of element shown on the page.  Otherwise, why say that?

That's the point: each of these kinds of "element" is specified
separately, and it says so explicitly.  If you want to make the
current description of MATCHER apply to the whole page, then it
needs to be introduced at the outset as applying to the whole page.

And the text certainly should NOT then say that the description
applies to some particular kind of element.  IOW, remove that
"In this kind of element...", as well.

Again, please _read_ the bug report.  Among other things, it says
that the doc string gets it right.  Use it, if it helps, as your
inspiration for actually _fixing_ this bug.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15120 <at> debbugs.gnu.org
Subject: Re: bug#15120: 24.3.50;
 (elisp) `Search-based Fontification': unspecified MATCHER cases
Date: Mon, 10 Feb 2014 00:03:06 -0800

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

> You are just not reading.
>
> What it says, at the place where you apparently think that it
> introduces MATCHER for the entire page, is this:
>
>   "In this kind of element, MATCHER is..."
>    ^^^^^^^^^^^^^^^^^^^^^^^
>
> IN THIS KIND OF ELEMENT!  Why on Earth does it say that?
>
> It is specifying what MATCHER means in the form `(MATCHER . SUBEXP)',
> where SUBEXP must be...  And by taking the pains to specify
> explicitly that this applies to this kind of element, the
> suggestion is that it does NOT necessarily apply to the other
> kinds of element shown on the page.  Otherwise, why say that?

And in the next paragraphs it doesn't define MATCHER, because, well,
it's the same.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Previous Next

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