Vimtex: Spurious curly brace in filename in ToC using subfiles

[gvdeynde]

I'm using a main latex file with a number of subfiles using the subfiles package (so I can easily and quickly compile the different parts when I work on them). Recently (I'm sorry, can't say since which update of vimtex) when I call up the vimtex generated ToC, there is a spurious } in the file name...

% file: MWE_sub.tex
\documentclass{article}

\usepackage{subfiles}

\begin{document}
\subfile{sub.tex}
\end{document}

% file: sub.tex
\documentclass[MWE_subfile]{subfiles}

\begin{document}

Subfiles!

\end{document}

Calling VimtexTocOpen gives this:

<Esc>/q  Close
<Space>  Jump
<Enter>  Jump and close
      r  Refresh
      h  Toggle help text
      t  Toggle sorted TODOs
    -/+  Decrease/increase ToC depth (for content layer)
    f/F  Apply/clear filter
      s  Hide numbering

Layers:  L  label+
         I  include+
         T  todo+
         C  content+

L0  Preamble
L0  tex incl: sub.tex}.tex

Note the } in the sub.tex}.tex. So pressing Space or Enter opens a blank (new) file.

I'm running Vim 8.1.2340, latest vimtex on Windows.

Any ideas?

[lervag]

I'm sorry, but I can't reproduce this. I don't have Windows, but I don't think that matters here.

Can you also provide a minimal vimrc file?

[gvdeynde]

Minimal vimfile:

set nocompatible
let &runtimepath  = 'c:\\users\\gvdeynde\\vim\\plugins\\vimtex,' . &runtimepath
let &runtimepath .= ',c:\\users\gvdeynde\\vim\plugins\\vimtex\\after'
filetype plugin indent on
syntax enable

gvim --servername VIM -u minimal.vim MWE_sub.tex

UPDATE:
In a Lubuntu virtualbox, running vim 8.1.2347 (compiled by myself), same minimal.vim (except for the rtp, of course) and latest vimtex there is no problem...

UPDATE2:
Both Windows and Linux now at vim 8.1.2352. Windows version, I get pre-compiled from vim releases (64 bit signed zip file). Linux version is from git source repository, home-compiled. The problem is only present on Windows :-(

UPDATE3:
I downloaded vim 8.1.0001 for windows. Same problem on windows. I'm quite sure that I used versions in between 8.1.0001 and 8.1.2352 without a problem in the past.

[lervag]

Thanks for the updated information! Very good to know that this is only reproducible on Windows.

I have a machine with Windows, but it is somewhat unavailable. If you happen to have some experience with coding and vimscript, perhaps you could do some "echo debugging"? All of the relevant code is located here:

https://github.com/lervag/vimtex/blob/0647bb8991a490f92de173ca67e9b49a3f1fddcd/autoload/vimtex/parser/toc.vim#L166-L192

In particular, I think you should be able to figure out something about whats wrong by adding unsilent echo l:file before line 174. The unsilent might be important, as the echoes might be silenced if not. If it still does not display anything, you can try echom and then :messages to view the message.

If you don't find anything, or if it is all confusing to you, then I should be able to look at it myself within a couple of days.

[gvdeynde]

I'm not familiar with Vimscript, but I'll try my best..

on both windows and linux:

• If I echom a:context.line, it gives \subfile{sub.tex}
• If I echom self.re, it gives \v^\s*%(\v\\%(input|include|subfile)\s*\{|\v\\%(sub)?%(import|%(input|include)from)\*?\{[^\}]*\}\{)\zs\f+

(why is the plain s at the end of the regexp? I mean inbetween \z and \f).

but echom l:file gives sub.tex on linux and sub.tex} on windows....

UPDATE
OK... This is really weird...

If I open the MWE_sub.tex file and search the file using / and then the regular expression that popped up from echom re and have highlight search on, I clearly see in Windows that the final }is included in the search result (the search result is sub.tex}, while in Linux this is not the case (the search result is only sub.tex).

[lervag]

(why is the plain s at the end of the regexp? I mean inbetween \z and \f).

Because it is not a plain s. See :help \zs. :)

If I open the MWE_sub.tex file and search the file using / and then the regular expression that popped up from echom self.re and have highlight search on, I clearly see in Windows that the final }is included in the search result (the search result is sub.tex}, while in Linux this is not the case (the search result is only sub.tex).

Interesting. I think it may have to do with the \f. See :help isfname. On Windows, it includes { and }.

Can you test if this is the issue? It should suffice to do :set isfname-={,}. I think this should fix the issue.

One question is then: how to fix this. I'm not sure if it is "OK" to ask every Windows user to add a setting. It could be better to instead change the \f to something else. However, I'd love some feedback on this, as I'm really not sure what's the best solution. (@clason @kiryph @Konfekt You guys often bring some good stuff to discussions, do any of you have experience/opinions about this?)

[clason]

@lervag I don't really have anything to add to this, but @Konfekt might -- after all, this issue goes _way_ back: https://github.com/lervag/vimtex/issues/87 https://github.com/lervag/vimtex/issues/63 ;)

[Konfekt]

I don't see any elegant solution, but:

• There could added another question to the FAQ whose response is that of vimtex-faq-isfname to set isfname-={,} on Windows, or
• Since Vim does not support Character class subtraction, the characters in \f could be on Windows
  
  
  
  • converted to a character class by a custom Vimscript function, or
  
  
  • hardcoded to the default on Windows minus { and }.
  
  

[Konfekt]

Wait, perhaps there is one: How about, non-greedy matching: instead of \f+, trying \f{-}\s*\}?

[lervag]

@clason Wow, I typically forget to search well myself. Very interesting to see that this topic was discussed so long ago!

@Konfekt Thanks for the input! You propose three options, I'll quote and address them here:

• There could added another question to the FAQ whose response is that of vimtex-faq-isfname to set isfname-={,} on Windows, or

Yes, I agree this could be done. However, I fear those who "need" to see this will miss it, and that the effect is thus that there will be new issues on the same topic.

• Since Vim does not support Character class subtraction, the characters in \f could be on Windows
  
  
  
  • converted to a character class by a custom Vimscript function, or
  
  
  • hardcoded to the default on Windows minus { and }.
  
  

It would be very nice to have character class subtraction! But as you say, we don't have that. My understanding of your thought here is to use a custom character class, at least on Windows. I.e., instead of \f, something like [...] where the contents imitate the isfname option without the {,}. I actually like this idea. It feels like it would solve the issue in a reliable manner.

Wait, perhaps there is one: How about, non-greedy matching: instead of \f+, trying \f{-}\s*\}?

I think this might also work well. The main drawback is that I'm not 100% sure if there might be an edge case that was not considered. But I can't think of one, and so I think I will try to use this as a first solution. If something unexpected happens, then I'll go for the above approach instead.

[lervag]

@gvdeynde I think the recent update should fix the issue for you. Can you please test? If you did add any set isfname-={,} then you should first remove this to reproduce the issue, then update vimtex.

[gvdeynde]

Removed the set isfname-={,} work-around, updated VimTeX.... And it worked. Thanks.

[Konfekt]

I'm not 100% sure if there might be an edge case that was not considered.

This will break down once the filename contains }. But neither will TeX parse it correctly, so I think it's fine.
(It could be worked around by something like \f{-}\s*\}\s*$as usually every \input{..} is put on its own line, but anyway the tex filename containing } is too academic a problem.)

[lervag]

the tex filename containing } is too academic a problem.

Exactly my conclusion here. :)

I think "don't aim for perfect, rather settle for good" is an OK motto. So I think I'm happy with this now, as long as it works for everyone.