With Neovintageous activated, since yesterday, when in command mode (normal mode), I cannot use Alt+ shortcuts. For example, Alt+F usually brings up the file menu, and Alt+F4 closes the program, since yesterday they no-longer work. When using these hotkeys, the current line is briefly highlighted, but that’s it.
When in insert mode, they work as usual.
I haven’t changed my configuration lately, so I wonder if an update has caused this?
The following is logged when I do Alt+F and Alt+F4:
command: _nv_feed_key {"key": "<M-f>"}
command: _nv_feed_key {"key": "<M-f4>"}Thanks. This is a bug https://github.com/NeoVintageous/NeoVintageous/issues/620
The wrong default was set for the new winaltkeys option.
The new option is to allow mapping ALT keys. You can set the winaltkeys option in your neovintageousrc file, for example:
set winaltkeys=no
It accepts three values: “yes”, “no” or “menu”.
alt+f will still invoke the menu instead of neovintageous overriding it.Thank you. This fixes it but for me it introduces another problem. I have added the following lines to the end of my .neovintageousrc:
" Mapping Alt Keys.
" It accepts three values: “yes”, “no” or “menu”.
" If “yes” (default) the alt keys are not registered by neovintageous (alt keys will default to whatever Sublime has defined by default)
" If “no”, all alt keys are registered by neovintageous (overrides any alt keys defined by Sublime)
" If “menu”, then all alt keys are registered by neovintageous except if the menu is visible then any alt keys bound to the menu will be ignored by neovintageous, for example alt+f will still invoke the menu instead of neovintageous overriding it.
" set winaltkeys=menu
This gives me the following error (even though every single line is commented):
Traceback (most recent call last):
File "C:\Users\Me\AppData\Roaming\Sublime Text 3\Installed Packages\NeoVintageous.sublime-package\plugin.py", line 190, in plugin_loaded
rc.load()
File "C:\Users\Me\AppData\Roaming\Sublime Text 3\Installed Packages\NeoVintageous.sublime-package\nv/rc.py", line 51, in load
_load()
File "C:\Users\Me\AppData\Roaming\Sublime Text 3\Installed Packages\NeoVintageous.sublime-package\nv/rc.py", line 73, in _load
for line in f:
File "./python3.3/encodings/cp1252.py", line 23, in decode
UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 1705: character maps to <undefined>
NeoVintageous: ERROR An error occurred trying to load NeoVintageous. Please restart Sublime Text.
If I simply include the following two lines, there is no error:
" Mapping Alt Keys.
set winaltkeys=menu
What’s wrong with all my commented lines that causes a problem for NeoVintageous?
The example values in the comments are wrapped in “fancy” quotes and the file is written as utf8 while neovintageous opens it with the default encoding (of your system), which apparently is cp1252. Looks like another NV bug.
When creating the file nv does:
def open(window):
file = _file_path()
if not os.path.exists(file):
with builtins.open(file, 'w') as f:
f.write('" Type :h neovintageousrc for help.\n')
window.open_file(file)
When Sublime opens the file via window.open_file() it uses whatever you have set as “default_encoding”, for example if you have 1252 encoding set as default then that is what the file will be opened as, for example:
"default_encoding": "Western (Windows 1252)",
unless… the file has been saved as utf-8 and contains characters like curly quotes, otherwise it seems Sublime can’t understand what encoding the file is.
For example, the initial neovintageousrc file contains " Type :h neovintageousrc for help.\n. Sublime opens it as 1252 if that’s your default encoding. However, if you saved the file as utf-8 with something like a curly quote (“) then Sublime will open it as utf-8 regardless of what default encoding you have set.
When opening the file nv uses:
with open(_file_path(), 'r') as f:
for line in f:
...
If the file was saved in utf-8 then it will work fine. It was saved in 1252 then it won’t.
Setting the encoding of the file to utf-8 will fix it.
I’m not sure that there’s any good workaround fix for this issue. It doesn’t seem isolated to nv.
The issue seems to occur when the file encoding is set to cp1252.
Set the encoding of the file to utf-8 and it will load fine:
I know this is probably just a workaround but I don’t know how to fully fix the issue yet.
The default encoding used for open is locale.getpreferredencoding(), not UTF-8. From the traceback above, the error was caused by the file being saved with utf-8 and then attempted to be read as ctcp1252 and then converted to unicode for Python’s internal string representation.
The fix is to read the config file (and probably all files) with encoding='utf-8'.
Although I have to admit I have no idea where this 0x9d byte comes from. It’s not a utf-8 start byte and seem to be a character in cp1252 either.
>>> b"\x9d".decode("cp1252")
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "./python3.3/encodings/cp1252.py", line 15, in decode
UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 0: character maps to <undefined>
@oldmankit1 could you upload the file that fails to be loaded in its binary form somewhere (i.e. not a pastebin site) so we could take a closer look at it?
The fix is to read the config file (and probably all files) with
encoding='utf-8'.
This doesn’t fix the issue because Sublime still opens the file in the default set by the setting:
"default_encoding": "Western (Windows 1252)",
I think that what you say should be right, in theory, but Sublime still opens the file as 1252.
It looks like Sublime tries to guess what encoding the file is but it can’t guess from a file that only contains ASCII characters, for example the default text of the file is:
" Type :h neovintageousrc for help.\n
Sublime opens it as 1252, the default that you have set. Even if you then change the encoding to utf-8, close the file, and then reopen it, it will open as 1252 (the default that you have set).
There is an exception. If you save the file with something like a curly quote and set the encoding to utf-8, then the next you open it Sublime will open it correctly as utf-8, because it can guess the encoded curly quote i.e. a character outside of ASCII (the common denominator).
I was surprised by this at first, but if a file only has ASCII characters then how can Sublime know it’s utf-8? It can’t, so it opens it as whatever you have set as your default encoding. I’d expect this to impact a lot of plugins dealing with files, but only if you add characters like curly quotes, which is why you don’t see too many issues.
That is correct, but the default setting is "default_encoding": "UTF-8", (as it should), so a user would have to modify this explicitly in order for that case to occur.
There are workarounds to opening text files with unknown encoding, that I’m not going to go into too much, but chardet is a thing and a cheap solution is to try reading as utf-8 and then with locale.getpreferredencoding() if a UnicodeDecodeError occurs.
Fortunately that doesn’t matter for this use case.
hat is correct, but the default setting is
"default_encoding": "UTF-8",(as it should), so a user would have to modify this explicitly in order for that case to occur.
I’m assuming @oldmankit1 has his default encoding set to 1252?
Or has in some other way saved the file in the 1252 encoding.
There are workarounds to opening text files with unknown encoding, that I’m not going to go into too much, but chardet is a thing and a cheap solution is to try reading as utf-8 and then with
locale.getpreferredencoding()if aUnicodeDecodeError
I think this will work for most edge cases, though it’s not bullet proof and bit messy. I’ve been looking through sources like Package Control to see how it’s handled and I don’t see workarounds like this.
But we don’t actually know this is the case. As I showed, 0x9d isn’t a byte that’s used in cp1252 and my entire point so far was that the file is being written as utf-8 but read as cp1252.
>>> " It accepts three values: “yes”, “no” or “menu”.".encode('utf-8').decode("cp1252")
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "./python3.3/encodings/cp1252.py", line 15, in decode
UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 34: character maps to <undefined>
Sorry for the slow reply! If I enter in the console view.encoding() I see 'UTF-8'.
I’ve uploaded the file directly to a server so you can check it.
And removing the curly quotes fixed the problem for me, so thank you for that.
It looks like somehow the file got encoded as Windows-1252 or is otherwise corrupted.
I suggest removing the file and creating one fresh by the Open My RC File command palette command. When you create it, watch the status line to make sure the file opens as utf-8:
and not as windows-1252:
As I showed,
0x9disn’t a byte that’s used in cp1252 and my entire point so far was that the file is being written as utf-8 but read as cp1252 .
The 0x9d byte is unused except in the Windows API MultiByteToWideChar 
Windows.
According to the information on Microsoft’s and the Unicode Consortium’s websites, positions 81, 8D, 8F, 90, and 9D are unused; however, the Windows API
MultiByteToWideCharmaps these to the corresponding C1 control codes. The “best fit” mapping documents this behavior, too.[5] – https://en.wikipedia.org/wiki/Windows-1252
It’s utf-8 for me and ST opens it as such as well.
λ wget https://withkit.com/misc/.neovintageousrc && file .neovintageousrc
.neovintageousrc: UTF-8 Unicode text
I’m not sure how else I can get my point across.
Sorry if I’m not understanding.
I’ve been able to reproduce an issue by setting my default encoding to windows-1252, then creating a fresh rc file which opens as windows-1252.
Then when I paste a curly quote into the file and reload it I get the error, because I think nv is trying to load the windows-1252 encoded file as utf-8.
I think I understand your point that this still shouldn’t cause an error, because for example it’s only the closing curly quote causing the error, the 9D position, which is not in windows-1252, however it’s part of the Windows API MultiByteToWideChar… but I’ll be honest that’s a rabbit hole I don’t want to go down.
1.17.2 should fix the issues.
@FichteFoll You’re right about the locale.getpreferredencoding() api, on windows it will default to windows-1252 so nv opens the utf-8 encoded file as windows-1252 which chokes when reloading the rc. I should have tested on Windows system from the beginning. Sorry Fitch.