everyone I have met a problem that I couldn't find any answer online so far. hope there is someone who could help me !! (If this question already has an answer online, I would love to know thanks!).
When I use my nvim, I find out that my buffer on the top keeps showing [no-name] buffer. at first, I can't find why it was showing that [no-name] buffer.
Then I find out every time I switch the buffer with coc-nvim diagnose is activated, I'll get the [no-name] buffer with the diagnose message in it(image 2).
so I think it might be the reason of coc-nvim. but I'm not sure and I don't know how to fix this issue.
please help!!
my nvim full view
no-name buffer with coc-diagnose
Here is my nvim config file on GitHub if someone wants to play for a while. https://github.com/IsaacTai123/DotConfig/tree/master/nvim
Related
I'm struggling with this really annoying thing in VSCode and I don't know if its a bug or just something I accidentally turned on inside the VSCode settings.
The Problem: When writing some code, for example in HTML typing "class" it provides me suggestions. After accepting it, the Cursor stays between the autocompleted quotes (class="here"), but has some weird kind of marking and is not giving me any suggestions anymore. The get new ones, I first need to press esc and now I can type again to get suggestions.
Anyone familiar with this issue? I'd be really thankful if someone knows how to turn this off, because it's a really irritating thing.
I made a screen record and uploaded it to youtube so you can see the behaviour:
https://www.youtube.com/watch?v=gtVSWx0Qc6A
Disable this setting:
Editor > Suggest: Snippets Prevent Quick Suggestions
otherwise the active snippet prevent more suggestions.
My apologies if this is an overly nooby question. I'm just learning Ruby and my terminal has started acting funny and I'm not sure how to fix it. I appreciate any guidance that can steer me in the right direction.
First, when I open terminal within VS Code I have started to get the following message - "complete:13: command not found: compdef". As a newcomer, I am not very skilled yet with zsh and not sure what to do to fix this message.
Second, ever since this message started appearing, whenever I run ruby code and expect an error, instead of getting an error message, the terminal just seems to crash. The cursor moves to the next line and then nothing happens other than the fan speeding up. I can type text but the only way to get the terminal working again is to close out and reopen. Is this related to the compdef message I am getting or is this a separate message? Does anyone know how I might go about fixing this? It's preventing me from being able to learn where I am going wrong in my code.
Thank you so much to anyone that may have an answer!
When editing a large file, flycheck-mode often takes 3-4 seconds to complete if an error "spills" over into the rest of the source file such that lots of lines are tagged with an error.
How do I limit the number of errors that the mode highlights such that it prioritizes the current buffer location?
Flycheck maintainer here.
You cannot “limit” error reporting currently in an easy way. At best, you can use a custom function for flycheck-process-error-functions, but that won't help you if the lag comes from something else, like error parsing.
And in general, I'd rather like to fix these lags than work around, if possible. Please open an issue at https://github.com/flycheck/flycheck/issues. Please add your Emacs version to the issue, and the amount of errors reported by Flycheck.
If possible, also give me the source file in private. You can find a mail address in the Github profile of Flycheck.
I'm not sure how to comprehensively accomplish this.
Currently I build my own bzr Emacs on Windows, so I can see that `display-buffer' now takes a SPECIFIERS option, which could be interesting, but I couldn't find concrete examples of how to use it.
But this problem really has to be solved before display-buffer is called.
For example a Help window previously was visiting Buffer-A, but I've visited Buffer-A in another window while reading the help. Now when I quit the Help window, Buffer-A appears there as well. I want some other useful buffer to appear there.
I have some experimental code that appears to work here.
I emphasize experimental. This could melt your Emacs.
I'd appreciate it if you could contact me on github or here to let me know your experiences with this.
Emacs 24 is not yet released. They have changed the buffer-display/window behavior and Lisp interfaces several times over the release's development period. The current status of the release is pretest, so development is supposedly stopped, except for bug fixes.
However, ongoing emacs-devel#gnu.org discussions show that things are still in flux wrt buffer display and windows.
Your best bet is to check the latest doc and code (which might not correspond exactly, at this point).
I was digging through the header files for SDL in Linux when I tried to open the file from the SDL library called "SDL_opengl.h" in Emacs. For some reason, it always causes it to crash. It opens just fine in Vim and in gedit.
Has anyone else had an issue with Emacs just plain refusing to open a particular file? What sort of things should I look for to find what is causing the problem? Mind you, I was able to open every other "SDL_*.h" file in that directory; just that one gives me trouble.
Much appreciated in advance!
I would be interested to see the exact error message, and stack trace if possible.
I suspect file encoding, special characters, file size, cc-mode parsing, or something like that to be the culprit. (emacs 22 and libsdl1.2 on ubuntu 9 with utf-8 screen works fine for me)
Converting my comment into an answer b/c the comments get cut off.
Try loading the file with
M-x find-file-literally
Since this (appears to) resolve the issue for giogadi, I think that points to perhaps the colorization of the buffer. cc-mode does its own colorization...
Oh goodness, I'm a dunce.
So I apparently underestimated both the size of the file AND the speed of Emacs in opening said large files.
I decided to sit and wait to see if it dies completely on its own (as opposed to me xkill-ing it), and after a whole minute, the file is loaded.
So that solves one problem - the file is being loaded. However, why would Emacs take so long to do it? I have no strange settings enabled that should cause it to lag more than usual.
have you hilit-mode on?
with hilit-auto-highlight-maxout and a great value?
I have had the same problem with header-files, so reduce that value.
maybe it is hs-mode (hideshow-mode)?