bugLaTeX semantic checker - Bugs: bug #53347, Wrong interword spacing (W 12) not...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #53347: Wrong interword spacing (W 12) not detected

Submitter:  Ivan Andrus <gvol>
Submitted:  Thu 15 Mar 2018 04:18:41 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  gvol
Open/Closed:  Closed

Fri 30 Sep 2022 04:20:07 AM UTC, comment #4: 

I have what I believe is a reasonable fix for this (and for https://savannah.nongnu.org/bugs/?54751).  I have updated the regex to "([^A-Z@.])\.[.!?:]*\s[ \`([]*[a-z]" which I think accounts for most cases that we care about.  Let me know if you think there are any other character we should skip past.

I'm hoping to make a release soon, after which it will have to propagate out to the distributions.

Ivan Andrus <gvol>
Group administrator
Fri 28 Dec 2018 09:12:27 PM UTC, comment #3: 

I've been now testing this:


UserWarnRegex {
        # Also warn about `foo. \enquote{bar}'
        (?!#Interword! spacing! `\! '! should! perhaps! be! used)([^A-Z@.])\.[.! ?:]*\s+\\
}


quite a while successfully it introduced pretty much no false-positives for me

Leonard König <larkey>
Fri 16 Mar 2018 01:12:30 PM UTC, comment #2: 

Hi, I didn't knew a bugtracker existed and simply looked at the ChkTeX documentation for a contact.

A few false positives would be okay, I will test an adjusted regex in the next days, although I think the number of false positives won't be that bad.

Leonard König <larkey>
Thu 15 Mar 2018 04:41:42 AM UTC, comment #1: 

Thanks for the bug report Leonard.  I have taken the liberty of creating a bug: https://savannah.nongnu.org/bugs/index.php?53347 so that it won't get lost.

I'm going to have to think about this some.  If you look at FindErrs.c line 1477, you see the regular expression that is being used to catch the generic case, namely

    ([^A-Z@.])\.[.!?:]*\s+[a-z]

As you can see it just searches for a lowercase letter following an abbreviation (unless the last letter of the abbreviation is a capital).  It would be pretty easy to just say that any command requires interword spacing (basically just adding \ to the final portion of the regex.  But I am a little worried that it will introduce some false positives unless I create a list of  LaTeX commands which don't need interword spacing (e.g. \par). But adding that would be a little more work.  Personally, I don't mind false positives if they don't happen too often, but I don't like introducing them if I can avoid it.

Let me know if you have any further thoughts, otherwise I'll get around to it after I've thought about it for a while.

I guess in the mean time you could add a UserWarnRegex with the updated regular expression and see how it works out.

Ivan Andrus <gvol>
Group administrator
Thu 15 Mar 2018 04:18:41 AM UTC, original submission:  

I've just noticed a case where ChkTeX doesn't properly notice that an
abbreviation is encountered:


\documentclass{article}
\usepackage{csquotes}


\begin{document}
This will be detected: Hello etc. now continued.\\
This won't be: Hello etc. \enquote{now continued}.
\end{document}



I guess the command `enquote` does confuse the parser and the actual
result, is not considered when checking for a continued sentence.

So I'd propose two things (but sadly lacking the ability to implement
them, at least currently):

1. In general, assume a command as not introducing a new sentence since
this is unlikely and better warn once too often.
2. For some known commands like `enquote`, parse the argument as a
continuation of the sentence and decide based on this, whether there
should be interword spacing.

What do you think?


Cheers,

Leonard

Ivan Andrus <gvol>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by larkey (Posted a comment)
  • -email is unavailable- added by gvol (Submitted the item)
  • -email is unavailable- added by gvol
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-09-30 gvol StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2018-11-27 gvol StatusNone Confirmed
        Assigned toNone gvol
    2018-03-15 gvol Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code