Suddenly, the way to analyze and display errors in vscode changed. From today it marks the entire function block as an error, which is annoying because it becomes very confusing.
I do not know if without intention I pressed a shortcut, or some combination of keys. Does anyone know how to return to the previous mode?
Thanks a lot.
Before LSP, the error range was being accidentally truncated to a single line. With LSP the complete region is used, which means you now see the actual range produced by the analyzer.
Turning off LSP is only a short-term fix as it will soon became the default (and only) option, so if you think the shorter ranges are better, please file an issue at https://github.com/dart-lang/sdk for some discussion. Thanks!
Related
I have the following snippet in the hypersnips extension (in vscode)
snippet txt "text in math" imA
\text{$1}
endsnippet
Usually, it works fine with me typing txt and it automatically sends me to
However, sometimes when using a snippet I get the following
After this occurs, if I delete that and try again, I get
This "bug" (?) occurs 10-20 per cent of the time and it is very annoying. Moreover, it is not unique to a specific snippet.
I have tried changing the version of vscode and of the extension but nothing has seemed to work.
Any help will be greatly appreciated.
EDIT: Screenshot to address rioV8's comment
I think that it is the bug of VSCode. When you overlap placeholders more than (about) 18 times, it occurs.
Just because HyperSnips adds too many placeholders, you noticed the bug.
Test: use VSCode keybindings to add snippet (without extensions).
ctrl+M inserts $|$ | .
Click here to view the result
However I don't know why it occurs and how to solve the problem. Sorry for that.
I'm using (global-linum-mode t) to present line numbers in Emacs.
This works just fine up-until I use the ctrl + up/down commands (forward-paragraph and backward-paragraph) to navigate a buffer, at which point some line numbers are rendered incorrectly (see attached image).
This occurs only when I use said commands to skip entire segments of code, and the issue immediately disappears (the line numbers are rendered correctly, that is) if I start navigating the buffer by other means.
The issue is present in both C and C++ modes (visualized), and I'm using Emacs 24.3.1 on x86-64 Fedora 19.
While the go-to-line command serves my purposes in terms of navigating compilation errors and warnings, I'd like to keep the line numbers as I find them to be helpful in terms of quickly approximating length of functions.
So far I've found no mention of this problem elsewhere, and I'm unsure of whether or not this is expected behavior of Emacs or if I'm to submit a bug report.
Has anyone encountered the issue or know anything of its origin?
Fix:
The problem may be resolved by invoking (linum-update-current), as portrayed by #lawlist in his answer below. An easy way of repeatedly doing this is to append the command to the execution of forward-paragraph, which may be done using the Emacs Lisp advice feature:
(defadvice forward-paragraph (after forward-paragraph-linum-update)
"Perform (linum-update-current) after jumping forward one
paragraph to ensure line numbers are being rendered
correctly."
(linum-update-current))
(ad-activate 'forward-paragraph)
A few of the lead members on the Emacs development team suggest that linum-mode be avoided for a variety of reasons, and instead they suggest using nlinum-mode: http://elpa.gnu.org/packages/nlinum.html
I personally use a modified version of linum-mode, and I have fixed a few bugs -- if you keep using linum-mode, you will likely need to do the same -- i.e., implement your own bug fixes as you find them. The quickest way to fix the bug you see is to follow your command with:
(linum-update-current)
I've tried to figure the problem myself, and will probably continue, but due to poor error reporting it's just too time consuming. So, perhaps, if anyone had encountered this problem before, please share.
What happens: after flymake-jshint encounters an error, no matter what the error is, it could be a missing semicolon for example. It will get stuck in an infinite loop. I can C-g the loop, but this is very annoying, and will happen multiple times on the same line, making it absolutely impossible to write anything.
When I then look into the *Messages* buffer, it reveals something like:
missing ; after statement [NNNN times]
i.e Flymake was requested to perform the check many times. The timer interval is set to 2 seconds, but it clearly overdoes, because it will do hundreds of checks in two seconds. Trying to increase the flymake-log-level reveals no additional information.
I have customized these variables:
(flymake-no-changes-timeout 2)
(flymake-start-syntax-check-on-newline nil)
but no more additional customizations.
EDIT:
This seems to be related to auto-complete mode. Disabling this minor mode "solved" the problem, but now I'm getting hundreds of "Invalid face reference: nil [NNNN times]" kinds of messages. sigh
I think, I finally found the problem. It was the highlight-current-line minor mode. Whenever Flymake would detect an error and needed to paint the error location it tried to read the overlay, but got confused by the overlay created by the highlight. I haven't yet gotten to trying to fix it, but simple disabling of the highlight made it at least possible to work.
Emacs reindents the current line whenever I type certain things, like ";" or "//". This is pretty annoying, since there are a whole lot of places where it isn't smart enough to indent correctly.
How do I disable this feature? I still want to be able to indent the line with TAB, but I don't want any source code I type to cause it to reindent.
(I'm using Dylan Moonfire's C# mode, but this probably applies to any cc-mode.)
Try running c-toggle-electric-state to turn off the electric action of these characters.
You can do this as part of a c-mode-common-hook, or toggle the state manually by hitting C-c C-l.
most likely caused by the inline-and-indent 'feature' of c-mode and derivatives. emacswiki has several solutions.
When I try to add closing parentheses, it always override the next parentheses to the right.
Here is a screen capture (it looks like I hit the right-key on the keyboard, but I'm actually inserting a new closing parentheses):
Is it possible to change this behavior?
As of version 1.38, the answer is yes, you can turn it off completely, while still keeping the autoclosing brackets.
That version introduced a new setting, editor.autoClosingOvertype, which can take three possible values:
always - always overtype closing parens (the old, classic, Sublime-Text-inspired behavior)
auto - "smart" overtype which tries to detect whether a closing paren was automatically inserted by the editor, and overtypes only those parens (this is the default)
never - never overtype closing parens
The current default behavior was introduced in version 1.37. At that time, there was no setting available, you just got the "smart" overtype behavior no matter what.
I'm leaving the material below for historical purposes.
No, it's not possible (yet), and this is by design. When you are typing brand-new code, and you type an opening bracket, you get the closing bracket automatically (when you have editor.autoClosingBrackets on, of course). Then, when you are finished with typing whatever you want inside those brackets, how are you going to "exit" and leave the closing bracket where it is? The most natural way is to type a closing bracket! Some disagree, but many typists find this much easier than moving their hand all the way out to the arrow keys or mouse to move past it.
Note that this behavior is largely inspired by and modeled after what Sublime Text does.
It may be helpful to understand that the autoclosing brackets feature isn't primarily for saving keystrokes. Rather, its main purpose is to improve the stability of syntax highlighting (which can get wonky when there is an unclosed bracket), and secondarily to help prevent you from forgetting to type the closing bracket. If you happen to navigate away for some other reason without typing it, then congratulations, you do get that bracket for free!
The two simplest options you have if you want to add a bracket (and let me note that in your example, you'd be adding a mismatched bracket) are to either (1) put the cursor after the cluster of closing brackets before you type a new bracket, or (2) put the cursor where you did, but just keep typing closing brackets until a new one is added. In either case, any new brackets will only be added to the end of the cluster.
Update (now obsolete):
For what it's worth, there's now an issue for this on the tracker, as well as a pull request to create a setting which allows you to turn off the "bracket-swallowing". For anyone who is reading this, if it's something you're interested in, you should give your feedback on the pull request.
Further update (now obsolete):
There is currently new code being tested which will make the bracket overtyping more sophisticated. The plan is for the editor to keep track of which brackets have automatically been generated, and only type over those brackets. Once the cursor leaves the bracketed area, the editor stops keeping track of those brackets and they become "full-fledged" characters that can no longer be typed over. Hopefully, this will retain the overtyping where it's useful and get rid of it where it's not. Note that the current plan is for this new behavior to become standard, and to not have a setting to control whether it is in effect.
Try setting:
"editor.autoClosingBrackets": "never"
to disable the autoclosing brackets feature entirely.
Vscode has finally fixed this issue, and you don't need to do anything in order to get the new behaviour. Now it will swallow only brackets that were automatically added, so everything works as expected. If you already disabled the autoClosingBrackets option from the settings, it is recommended to turn it on again now.
The way to work with the VSCode original setting is to add new parenthesis at the end of a list of parenthesis.
...if (test === funFunction(data))| /* <- here */ {...
You should be able to type a new parenthesis and it won't override the old one. This doesn't solve your problem, but if you wanted to follow the paradigm that VSCode is using then there you go.
(personally I disable it like the other comments say)
There's another option available now called autoClosingBrackets beforewhitespace. This will overtype an automatically added parenthesis but it will not overtype of there's any characters to the right of that closing parenthesis. This is perhaps a step closer to the OPs intended behavior, it certainly saved me from going totally bald.