Getting github to syntax highlight my files - github

github automaticall syntax highlights any code files such as those with .c extensions. And there seems plenty of information about controlling highlighting from within 'markdown' or .md files.
But how can I get it to highlight code files that it doesn't know about?
I can't even get the tabbing right - if I say 4-spaces tabs while editing, it goes back to 8-space ones when I've finished.
I don't care what highlighting style it uses even if it's the wrong language; it must be better than the plain text appearance which looks really flat. Oddly, when editing it uses some sort of highlighting, which again disappears when I've finished.
The files aren't in any well-known language so the highlighting won't be perfect; I just want a bit of colour. But I'd rather not change file extensions as that could be confusing.

The tabbing is done through a ?t=4 parameter added to the GitHub url.
But the syntax highlighting (using Rouge on GitHub pages for instance) itself is either:
set in fenced code block (but only for .md markdown pages)
or by changing the file extension (which you don't want)
But how can I get it to highlight code files that it doesn't know about?
Update Feb. 2021 (5 years later)
Nat Friedman (CEO of GitHub) announces it on Twitter:
Another tiny but nice improvement we just shipped to GitHub – syntax highlighting now works on new files without the need to commit first.

Related

Disable competing language servers / code highlighters

I want to add a language server to handle completion / highlighting / etc. for a file.
As a basis for testing stuff I am using an example from Microsoft (https://github.com/microsoft/vscode-extension-samples/tree/main/lsp-sample) and changed it to be active for any File. This language server highlights any word in all capital letters.
When opening a C++ File, I get the highlighting / completion of my language server and the default one for C++ (See image).
I would like to detect if some other extension / build in highlighter is active for a file and deactivate it for this workspace or the current file if it is impossible for the current workspace)
Is there a way to do this in a generic way where I do not have to know which extensions are highlighting code?
If no, is there a way to do this, if I know a set of extensions I want to deactivate?
I finally had enough time to try around a bit more and found that providing your own language for the same extension is enough.
In package.json I added an element in contributes.languages with extensions containing .cpp (since I am using cpp files for testing).
I also copied over some implementation code from an example.
This suppressed the default highlighter and code completion for cpp files. Since i am only implementing a semantic token provider, I can see the default highlighting before my provider takes over. (I think this could be solved by adding a syntax highlighter, but this is already sufficient fo my preliminary testing)
I am not sure, how stable all of this would be as a plugin (I only tested in Extension Development Host mode)
Here an image of the results:

How to paste text with links and formatting into VS Code like Obsidian?

If I copy the above text from Chrome and paste it into Obsidian, I get
People who code: we want your input. [Take the Survey](https://stackoverflow.com/dev-survey/start?utm_source=so-owned&utm_medium=announcement-banner&utm_campaign=dev-survey-2021)
[](https://stackoverflow.com/questions/ask# "dismiss")
But when I paste into VS Code or any other editor, I get
People who code: we want your input. Take the Survey
Video Reference: https://dsc.cloud/J/67968285.mov
How does Obsidian do it? How can I achieve the same in VS Code?
— — — — — — — — — — — — — — — — — — — — — — — — —
The Short Answer:
"        The VSCode editor does not support the feature you described, and VSCode will almost certainly never support any functionality that comes close to it. This is because of what VSCode is, and what VSCode does, which I will explain in detail below."
The Long Answer:
So VS-Code is a text-based editor, and its purpose is to be an environment that programmers can write their code in, therefore, people using VSCode are going to preform a long list of tasks which includes, but is not limited to:
interpret, compile, execute, debug, serve, share, save, write, read, document, and run code. Now here is the problem with adding the ability to paste arbitrary data types into VSCode. Having any type of data, other than standard text in a file that you plan on using to do one of the following (this is the very short list)...
compile,
execute,
debug,
interpret
parse,
serve,
...will cause a syntax error to be thrown.
When you can copy, and paste, text-formatting from an external source (like a webpage), there is an extremely high probability that some unwanted formatting data will get pasted into some program you've written, and the text's format-data will end up not rendering for what ever reason (theirs a million and 87 reasons why that would happen), and you end up getting syntax errors that you can't see, so you now have no idea where the error is, despite the error message saying line number 734 column 24. In a situation like this you will have an error message that makes no sense, and you will have to start deleting things to find the issue. all because it has text-formatting data intertwined with standard text-data, which you can't see. I hope I drew a clear enough picture for you.
Their are other tools called word processors that implement this feature. I constantly couple G-Docs with VSCode.
Crazy Enough, not all is lost
VSCode allows extensions to make custom editors. The Extension API used to create an editor (can be seen by clicking the link) lets developers build the UI using standard HTML, CSS, and JavaScript. This is enough for someone to write a Word Processor for VSCode, which surprisingly no one has done yet. When someone does create one, which I am almost certain that someone will eventually, in could support the feature your asking for.
For the record, the feature your describing is typically a word processor thing. VSCode allows you to install extensions such as PASTE, which copies and pastes other data types, however; when it is pasted into the editor, instead of rendering the data types like HTML, it just writes it in its text format. In other words, you might think your copying the page at first, but you will be disappointed once you paste to VSCode. I want to point out that Paste uses the GTK-3 Clipboards API, which means that if Paste were to be implemented in a word-processor, like word, or Google docs, those word processors would render the data the the Paste extension pasted into the word processor. In other words, it isn't the extension that is failing to render the Data (which as stated, can be done with the Paste Extension), but its VSCode that wonder render that data as HTML, but only accepts it as a standard text data type.
#W3Dojo
What you've copied can be considered "rich text", but VSCode treats everything in your clipboard as plain text.
So it's the same as pasting via "Ctrl+Shift+V" in other programs like Word or Google Docs. It will remove any formatting, links, color, font, bold/italic, etc.
Obsidian was built with formatting in mind - it closely follows the markdown specification, so it's natural that it will try to convert any rich text to markdown.
I'm not aware of a built-in VSCode setting that will allow you to paste rich text, but I've found 2 extensions that might do the trick:
Paste Special
Markdown Paste

VSCode issues with syntax highlighting for yaml headers in markdown

I have been using VSCode and Pandoc for writing Markdown documents. VSCode recognizes and highlights some YAML header blocks just fine, but not others. I noticed the problem on HTML comments in Markdown.
If I use this style of YAML header (closed with dashes) at the very top of the document, VSCode seems to recognize the end of the block, and move back to normal highlighting mode after the close of the block(see screenshot "scratch1.md" document).
---
title: Best Article Ever
author: Great Writer
---
However, if I use another legal style (closed with ...) which seems to be legal according to the YAML specification, section 2.2 Structures:
---
title: Best Article Ever
author: Great Writer
...
VSCode does not seem to see the YAML block as closed, and so highlighting is messed up for the rest of the document (see screenshot below).
This problem (messed up highlighting) does not occur for either style if they are not at the very top of the document.
At this point, I'm not sure where the problem is and how I might go about changing it. Some pointers in the right direction would be appreciated.
Is it a problem with my understanding of the YAML syntax?
Is it a problem with the YAML language file in VSCode?
Is it a problem with the markdown language file in VSCode (i.e. problem with the embedded YAML)?
Is it something I have to/can correct with some kind of language extension?
etc.
It isn't hugely important to me, but I have a lot of legacy documents like this and if a correction is reasonably straightforward I'd like to try.
Thanks in advance for any help or explanations.
I work on markdown support for VSCode. Yes, right now you have to use --- to terminate your frontmatter.
I've opened https://github.com/Microsoft/vscode/issues/23178 to track support for using ... as a frontmatter terminator. Feel free to submit a PR for this. I've added some notes on what this would involve: https://github.com/Microsoft/vscode/issues/23178#issuecomment-289136137
Update
This should be fixed in VSCode 1.11+
Here was the fixing PR: https://github.com/Microsoft/vscode/pull/23195

Return without double-space at the end with Visual Studio Code markdown

I often write markdown-style documents for GitHub with VS Code.
When I preview it, it breaks lines only when I place 2 spaces at the end.
But is there any way to add a line break with simple return?
I know this is not a standard behaviour of traditional markdown,
but since GitHub supports simple return, I also want to have it locally.
(Otherwise, the sentences I see on VS Code preview and GitHub differs a lot...)

How to efficiently edit Markdown in the github issue tracker?

I like the fact that the github issue tracker supports Markdown. However, I find it relatively unpleasant to actually write Markdown in the github editor. It lacks many of the features of the Markdown editor on StackOverflow.
E.g., it lacks:
a button to indent multiple lines of code by four spaces
a button to add quote to the start of each line
real time markdown preview
fixed width font
ability to insert image using imgur
a confirmation dialog box when you close a browser window when you might otherwise lose your work
In particular, the inability to insert code blocks is probably the feature I miss the most.
Sure, I could write my markdown in a separate editor and then paste it into the github issue tracker, but this is not especially appealing. I could even use the StackOverflow editor if I was careful not to click "Ask Question", but that seems a bit silly.
Question
Is there anyway of altering the text box in github to incorporate the editing features in StackOverflow?
Or if it is better to type in another text editor, what's a particularly elegant way of doing that? (e.g., minimum steps, simple to move back and forward, good editor) Perhaps theres a way of clicking a text box and bringing up a Rich Markdown editor which when closed returns the contents to the original text box?
You should appeal to GitHub to add one. Your argument is sound. Stack Overflow demonstrates editors can be functional, non-intrusive and tasteful.
Meanwhile, there might be a browser extension that does some of this. https://chrome.google.com/webstore/detail/cpojebknccclkjabfngjlcknonpmhhol
If you are on Windows, you might want to check MarkPad: http://code52.org/DownmarkerWPF/
Disclaimer: I have never used it myself (being on Ubuntu), only read about it watching the code52 project. I know it can edit posts of several blog systems, but I'm not sure if Github is in the list of supported web sources. Its syntax however is supported, for sure.