Latex-workshop: Wrong column number from chktex (Tab) + character/byte skipping in actions

[ivankokan]

Hi,

Here is the interesting screenshot showing two issues:

If I got the things correctly, chktex detected a common $...$ -> \(...\) TeX vs LaTeX thing starting at 13th character but it reported column number is 21 (because of its own setting TabSize = 8). When I remove the leading tab character, this is what happens:

As you can see, codeaction suggestion is shifted by one character to the right-hand side, and clicking it does not make any change. The root cause for the misplacement is the character č in UTF8-encoded input file. Once I remove it, codeaction suggestion is placed correctly and the action successfully replaces $P(x,y)$ by \(P(x,y)\).

So, to conclude:
1) [UX suggestion] Could LaTeX-Workshop consider TabSize = 8 setting from chktex?
2) [Bug?] Is it really true that non-one-byte-characters are the root cause of the presented issue and can that be fixed?

Kind regards, Ivan

[James-Yu]

Unfortunately, it seems that neither of each can be handled from the extension side, though I will look into point 1.

[ivankokan]

Hi, thank you for the prompt reply.

I actually expected that point 2. could be handled easier than point 1. :D

If I run chktex on my console (Windows 7 cmd), I get this:

Warning 46 in zadatci\drugi-dan.tex line 11: Use \( ... \) instead of $ ... $.
Ozna─Źimo s $P(x,y)$ uvr┼ítavanje vrijednosti $x$ i $y$ u po─Źetnu jednad┼żbu. T
ada imamo
            ^^^^^^^^

So, it seems that ^^^^^^^^ are correctly aligned below the problematic content $P(x,y)$.

Based on the code I have checked, codeaction is implemented the right way assuming that position is given correctly - but it is not (because vscode itself gets the wrong information, what can be seen in the upper screenshot, underlined).

Now I am onto checking the parseLinter function, to understand the parsing algorithm... I guess it just takes the starting position of ^^^^^^^^?

Kind regards, Ivan

[ivankokan]

Okay, I think I got it. Since arguments -f%f:%l:%c:%d:%k:%n:%m\n are being used, it is the %c that returns 13 instead of 12 for the upper example, and it is chktex's problem which is agnostic to file encoding.

[James-Yu]

That seems exactly the problem. Bear in mind that most LaTeX tools are designed in the age of ASCII. CJK users are still cursed by the compilers on non-english file names. It seems hard to resolve the problem besides requesting users to use \v{a} instead of ǎ.

[ivankokan]

Let us keep track of the chktex tracker: https://savannah.nongnu.org/bugs/index.php?54750.

[ivankokan]

Consider this idea in handling point 1... Assuming that local/user settings override default chktex settings, just override them using TabSize = 1 (if editor uses tabs) or TabSize = n (if editor uses n spaces instead of a tab) - or something like that.

[ivankokan]

When it comes to "character vs byte" issue, I asked whether something can be done from vscode's side until (one day) chktex becomes Unicode-friendly: https://stackoverflow.com/questions/52878605/replacing-from-byte-to-byte-not-from-character-to-character.

[ericrbg]

I'm also running into this issue - I changed my TabSize in chktexrc to be equal to 4, and it's struggling with that, but it was also previously struggling with TabSize = 8. I'm not using any weird unicode characters, and in fact the chktex is bringing up the right column according to VSCode, see below:

[ivankokan]

@ericrbg Shouldn't TabSize = 1 be the correct setting since you are really using tabs in VSCode?

[ericrbg]

@ivankokan yes, that fixed it. still confused about why the column numbers line up with space counting... argh we make it so complicated for ourselves

[jlelong]

What is the conclusion on this? Is the issue fixed ?

[ivankokan]

There are two issues here, actually:
1) encoding

I am planning to improve chktex so it can operate on arbitrary encodings, not just ASCII. Still no progress.

Until proper solution on chktex's side is made, this plugin should interpret chktex's %c output as the number of bytes (not characters) to correctly highlight/position warnings and fix suggestions in GUI. I started to investigate on this but found nothing, see https://stackoverflow.com/questions/52878605/replacing-from-byte-to-byte-not-from-character-to-character.

2) tabs

LaTeX-Workshop should set proper TabSize setting for chktex based on whether tabs are used (= 1 should do, apparently) or n spaces are used for indentation (= n should do in this case). That would do in cases when tabs and spaces are not mixed.

On the other hand, proper way would be to always set TabSize = 1 (or any arbitrary positive integer t), and take that into account when warnings and fix suggestions are highlighted in GUI.

I would say that two needed improvements are on LaTeX-Workshop's side (bold ones), and possibly one more after something is done on chktex's side for encodings.

Anyone interested to help on this, especially on the first one; I can handle the second one.

Kind regards, Ivan

[ivankokan]

@ivankokan yes, that fixed it. still confused about why the column numbers line up with space counting... argh we make it so complicated for ourselves

@ericrbg Simply because tab character is one byte.

[ivankokan]

@ericrbg Can you please explain how/where did you set TabSize for chktex in VSCode?

[ericrbg]

I had to change chktexrc itself.

On Fri, 24 May 2019, 21:43 Ivan Kokan, [e-mail] wrote:

@ericrbg https://github.com/ericrbg Can you please explain how/where
did you set TabSize for chktex in VSCode?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/James-Yu/LaTeX-Workshop/issues/829?email_source=notifications&email_token=AJBZUU5IFSD4AVLKTPWS2MTPXBHN3A5CNFSM4FXW5IWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWGQV5A#issuecomment-495782644,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJBZUU24EWXMMH6NHOWENZTPXBHN3ANCNFSM4FXW5IWA
.