GNU bug report logs - #50731
`progress-reporter-update' docstring and `backward-sexp' interaction

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 50731 <at> debbugs.gnu.org
Subject: bug#50731: `progress-reporter-update' docstring and `backward-sexp' interaction
Date: Thu, 23 Sep 2021 10:47:41 +0300

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Thu, 23 Sep 2021 00:12:08 -0700
> Cc: 50731 <at> debbugs.gnu.org
> 
> > Once again, why does checkdoc want you to have 2 spaces there? what
> > rule is it that ends up requiring that?
> 
> Sorry, I didn't understand you were asking about checkdoc.

Because you said:

> This in turn leads to checkdoc flagging this as a mistake, and asks you
> to put two spaces after dot.

I read this as the issue you'd like to solve: to prevent checkdoc from
flagging this as a mistake.  Was I misinterpreting your report?

> The code
> there is really simple: find the next dot (that is also at a word
> boundary), run `backward-sexp', use a regexp to see if this is an
> abbreviation.
> 
> So it lands on the "r" in "reporter---i.e." and says, no, this is not an
> abbreviation I know about

Isn't _that_ a bug, right there?  Why does checkdoc use this strange
strategy for identifying abbreviations?  A punctuation character that
precedes an abbreviation shouldn't interfere with recognizing the
abbreviation, IMO.  And using sexp movements in text that is not
really a sexp is perhaps "the original sin" here?

IOW, I see no reason whatsoever to believe backward-sexp is the
problem here.  The problem is in checkdoc, and IMO should be solved
there.

Previous Next

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