-
-
Notifications
You must be signed in to change notification settings - Fork 446
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
flycheck’s tooltips can be displayed sdrawkcab when the source contains bidi directional formatting characters #1919
Comments
That's a funny one, thanks! |
I want to make a pull request for this, but Do you have any recommendations for that? The format string is 103 characters, and using hex codes instead of character names would be less readable. And using a lot of string concatenation would allocate a lot of memory. |
Making a defconst for the format string is probably the simplest.
Does that mean that every IDE needs to wrap LSP messages in those formatting codes? |
It depends on how the client displays the message. Flycheck is putting four pieces of information into a single string and then displaying it, so it needs to be careful. However, if we put the information into four columns of an HTML table, then each cell would be shaped and printed independently; the bidi state from one could not affect the others and thus no special care would need to be taken. Even without a table, Emacs could arrange to shape the separately, calling into libharfbuzz (or the equivalent API on other OSes) several times instead of once. But then the tooltip would have to be defined by a list of lists of strings, where the strings in the inner list are shaped independently but printed on a single line.
I suppose concatenating once when the constant is defined wouldn’t hurt. |
lest bidi formatting characters cause the error message to be rendered sdrawkcab. In principle we should probably do this to the filename and even the error message, since those could be suspect as well. As ordinary RTL text doesn’t cause any problem, it is in practice not so important. Note also that if flycheck is to be localized, this format string must be localized as well (or the localization system must support such substitutions directly). Fixes flycheck#1919.
Checklist
Bug description
Source code containing bidi directional formatting characters can mess up the direction of the error message itself.
I imagine that localized error messages might cause the same problem as well, though I haven’t any easy way to check.
Steps to reproduce
Expected behavior
The text direction of the error message is not affected by the content of the source code it arose from.
Screenshots
The Fix
I will make a pull request for this, but for the moment here is the change I made to fix this:
Likely the other fields ought to have the same treatment.
System configuration
I’ve got some
lsp-mode
stuff going on as well, which isn’t reflected here.Emacs configuration:
Additional notes
https://en.wikipedia.org/wiki/Bidirectional_text
https://www.w3.org/International/questions/qa-bidi-unicode-controls
The text was updated successfully, but these errors were encountered: