Github highlights the second % in this line as an error:
fscanf(fp, "%d%*[^\n]\n", &ints[i]);
However, the code compiles perfectly and the removing the 'error' will cause the program to function incorrectly.
Is there any way to either disable this error highlighting or make Github recognize it as correct?
Update: pchaigno points out in the comments the section linguist#Overrides, where you can use for instance .gitattributes:
Add a .gitattributes file to your project and use standard git-style path matchers for the files you want to override to set linguist-documentation, linguist-language, linguist-vendored, and linguist-generated. .gitattributes will be used to determine language statistics and will be used to syntax highlight files. You can also manually set syntax highlighting using Vim or Emacs modelines.
$ cat .gitattributes
*.rb linguist-language=Java
Original Answer Jan. 2017
Since you cannot easily remove the GitHub highlight, you can try and use a similar workaround I suggested in "How to fix/ignore syntax error in github"
Try and add on the same line a comment with a '%' in it, in order for the lexer (used by the syntax highlighting engine Rouge and Pygment) to not propagate the "error" to all subsequent lines.
To complete VonC's answer, if you think the highlighting is incorrect, you can actually file a bug report or even fix it; All grammars github.com uses are open source!
How to find the grammar? To find the grammar used for syntax highlighting in your case, you can visit this page on the Linguist project. In front of each language (looks like C in your case), you'll find the repository where the grammar for that language lives (for C, github.com/textmate/c.tmbundle). You can open an issue there with your failing test case, or even better, try and fix it yourself.
Related
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)
When I click an imported variable while holding Cmd on MacOS in VSCode (or Ctrl on other platforms), I often end up looking at the TypeScript declaration of that variable.
Is there any way to have VSCode take me to the definition of it instead?
I don't use TypeScript myself, so the feature isn't helpful to me right now.
Try Go to source definition
This command will try to jump to the original JavaScript implementation of a function/symbol, even for code under node_modules.
JavaScript is a very dynamic language though, so we can't figure out the source location in every case. If you aren't getting results for a common library, please file an issue against TypeScript so we can investigate adding support
For faster and more accurate results, libraries can bundle declaration maps that map from .d.ts files back to source .ts (or .js) files. However many libraries currently do not include these
I found a simple solution for this after a lot of searching.
You just need to add "typescript.disableAutomaticTypeAcquisition": true to your project's settings.json (or vscode's global settings).
This will disable the automatic generation of TypeScript definitions and restore the original "Jump to" behaviour of going to the implementation.
Source:
https://ianwalter.dev/jump-to-source-definition-instead-of-typescript-definition-in-vs-code (archive.org link)
The author provided the wrong instructions though (false when it should have been true so be careful when you read the post. Re-installing node modules was also not needed.
VSCode was updated to include a new option Go to Source Definition. If the ts source is available and ts is upgraded to > 4.7 and VSCode to > 1.67 it should work.
Many library authors do not include the ts source code unfortunately. The package often only consists of the compiled *.js files and the *.d.ts definition files. That makes this new feature of VSCode useless for these packages unfortunately.
This is the original issue:
https://github.com/microsoft/TypeScript/issues/6209
And this is an issue for feedback on the new feature.
https://github.com/microsoft/TypeScript/issues/49003
Implementation is bundled and transpiled ro javascript and vscode is not able to take you there but instead of it will take you to interface. You can search for references in javascript file or you can clone or form the repo to see the implementation in typescript.
As other answers have already stated,
Regardless of any of your tsconfig and whether the package you are requiring/importing things from provides type declaration files or whether you installed a Definitely Typed package for it or not, you can use the TypeScript: Go to Source Definition command to go to the symbol definition in the JS file. This functionality is provided TypeScript and the vscode.typescript-language-features extension (which is built-into / ships out-of-box with VS Code).
I thought I'd try to give more interesting information that other answers haven't covered yet for fun and profit curiosity's sake (and also explain why this "often" happens to you, but not always):
You can bind that command to a keybinding. It's keybinding command ID is typescript.goToSourceDefinition.
If the package you require or import packages its own type declaration files or you installed a community-maintained type declaration file from the Definitely Typed project, then ctrl+clicking / cmd+clicking into the require/import argument or putting the caret on it and invoking whatever the editor.action.revealDefinition command or editor.action.goToTypeDefinition are bound to (F12 by default for editor.action.revealDefinition) will take you to the type declaration by default.
If the package you require or import doesn't package its own type declarations and you didn't install a types package from the Definitely Typed project, and you modify your tsconfig or jsconfig to set allowJs: true and maxNodeModuleJsDepth: <N>, then ctrl+clicking / cmd+clicking into the require/import argument or putting the caret on it and invoking whatever the editor.action.revealDefinition command or editor.action.goToTypeDefinition command are bound to (F12 by default for editor.action.revealDefinition) will take you to the symbol's definition in the JS file by default (unless you already performed this action at a point when a type declaration file declaration types for symbol was available and have not since reloaded/restarted VS Code or edited your tsconfig/jsconfig file, because it will cache that association in memory (smells like minor bug, but ¯\_( ツ )_/¯)).
The editor.action.revealDeclaration keybinding seems to do nothing here (at the time of this writing). I guess that keybinding is more for languages like C and C++.
Some loosely related release notes sections and user docs (non-exhaustive list (I don't get paid to do this)):
https://code.visualstudio.com/docs/editor/editingevolved#_go-to-definition
https://code.visualstudio.com/updates/v1_13#_go-to-implementation-and-go-to-type-definition-added-to-the-go-menu
https://code.visualstudio.com/updates/v1_35#_go-to-definition-improvements
https://code.visualstudio.com/updates/v1_67#_typescript-47-support
In TypeScript's GitHub repo: Go To Source Definition feedback thread #49003
https://code.visualstudio.com/updates/v1_68#_go-to-source-definition
Quoting from that last one:
One of VS Code's longest standing and most upvoted feature requests is to make VS Code navigate to the JavaScript implementation of functions and symbols from external libraries. Currently, Go to Definition jumps to the type definition file (the .d.ts file) that defines the types for the target function or symbol. This is useful if you need to inspect the types or the documentation for these symbols but hides the actual implementation of the code. The current behavior also confuses many JavaScript users who may not understand the TypeScript type from the .d.ts.
While changing Go to Definition to navigate to the JavaScript implementation of a symbol may sound simple, there's a reason why this feature request has been open for so long. JavaScript (and especially the compiled JavaScript shipped by many libraries) is much more difficult to analyze than a .d.ts. Trying to analyze all the JavaScript code under node_modules would be both slow and would also dramatically increase memory usage. There are also many JavaScript patterns that the VS Code IntelliSense engine is not able to understand.
That's where the new Go to Source Definition command comes in. When you run this command from either the editor context menu or from the Command Palette, TypeScript will attempt to track down the JavaScript implementation of the symbol and navigate to it. This may take a few seconds and we may not always get the correct result, but it should be useful in many cases.
See also: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-7.html#go-to-source-definition.
I have a GitHub repo with multiple C source files. (I won't share a link unless absolutely necessary so that I can't be accused of advertising.) Every instance of the % character in the C files is highlighted red:
Am I missing something about % in C, is this a bug, or is it intentional?
GitHub uses linguist for detecting languages, and some highlighting issues can be found there (even if it does not directly concern the language detection module)
See issue 2839 which does mention
We use open source TextMate-style language grammars for syntax highlighting, which are available here:
https://github.com/github/linguist/blob/master/grammars.yml
Linguist pulls in grammar updates with each new release, which usually happens every couple of weeks.
For C, is is textmate/c.tmbundle, which had a percent-related highlighting issue before (issue 28): you might have to open a new issue there.
I found this discussion has a plausible explanation. Here I quote:
It's highlighting the % because it's assuming that you're making a printf format string, and that you've made it wrong. Unfortunately there's no way to tell it it's not a printf format string short of changing the syntax file.
I'm using the Brackets code editor to code in C++ and I'm having a hard time having the shortcut for lineComment and blockComment working...
The shortcuts are [Ctrl+/] and [Ctrl+Shift+/], they work perfectly for CSS, JS.. etc but not with C++ files.
I looked into the clike.js file in the CodeMirror folder of Brackets, the blockCommentStart, blockCommentEnd and lineComment are correctly defined.
Is it a known issue? has anyone found a workaround?
Before that,I was coding with Notepad++ and this feature was the one I used the most. It's really hard not to have it anymore
You said you saw that blockCommentStart, blockCommentEnd and lineComment are correctly defined in clike.js. From CodeMirror documentation
This file defines, in the simplest case, a lexer (tokenizer) for your
language—a function that takes a character stream as input, advances
it past a token, and returns a style for that token. More advanced
modes can also handle indentation for the language.
It is used to highlight the c++ file. But also it could be used to auto comment line with shortcut. However it is probably not implemented for C++. For this feature comment addon from CodeMirror might be used http://codemirror.net/addon/comment/comment.js since The addon also defines a toggleComment command, which will try to uncomment the current selection, and if that fails, line-comments it.
This was a Brackets bug, but it was fixed in the Sprint 39 release.
(Fwiw though, language metadata in Brackets is defined in a file called languages.json - although Brackets extensions can add to / modify this metadata as well).
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.