Today I saw this for the first time in a pull request diff in AWS. The line is green and with a plus, so it is added. But the text is red and with slightly red background. The file is a SpecFlow (*.feature) file.
Does it signify spell-checker, or something else?
I have never used SpecFlow or AWS CodeCommit, but a little bit of experimentation (for lack of thorough available documentation) strongly suggests that AndrewF's suspicion is correct:
Syntax highlighting rules highlight invalid statements for a SpecFlow feature file (example found on toolsqa.com) are highlighted with red background. On the left, the same rule seems to cause the grey background for removed invalid statements.
The highlighting rules seem to support And clauses, just not in the Then part of a scenario, although the language grammar seems to allow this. I blame a bad syntax highlighting rule.
However, I have a hard time finding a formal grammar specification for Cuccumber/Gherkin that would tell me exactly what is and isn't allowed where (and what a compliant parser would make of it).
Edit
Why didn't I think of checking the source view first? Looking at the HTML/CSS rules of the above diff, one can see the markup in black and white: Red background equals <span class="err">. The same applies to the grey Foo on the left side of the diff.
Related
Prettier (VSCode) does a great job beautifying my code on save.
There is one feature that I consider important in code formatting which I can't find in Prettier.
I want to align chars =, :, =>, etc., in multiple lines like this VSCode plugin does.
The universal answer to questions like "How can I make Prettier format my code in such a way that ...?" is "You can't."
Prettier's purpose is to facilitate collaboration in projects and teams by taking care of code style, not to be a customizable code formatter that does whatever the user wants. In other words, the formatting it produces isn't really customizable, and this is intentional. Read more here. If you need that degree of control over formatting, you're likely not the target audience for Prettier.
This specific code style (alignment) that you want to have is considered diff-unfriendly (e.g., see here or here). Prettier's line breaking algorithm by itself has similar problems (e.g, adding one argument to a call might lead to a multiline diff if the line becomes too long), but they're inevitable, so Prettier's strategy is to compensate for that by avoiding other diff-unfriendly things.
You could always utilise the Alt key or Code Maid to clean up.
If you hold the Alt Key and drag down then you can highlight the spacing to either remove or align your code.
This is really a two part question, but they are in the same vein, so I will ask in one post.
When I flip through various colors, I see that they also have the ability to change the color of the Output window. Which VS Code setting can I use to change the color of this output? To be specific, I am not asking about the terminal, I am inquiring about the output window that displays the output when using coderunner as an example. Please refer to the screenshot to see which window I am referring to.
Second question is I can see that the output does support multiple colors. I am trying to use the module cpprint from the python lib prettyprinter to print colored output to this window. When I run the script in a terminal, I am getting colors, but in the output window, I am not getting any colors. Will it be possible for me to get similar colored output in the output window as in the terminal? I am assuming the output window supports colors because the [Running]... and end are in colors.
The Python lib I was referring to
Thanks!
So, for long while now, we have had to resort to an IBM developed extension named Output Colorizer, however, this extension clashed with other extensions, and cuased an array of bugs/issues. I personally had to disable it because it was causing text to not print at all in my output window.
We now have a much more robust, built-in solution, and it doesn't require doing anything.
Visual Studio Code added syntax-highlighting support to the "Output Channel" as part of a Milestone that it had been working on, in its March 2022 Release.
The syntax highlighting is configured by a specified languages grammar.
The language grammar that is used will vary, depending on which output channel you use. The person who decided on the language syntax highlighting used for any given output-channel is the person who authored the extension that the output-channel belongs too.
Here is the link to the official release note
Because the output highlights syntax on a language basis, configuring what colors the new feature uses to color any given text, is done the same way you color syntax.
In Depth Explanation:
If numbers are set by your theme to render green (#00FF00), then, then numbers that are printed in the Output View Panel will also be green.
If the language defined constants true & false render as a pastel-red (#FF7799) when you are writing TypeScript, but when you have a Java file open, they render as a bright pastel-yellow-green (#BBEE88), then the way they render will be contingent on whether or not the output window was set to Java or TypeScript. Obviously an output window for an extension that's a tool for Java, will most likely highlight syntax as Java. A typescript-tool extension will likely highlight all syntax as if it were typescript.
Some People Might Prefer that the Feature be more Customizable
Some people might want a more customizable feature, but I think it would be a mistake, even if it were possible, to highlight the syntax in the output differently from the editor. In fact, thinking about it, it would be stupid to have done that. It makes perfect sense that it is the way it is.
Anyways, that is the end of the Color in the Output Channel, or at-least for now.
Github supports syntax highlight as follows:
```javascript
let message = 'hello world!'
```
And it supports diff as follows: (but WITHOUT syntax highlight)
```diff
-let message = 'hello world!'
+let message = 'hello stackoverflow!'
```
How can I get both 'syntax hightlight' AND 'diff' ?
No, this is not a supported feature at this time.
GitHub documents their processing of lightweight markup languages (including Markdown, among others) in github/markup. Note step 3:
Syntax highlighting is performed on code blocks. See github/linguist for more information about syntax highlighting.
If we follow that link, we find a list of grammars that Linguist uses to provide syntax highlighting on GitHub. Linguist can only apply one of the grammars in that list to a block of code at a time. Of course, one of the grammars is Diff. However, that grammar knows nothing about the language of code being diffed, so you don't get syntax highlighting of that.
Of course, there are other languages which are often combined. For example, HTML is often included in a templating language. Therefore, in addition to the HTML grammar, we also find grammars for HTML+Django, HTML+ECR HTML+EEX, HTML+ERB, and HTML+PHP. In each case, the single grammar is aware of two languages. Both the specific templating language and the HTML which is interspersed within the template.
To accomplish the same thing with a diff, you would need a separate "diff" grammar for every single language listed. In other words, the number of grammars would double. Of course, a way to avoid this might be to treat diff differently. When diff is specified, they could run the block through the syntax highlighter twice, once for diff and once for the source language. However, at least when processing code blocks in lightweight markup languages, they have not implemented such a feature.
And if they ever were to implement such a feature in the future, it would likely be more complicated that simply running the code block through twice. After all, every line of the diff has diff specific content which would confuse the other language grammar. Therefore, every grammar would need to be diff aware, or each line would need to be fed to the grammar separately with the diff parts removed. The problem with the later is that the grammar would not have the context of each line and is more likely to get things wrong. Whether such a solution is possible is outside this cope of this answer, but the point is that it is reasonable to expect that such a feature would be much lower priority to support due to the complexity involved.
So why does GitHub do syntax highlighting in other places on its website? Because, in those cases, it has access to the two source files being diffed and it generates the diff itself. Each source is first highlighted (avoiding the complexity mentioned above), then the diff is created from the two highlighted source files. However, a diff included in a Markdown code block is already a diff when GitHub first sees it. There is no way for them to highlight the pre-diff code first. In other words, the process they currently use would not be transferable to supporting the requested feature.
You would need to post-process the output of the git diff in order to add syntax highlighting for the right language of the file being diff'ed.
But since you are asking for GitHub, that post-processing is not in your control, and is not provided by GitHub at the moment in its GFM (GitHub Flavored Markdown Spec).
It is supported for source files, in a regular diff like this one or in a PR: GitHub does the syntax highlighting of the two versions of the file, and then computes the diff.
It is not supported in a regular markdown fenced code block, where the +/- of a diff would throw off the syntax highlighting engine, considering there is no "diff" operation done here (just the writer trying to add diff +/- symbols)
I've noticed that if I use language-specific syntax highlighting on Github (e.g. Ruby)
There's a lot of space between code block and preceding text.
However, when using the plain shell syntax block, the spacing is tighter:
Just wondering if anyone has found a way to get the spacing tighter when using language-specific syntax highlighting.
For your own pages, you might try and fiddle with different css as in " jasonm23 / markdown-css-themes".
See this example page.
So I have some formatting rule to follow, such as :
Space on each side of operator (*, =, +, %, etc)
No space at the end of a line
No more than 80 chars per line
Is there a way to highlight in red line containing formating error?
The eclipse auto-formating tool is no good because either :
It will change to many line (old code not written by me)
or it won't (only my code)
Because I must follow some "colorfull" guideline :
You must change formating error relative to operators in old code but nothing else
Your code must be correctly formated.
Any ideas?
Thanks
You can select which lines of code you want to format. The Eclipse formatting tool doesn't have to run across the entire file. To do this: select the lines you want to format, then press Ctrl-Shift-F.
You could try using the Eclipse Checkstyle Plugin.
You'll need to configure it with just the rules that you need (the default configuration is very strict, so create a new one with just the rules you care about).
This will highlight all lines with formatting issues. I don't think it's possible to ignore old code using the plugin.
Talk to whoever created that coding guideline. It does not make sense in the long run, because editing code in Eclipse will always apply all current formatting rules (which violates that guideline) or none, if you disable the formatter (which leads to you writing bad code).
If there is really no way around that guideline, then you should split your workflow into 2 phases: Reformat all existing code one time to fulfill that operator guideline. You may use any tool you like, even just a regular expression search and replace might be fine.
After that has been done, configure Eclipse to auto-format only changed lines, but always apply all formattings to each changed line. There is no good reason to not re-format the other 75 characters in an existing line of code, if you already touched 5 characters of it.