# LaTeX 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

 Submitted by: Ivan Andrus Submitted on: Thu 15 Mar 2018 04:18:41 AM UTC Category: None Severity: 3 - Normal Item Group: None Status: Confirmed Privacy: Public Assigned to: Ivan Andrus Open/Closed: Open

## Discussion

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>
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>

## Attached Files

No files currently attached

## Dependencies

Depends on the following items: None found

Items that depend on this one: None found

## Mail Notification Carbon-Copy List

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
•

Do you think this task is very important?
If so, you can add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

## History

Follow 3 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2018-11-27 gvol StatusNone Confirmed
Assigned toNone gvol
2018-03-15 gvol Carbon-Copy- Added leonard.r.koenig@gmail.com