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
Console lexer cannot detect virtual environment names #1253
Comments
Some more info: There is already a Some recommendations (e.g., Google's developer docs) say to not include the user or directory unless it's necessary. If users of Pygments follow those recommendations, no change is needed as something like Some possible solutions:
|
It does make sense to handle virtualenv better, but I'd like to understand what the result should be. Do you want the virtualenv part to be highlighted, or just make sure it's ignored properly? |
Actually I'm ambivalent about whether it's (a) parsed as part of the prompt, (b) parsed and given a second class (e.g., so it could be styled differently), or (c) ignored properly. Currently it breaks the regex match, so the whole prompt fails to be colored as expected. |
Right, but it's easy to fix to ignore it (and make the prompt highlight correctly). If it should get some different class (and that is what I'm gravitating towards), then I need to figure out what class to use. Not to mention that various git integrations also mess with the console and add extra output (like |
Sorry, I have insufficient knowledge of the classes to form an opinion of which to use, but in terms of Token types it seems like it would call for a subtype of |
This is reported as issue #1253. This fix does not work yet -- the parsing does not resume with the correct parser yet.
Looking at this, it's not quite clear how this is supposed to be added. @birkenfeld : I've tried to get a |
The default virtualenv prompt contains a single space after the name of the virtualenv in parentheses. Commit 3f40368 which resolved pygments#1253 assigns the "Text" class to any whitespace between the virtualenv name and the rest of the prompt, but this is problematic, because it makes the space selectable, and doesn't include it in the prompt. Fix this by assigning the Generic.Prompt class to the space between the name of the virtualenv and the rest of the prompt, instead of Text. Also update the test accordingly. Signed-off-by: Vangelis Koukis <evangelos.koukis@hpe.com>
The default virtualenv prompt contains a single space after the name of the virtualenv in parentheses. Commit 3f40368 which resolved pygments#1253 assigns the "Text" class to any whitespace between the virtualenv name and the rest of the prompt, but this is problematic, because it makes the space selectable, and doesn't include it in the prompt. Fix this by assigning the Generic.Prompt class to the space between the name of the virtualenv and the rest of the prompt, instead of Text. Also update the test accordingly. Signed-off-by: Vangelis Koukis <evangelos.koukis@hpe.com>
The default virtualenv prompt contains a single space after the name of the virtualenv in parentheses. Commit 3f40368 which resolved pygments#1253 assigns the "Text" class to any whitespace between the virtualenv name and the rest of the prompt, but this is problematic, because it makes the space selectable, and doesn't include it in the prompt. Fix this by assigning the Generic.Prompt class to the space between the name of the virtualenv and the rest of the prompt, instead of Text. Also update the test accordingly. Closes pygments#2496 Signed-off-by: Vangelis Koukis <evangelos.koukis@hpe.com>
When a Python virtual environment is activated, by default it puts the virtual environment's name to the left of the prompt in a shell session. E.g.:
This causes Pygments to fail to detect the prompt in the
console
/shell-session
lexer. Compare:Without the virtual environment:
With the virtual environment:
Note that it is detected if there is nothing after the environment name or possibly a user@host:dir without brackets:
Context:
Some software I develop is documented with Sphinx. Since I encourage users of my software to use virtual environments, I would like to illustrate their use in my documentation, but the lexer fails to parse my examples if I use the virtual environment names. I think this is just a matter of accounting for an optional virtual environment name in BashSessionLexer._ps1rgx, but there may be complexities I'm not considering.
The text was updated successfully, but these errors were encountered: