New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vroom should be LANG-insensitive #25
Comments
Err… Pretty sure we shouldn't be en_US-centric, or LANG-dependent at all if we don't have to be, even if in practice most vroom files will be LANG-dependent. We'll have to see if it's such a lost cause that we should resort to LANG=C everywhere. This specific issue should be a simple matter of changing it to a regex (assuming it's always |
It's not that simple, sadly.
In the specific case of the maintainer messages, I agree with you: we probably should be checking messages at startup (which might help in fixing #13 too). There are at least two other cases where this shows up, though:
I'm happy to morph this into "Vroom shouldn't be sensitive to LANG" if you think that's the right thing to do. |
I was afraid of that. Still, I think we should try to knock out any specific cases of LANG-sensitivity we can find, even if we end up stuck on some major issue that forces us into LANG-sensitivity. (Folks will be keep having to troubleshoot why vim has different behavior from vroom otherwise.) I'd say go ahead and morph this issue accordingly, and if we get stuck we'll take it in stride. As far as the "E449: Invalid expression received" message, we have an explicit guideline to avoid messages and only match on error codes for that purpose. That's my fault for hard-coding the E449 message. |
Another instance: when we check for a valid DISPLAY, we test the text returned to see if it's exactly
I think that here (in |
Hmm, actually, I think the best thing to do for the above ( |
Force the vim client process to execute with LC_ALL and LANGUAGE set to en_US.UTF-8, which ensures that the "No display" message returned by the client can be recognised directly. References google#25.
This allows us to recognise this error even when LANG is set to something other that en_US or en_GB. References google#25.
I've broken the "can't handle non-ASCII output" case into #28, leaving this to cover:
|
While attempting to reproduce #13, I noticed that the message output I'm getting on failure is different to what was quoted. Instead of e.g.
I'm getting
It turns out this is because I'm running with
LANG=en_GB.UTF-8
, which changes at least the maintainer (which is hardcoded invroom/messages.py
). Running asLANG=en_US vroom ...
DTRT.Should vroom be setting
LANG=en_US
(orLANG=C
?) before running vim? It's not entirely clear to me whether hardcoding this would be unnecessarily restrictive, or whether it affects anything else.Alternatively, we could conceivably work out what the "Messages maintainer" message looked like ourselves, perhaps by running vim and dumping the messages with no input (or could we just do that as the first thing unconditionally?).
The text was updated successfully, but these errors were encountered: