I find that JSLint produces lots of warnings of the form:
Expected 'foo' to have an indentation at X instead at Y.
The JSLint options documentation describes an indent option that recognizes a numerical value representing the amount of space for each level of indentation. This option allows me to say things like use 2 spaces per level of indentation. I just write something like this at the top of my JavaScript file:
/*jslint indent: 2 */
OK, great. Now JSLint knows how much to indent for each level of indentation, but JSLint seems to be hardcoded to decide what level of indentation each line should have.
Suppose I want to indent my code differently than the way JSLint prescribes. Can I do this with some JSLint option? If not, can I at least turn off the indentation warnings? I tried:
/*jslint indent: false */
but that did not cause indentation warnings to be elided; it caused a JSLint error.
What a difference that morning coffee makes:
/*jslint white: true */
If you don't want to disable JSLint, you can remove the double indentations (e.g. when defining multiple var's in a javascript file) by adjusting this setting:
Options > Editor > Formatting > Language: Javascript > Continuation Indentation - set to 4.
Now you can use ctrl shift f to format code, and JSLint doesn't freak out...
Related
Intellij keeps formatting my spotbugs.yml file incorrectly, and so breaking the github action.
I cannot figure out why it's doing this:
It was working fine last week, I haven't made any changes to the formatting config, but now, every time I change focus from the file Intellij auto-formats like this, then saves it. How can I fix it?
The thing I don't get is what it's formatting to appears to be invalid yaml, right?
YAML has a syntax that makes it incompatible with indentation that is not 2 spaces. With 4 spaces, you have:
droggel:
jug:
- sequence item: with indentation
this line: isn't aligned to four spaces
nor are further indented lines:
if you indent relative four spaces
spam:
- same: problem
without: indenting the sequence item
This makes it hard for code formatters to get it right. Proper alignment would mean:
droggel:
jug:
- three spaces after the sequence item indicator.
that's horrible, nobody does that.
spam:
- alternatively this.
nobody does this either and it breaks
- - with nested sequences
I assume some bug in IntelliJ causes the formatter to be confused because of this. Generally it would be better to just use 2 space indentation which seems far more natural due to the problems described above. That should avoid confusing the formatter.
I cannot get indented code to highlight in GAWK in vim markdown model
Context: I doing some literature programming in gawk. Comments are markdown syntax and code is GAWK, indented by a tab spaces.
Problem: I followed the doc at https://github.com/plasticboy/vim-markdown#options. The markdown highlights as it should but the indented code remains white and bland:
What I did: The first line of my source code is
# vim: nospell filetype=markdown :
My .vimrc contains the line
let g:vim_markdown_fenced_languages = ['awk=awk']
Which, according to the doc at SHOULD be enough to make that syntax highlight happen
Help?
That information is not enough to get vim to understand how to highlight your block of code. "Fenced" refers to code that is bounded by triple backticks as follows:
```awk
this is some awk code that would be highlighted
```
This, when combined with the let g:vim_markdown_fenced_languages = ['awk', 'sh', 'make'] etc lists, lets vim know exactly which highlighting syntax to use in a particular block.
You should also note that you don't need that particular vim plugin to get this to work; this is native vim functionality.
Edit: If you really want indentation, you can just indent the code block with the fencing:
```awk
some awk code surrounded by indented fencing would be highlighted
```
If you were really hard-pressed to avoid the fencing entirely, the only way I know of would be to go into the actual vim syntax files:
cd $(vim -Nesc '!echo $VIMRUNTIME' -c qa)
vim syntax/markdown.vim
and try to figure out a way to force a default of awk highlighting on indented code, but I wouldn't recommend it.
How would one achieve to keep IntelliJ from removing spaces in Python (or any language for that matter) in areas where spaces serve a specific purpose of readability, such as repetitive assignments of many values.
is how I like it and I think many vim users agree that this is the way to go.
However, this is what IntelliJ makes out of it
The issue is specifically interesting with language such as python where spaces can (but do not have to) impact the programs flow.
I am also aware that it is rather difficult to define when spaces should be compacted (i.e. when only one of the 4 lines above are present) and when they should be kept.
I guess some heuristic approaches would work, this however wouldn't really be a 100% on-spot lintable situation.
I like your idea, but don't see how to achieve that within the Editor Settings.
An ugly alternative that does work, but "pollutes" your source, is to Enable formatter markers in comments on this screen: File -> Settings -> Editor -> Code Style:
After choosing that option you can selectively create blocks of code that will be ignored by IDEA when it formats the code:
// #formatter:off
String s1 = "Arkansas" + ".";
String s2 = "Maine" + ".";
String s3 = "Massachusetts" + ".";
String s4 = "Ohio" + ".";
// #formatter:on
You could also raise a bug report with JetBrains: "Provide an option to allow multiple embedded spaces in source code". That should be fairly straightforward for them to implement: just don't replace multiple embedded spaces by a single space when reformatting.
I love the fact that IntelliJ evaluates my code for syntax errors, but I don't like that it shows common errors on the current line as I'm typing.
There are several examples of this, but the most common one is the red error line (squiggly underline) for a missing semi-colon. I don't want the editor to check for this error until after I've finished typing the line and have pressed return. In fact, I really don't want the editor to evaluate the current line for ANY syntax errors until after I've completed it. The constant changing of the error indicators on the current line as I type is getting annoying.
I've looked around in the various options, but I can't seem to even find the name of squiggle line feature. It isn't code analysis, as that applies to the red and yellow indicators in the right margin. What is the name of this feature, and where can I find the options for it?
Example ( '|' is the current carrot position, '~~' are the red error lines)
System.Out = |
~~
The issue isn't limited to just the semi-colon, but for all sorts of other common syntax issues that I know I know about and will fix before moving on to the next line.
Update: I think the name of the feature is "error highlighting". But I still can't find any way to disable it for the current line. The closest I found was Setting --> Editor --> General --> Error Highlighting --> Reparse Delay, but that changed it globally with no option for just the current line.
There is no option in IntelliJ IDEA to disable error highlighting for the current line.
You can change the Settings -> Editor -> General -> Error Highlighting -> Auto reparse delay (ms) to something more comfortable, e.g. 3000 ms.
It will still highlight the error, but not immediately.
When goals are displayed by Isabelle in ProofGeneral, assumptions are rendered as having brackets around them as so:
In Isabelle/jEdit, however, this seems to have changed to meta-implication arrows:
While I understand the former is somewhat non-standard, I find it much easier to read. Is there a way to modify the behaviour of Isabelle/jEdit to print out goals in the old ProofGeneral style?
The format Isabelle renders its output is determined by Isabelle's "print modes". In ProofGeneral, the default print_mode includes the brackets mode, which renders brackets around assumptions, while the default jEdit print_mode includes no_brackets, which does the opposite.
The print mode can be changed either by setting Plugins > Plugin Options > Isabelle/General > Print Mode to brackets and restarting jEdit, by adding -m brackets to the isabelle jedit command line, or by including in your ~/.isabelle/etc/settings file:
ISABELLE_JEDIT_OPTIONS="-m brackets"
This will result in jEdit displaying brackets like ProofGeneral:
Go into Plugins -> Plugin Options -> Isabelle -> General
then type in brackets in the Print Mode field.
Click Apply.
Then close out of Isabelle and restart it.
You should have brackets around your hypotheses thereafter.