3

I'm using VIM 8.1.2234 with +multi_byte and +multi_lang

In my vimrc file, I have set listchars=tab:▸\ ,trail:· (Notice the "▸" and the "·")

When I cat or less my vimrc, the text displays as [intuitively] expected. When I use vim, the options behave as [intuitively] expected. However, when I edit my vimrc, I see set listchars=tab:â<96>¸\ ,trail:·

This has not always been the case. I have not changed my VIM version but I have tweaked my vimrc a bit. I'm convinced it is a setting I tweaked but for the life of me, I cannot figure out which. I tried backing out changes, but no luck.

FWIW, I got both the "▸" and the "·" characters into my vimrc via direct keyboard entry.

I don't know if it matters, but now when I open my vimrc file, I get a [converted] flag on the status line. (My encoding is and has always been set encoding=utf-8)

Update

I ran :verbose set fileencoding? and got fileencoding=latin1 (despite my setting it to UTF-8) When I ran :verbose set fileencodings?, VIM reports fileencodings=ucs-bom,utf-8,default,latin1 I tried :e ++enc=utf8 ~/.vimrc and got [ILLEGAL BYTE in line 213] on the status line. Line 213 is defines a macro I use for massaging specific PHP arrays into a Lua tables. Once I removed this macro line -- commenting out was not enough -- my listchars definitions appeared correctly [while editing] and the [converted] status tag went away.

I examined the macro definition closely (with a hex editor, as suggested) and it confirmed that all whitespace was actually whitepsace and all "normal characters" where just that, normal. I suspect that the format of the macro is confusing VIM's parser.

It was VIM's automatic encoding change from UTF-8 to Latin1 that broke listchars. VIM, for whatever reason, gets confused by my macro definition; this is what forces VIM to change the encoding. There is no deep understanding or solution here; the issue has been cleared but the problem remains unsolved.

FWIW, here's the macro definition that [now, but didn't always] breaks VIM's parsing:

let @z = "^M^MV-%->O $data = [^[-%O▸ ];^M $persist( $data, \"\" );^[^M%-$F/ v$kby^M%-f\"p^M%^M^Mma-$%-mb'aV'b:s/{/[/g^M'aV'b:s/}/]/g^M'aV'b:s/: / => /g^M"

10
  • How about :verbose set fileencoding? when you have your vimrc open? Do you have "utf-8" listed in :verbose set fileencodings? (note it's plural here.) Does it work if you open the file with :e ++enc=utf-8 ~/.vimrc? – filbranden Jul 8 '20 at 15:47
  • 1
    That illegal byte is then probably why it's not recognizing it as UTF-8... Maybe drop that line and see what happens? Or consider using an hex editor to see which byte might be the problematic one... – filbranden Jul 8 '20 at 16:45
  • 2
    Regarding editing the question: right now a lot of the useful information (like the [converted] message and result of :set queries) is in comments only. It should be in the question, so that others reading the question and planning to write an answer could easily find all relevant information. Also for the future, when others with the same problem bump into this question after encountering a similar issue. Finding all context easily is very important! – filbranden Jul 8 '20 at 17:30
  • 1
    @Rich I think the ▸ is what his listchars is doing to a tab character... LiamF any chance you could upload the problematic file to a service that would preserve it exactly, such as a Git repository or perhaps a paste bin that you can upload using a command-line tool? Or perhaps post the xxd output for that particular line? Something like sed -n 213p problem_vimrc.txt | xxd might be able to capture that... – filbranden Jul 9 '20 at 15:50
  • 1
    @filbranden Ah, of course. I was wondering what it was doing in there. – Rich Jul 9 '20 at 16:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.