I have a Jekyll blog, where I changed the code highlighter from Rouge (the default) to highlight.js, and it works perfectly.
However, I also want line numbers on my code snippets. Since highlight.js does not provide line numbers by default, I turned to the highlightjs-line-numbers plugin.
I followed the instructions given in the highlightjs-line-numbers usage instructions, and added the relevant lines to my _includes/script.html.
However, for some reason, adding this plugin mysteriously changes the code font to Arial. Here is a link to a blog post which demonstrates this odd side effect.
I have tried to figure this issue out for hours, to no avail. Does anyone know what I am doing wrong, and why this code font change is occurring?
Edit: The current GH Pages is being built from the custom-liquid-tag branch of my repository, and not main.
Updated Answer
This answer was not able to help OP with the problem. Keeping this answer here so the comments remain intaked.
Original Answer
I think you are missing the import of the highlightjs stylesheet that goes with the highlight JavaScript in your file scripts.html [1]
https://cdnjs.cloudflare.com/ajax/libs/highlight.js/11.6.0/styles/default.min.css
[1] https://github.com/wermos/blog/blob/main/_includes/scripts.html
As a sort of last-ditch effort, I opened an issue on the highlightjs-line-numbers repo to get some feedback from the author of the library himself.
Luckily for me, he responded, and the solution he proposed was indeed correct:
In my repository, the theme I am using, minimal-mistakes, was overriding the table CSS style and breaking the font. Since the line numbers plugin uses the table CSS style, the end result was a messed up font.
The error went away after I manually added
table {
font-family: $monospace;
}
to my main.scss.
For the sake of completeness, here is a link to how minimal-mistakes defines $monospace.
Related
I'm baffled! I built ckeditor 4.13 using the online builder, and included the codesnippet plugin. Now when I chose the plugin within the editor from the toolbar it allows me to add the code under which ever language I choose, but the syntax highlighting doesn't work for all languages. For example CSS is not highlighted. The background of the chosen theme is there, but no highlighting. SQL queries are fine as are some others, but not CSS or PHP it would seem!
Also, I'm editing in one place and then viewing the article on another place (pulling the article from a database). The styling is completely missing altogether when it's the article is viewed. I tried to find a CSS file which may contain the classes that had been attached to the snippets (such as language-php) but couldn't. I thought if I just linked to the CSS file in my header it would attach the styling...I was wrong!
Any ideas how I can tackle this issue please? Google has brought nothing so far.
For anyone interested, I've found the best way to deal with the syntax highlighting issue is to download prism. This will work with the classes produced by ckeditors codesnippet plugin and colour code the syntax according the theme you chose from Prism. Look at prismjs.com.
My Vim level is about intermediate - I've been using it about 10 years, but on "newbie" level - find file, delete something, add something, save and quit.
Now I decided to make Vim my only code editor.
I'm working with Ionic framework (it's Angular + SCSS) and I have a question about some useful things:
Is there a way to add all non-standard HTML tag to Syntastic? It's highlights all of Ionic tags, such as <ion-list>, <ion-button>, <ion-radio> and so on. If my google skills are good enough, there's no full Ionic plugin, which will add snippets, syntastic checkers and so on.
Is there a way to find and add classes from HTML to SCSS and from SCSS to HTML? I mean, if I'll write .my-very-important-class in SCSS file and then go to HTML file (which is in the same directory with same name and differs by .html or .scss) and in class="" attribute start to input "my" I'll get autocomplete suggest for this class. Is it real to make or maybe someone did already?
There is also main file for theming an app, called variables.scss. I need this file to be scanned and match colors (in this file there is an color section, where I can put all colors, I'll need in app, and in .scss file of any page I can get color I need with just color: color($colors, colorname) where colorname is the name of color variable. It's awesome feature, except no color highlighting in code. So it would be great to get color mappings and then highlighting with correct color in .scss file of page.
I didn't found any plugins for this. If there some existing plugins I've missed - I'll be happy to try it. If it's no - I will be glad to made one myself (if it's not very hard). Anyway, I think this are useful things not just for me.
UPD: #1 was fixed - I'm not sure, how exactly, but now it's fine in HTML and I have no errors or warnings from syntastic about wrong tags. I'm feeling newbie, but seems like I forgot to install Vim-ionic2 plugin - just added it to my .vimrc.
And #2 seems to be answered - does what I need.
Syntastic is a frontend to several linters. Find the linter used by Syntastic and look for a way to make it accept those custom tags.
If you have the CSS file opened, <C-n> should let you complete the CSS class.
You might need something like set iskeyword+=- for Vim to complete the whole class name.
I think this would be totally useless. That said, if you didn't find such a thing… write it.
respect to the first point I'll say that vim for itself doesn't highlights all the HTML elements (main, header,etc) because the default html.vim file is a little outdated. However, I've just created a repository in which I added all the remaining elements to be highlighted.
If you encounter that something in the language you're working on doesn't get highlighted you should create a .vim file adding the keywords you want to be highlighted. I share you the repository I've talked about: github repo
It'll be nice that people can contribute so we don't have to create repeated vim files.
You can read more about syntax here: vimdocumentation
First off, I'd really recommend you split this into three separate questions. I feel like they could easily have dedicated answers that are not really connected. And someone might have a good suggestion for one of them, but not for the others. On my side, I can give you suggestions about 2) and 3) only.
For 2), you could use romainl's suggestion for completing keywords. You could also try generating tags for your CSS files using ctags. Here's one possible way to do it: https://github.com/rstacruz/ctags-css. Once you have the tags, you could use tag completion. See :help ins-completion, in particular the "tags" section. It would be a pretty good idea to read up the entire section, though, to get an overview of what's possible.
For 3), there's plugins around for this. Try this one: https://github.com/lilydjwg/colorizer
For a big site renovation project I am looking for a way to find all elements in a website to which a certain css rule applies. This site has been extended for 6+ years, so CSS rules are not systematic/logical at all.
For example: I want to know on which pages form input[type='text']{} is mentioned on the entire site.
I cannot do this with a simple 'find text' search, because there are a LOT of CSS rules that are specifically set to a certain element (e.g. #login form input{} or form textarea.forminput_small{}), so there probably is quite some overlap. Furthermore there are a LOT of pages, so I really don't want to do this manually.
My desired output would be:
input[type='text']{} is on: /index.html, /search.html, /contact/form.php etc
For me a solution like a browser plugin, external website tool or PHP script would be fine.
Hope someone has a nice solution for this problem!
Edit 9 August 2018: digging up an old thread. However, still not found a good solution, but I did find the element-finder plugin for Atom. Unfortunately, it doesn't work anymore. The GIF image in the description shows what the purpose of this plugin (i.e. my question) is. Any ideas for an alternative?
Just updated Pycharm, and now it won't recognise any of my HTML tags. Do you also have this issue, or have I messed with some settings? A few days ago I changed a few of the HTML settings, but can't really remember what I did...
So, all of the yellow marked tags are not recognised by Pycharm anymore? I have no idea what I've done to cause this, unless its an update issue, but I searched online and could not find others with the same problem.
Had the same problem. Reading through this bug report I tried the following:
File | Invalidate caches
Worked like a (py)charm ;)
Delete your .idea folder, and then restart pycharm.
If you can refine your post, we'll be able to help you; can you point to a hi-lighted tag with your mouse and read the warning on pycharm status bar. Also you can do this by pointing to the warning indicators on the right in front of each line. Here are some things you can check:
settings/code style/html bring it back to defaults
settings/inspection bring it back to defaults
settings/file types choose html and check the registered patterns, it may be broken, you should find *.(htm, html, sht, shtm, shtml)
you could also un\re-install html tools plugin.
I have worked a few places which haven’t used source control. They seemed to get into the habit of putting comments around code they changed explaining the change so that things could be reverted.
I have found that this makes the code very difficult to read, and have been fairly adamant that such comments are not needed after introducing source control as the revision history will let you match up tickets with changes.
However now, I am not so sure, I think it may be good to document major revisions to a file in a file as well as in the commit messages. This should make the code more readable. Do people have a best practices way of documenting changes to code, so that it is not too cluttered but is still explanatory to someone trying to read it?
Just to be clear, I am not talking about a list of changes in the head of the file (which is a whole other argument) but comments in the code.
Most source control systems have an "Annotate" or "blame" command. It shows what code changed with each revision.
Since this information does not change the behavior of the program, or make it easier to understand the program, it doesn't belong in the program.
The documentation present in code should describe the code it is near. If the code changes, the documentation should also change accordingly. The version control system should take care of managing what changed and why it changed. Let the code and it's documentation do it's job (Doing things, and describing how/why those things are done), and let the version control system do it's job (controlling/documenting versions and changes).
Whenever you start indicating history in the present(current code), you are asking for trouble. Just think what a particularly change-heavy area of code would look like if it had a number of changes?!
If the comment is time sensitive don't do it it's a bad idea. Put a comment on the source file in the version control system instead.
I see this problem all the time at work. The code base I am currently working on extends back to 1979. You can imagine the difficulty with comments like the one below which have built up over that time:
"Line below seems to fix bug xyz, will revert if unforseen issues occur"
I realise it's not a very descriptive comment in the first place but that sort of thing in svn/cvs/etc. is actually very handy. A comment like that in the code sows the seeds of doubt. Can the comment be removed? Is the unforseen issue that has caused me to have to look back at the code related to this comment? etc.
I'm just wondering how knowing what the program USED to do helps understanding it now? You say it aids readability. How?
Now, when something is changed because the old way didn't work and the new way is counter-intuitive, I think that should be commented in code, because it's necessary to know for all time "This didn't work, don't do it again. I know it looks like it would make more sense. Still don't do it." Otherwise, I don't see that it helps.
Don't think that commenting changes inside a code is ever possible in a explanatory way.
But I'd like to say about "Modification history at the file begin". I doubt that this is useful at all. Unless I wanted to know which to versions of a file to compare to see the difference that were introduced with some "NNNN" task. In the file begin there is a line "NNNN date - small description". And our source control can "say" who and in which version this line was introduced.
So without this line I would look through all versions to find correct one.
I think it's good to document major changes or refactorings as comments in the code. I agree that it does get a little messy to read around copious amounts of comments, but I think it's easy enough to ignore the comments and try to just read the code. If anything is confusing, or you are tempted to change something, and there is a comment near by, you will be much more inclined to read the comment, as opposed to doing diffs with previous versions to see what had changed and why.
Each method in our codebase has its own change history. When the code of a method is changed its header gets a new entry. The code itself does not get cluttered with history comments, only the method header. Each change history entry consists of one or two lines briefly describing the reason for the code change in general terms. The entry also contains a number that refers to a change document, The change document also contains links to bug reports, development projects, design documents etc.
Such entries are invaluable, as they often give you an insight as to why the code is as it is. If you are there to fix a bug the history trace will invariably tell what code change introduced the bug, what the change was attempting to do, and therefore what else you need to be aware of when deciding on a fix.
OTOH - Reams of comments in the body of the code describing what it does and who changed it when are just noise.
Going to have a stab at answering this myself.
Documenting every change in the source makes it difficult to read, however if there is a particularly counterintuitive piece of code in there and it was introduced for a particular ticket put a note by it as to why the code is strange.
But the code should still be documented. So while you make not put in
/* ticket 101: add blink tag to headers, JF - 20010102 */
You may want to put in
/* make headers blink */
Quite often when people stop doing the former type of comments, they cut down massively on their comments and this is bad.