I have stage server which I use it with Xmanager. In the stage sever,after whatever I choose using the mouse,a "^C" will appear automatically after $.For example ,I choose "system/" with mouse,and a "^C" soon appears in the command line.
It never happened before until yesterday I tried "Shift+Ctrl+V" which means "copy" after I choosing the command line which I wanted to copy, but it didn't work although I tried several times.And then the problem I described existed.
It's really confusing,and I don't whether "^C" has any bad effect.
How to resolve this problem?Anyone knows why it happened?
The reason causing this problem is that I opened youdao dictionary simultaneously with its function of catching words on the screen on. Just close it and the problem won't happen again. I don't know why maybe it has something to do with the software's compatibility.
Related
I have a big problem with CodeBlocks right now.
If I make somewhere a breakpoint, and start the debugger, it will show the code until the breakpoint.
The problem starts here:
If I want to go to the next line for example, it won't work. In the Info Box/Console messages, there is a message called:
"In ?? () () "
"Cannot find bounds of current function"
What could it be?
Furthurmore, I noticed one thing when I compare CodeBlocks on my desktop PC with that on my Virtual Machine (on a Notebook). Is that on the Desktop he goes by a path that includes Python 2.7, while on my Notebook this path is nowhere visible.
I hope somebody can help me out! Thanks for any help!
It is not the first time that I have encountered this problem, mainly your debugger must be hosted in a folder that contains incompatible characters, at least that is the reason I gave it, download MINGW or some debugger of the same style, what I did was create a path without special characters or spaces.
This is how I fixed it, I hope it work for you too.
I am using emacs on Windows 7 and am using c-mode. Indentation starts out fine, but frequently, it stops working fine (what happens is that when I press the tab key, instead of indenting to where it normally would if things worked correctly, it would get rid of all indentation on that line). I have found that re-activating c-mode made everything work nicely again.
This happens anywhere in the code. If I have existing code and tab (even in the first lines of a main function), it will remove all indentation. I am almost 100% sure it isn't because I failed with my syntax somewhere. For example, if I have the following code, pressing "tab" on the second line will remove all indentation.
int main() {
printf("Foo\r\n");
return 0;
}
I don't believe c-mode suddenly disables (all of the syntax highlighting still exists, and the "C/l Abbrev" is still there on the bottom of the window). Any insights would be appreciated.
Most likely, you're hitting a bug in CC-mode, which results in a messed-up parse-state cache. The best thing you can do: M-x report-emacs-bug and try to come up with a reproducible test case. You can also try to upgrade to the latest Emacs (I know that the upcoming 24.4 has bug-fixes in that area, as did previous releases).
On OS X, I generated a set of ctags for the system includes using the following command:
ctags -f c -h ".h" -R --c-kinds=+p --fields=+iaS --extra=+q /usr/include
This was run inside of a ~/.vim/ctags/ directory, where I put all of the ctags I generate for system-wide header files (I also have stuff for ROS and CPP that I load conditionally, but that's neither here nor there).
Anyway. The ctags file is set correctly in my .vimrc, and vim can definitely see the ctags, but for some reason the autocomplete popup will only display results from #included header files if I write out the entire symbol and then start backspacing. As an example, if I #include <string.h> in a project, and then I want to call strlen(), and I start to type str in to the active vim buffer, I will only get results for symbols that are currently in the vim buffer. But, if I type out strlen and then start backspacing one or two characters and hit <C-n>, the popup menu will be populated with matches from any other included header files.
EDIT: Turns out, if I just hit "s" then <C-n>, it works as well. So the problem seems to be that it only works if the popup menu is launched manually. Which makes me think that it's a plugin problem (see below)
Additional information:
completeopt is set to completeopt=menuone,menu,preview,longest
I have OmniCppComplete, which I suppose could be interfering with the behavior. It is currently not being conditionally loaded for C++ files only. If you want me to edit and post my OmniCppComplete settings from my .vimrc, just ask.
I also have AutoComplPop installed, but I haven't done anything to configure it, so it's running with its default settings. Haven't really researched the plugin, so no idea if some of it's behavior could be interfering with the results.
I have AutoTag and TagBar installed, but those should only be fiddling with the current directory's local tagfile.
I'm honestly pretty new to Vim, and I just have no idea where to start debugging this issue, whether it be with a random plugin or with my .vimrc settings.
Vim has many specific completion mechanisms.
<C-n> and <C-p> use many sources defined by the complete option. By default, they will provide completion using the current and all loaded and unloaded buffers, tags and included files. While you can usually get quite useful suggestions with these, it is a bit of a "catch-all" solution: it is not reliable at all if you work on reasonably large projects.
<C-x><C-]> uses only tags so it may be a little more useful to you.
And there are many more, see :h ins-completion.
Omni completion is smarter: it typically runs a custom filetype-specific script that tries hard to provide meaningful completion. It is triggered by <C-x><C-o> and you can read about it in :h ft-c-omni. Omni completion is often a better choice when working with code.
Because you have two overlaping "auto"-completion plugins it's hard to say what completion mechanism is at work. You should disable those plugins and play around with the different completion mechanisms available to you.
I have not mastered this yet, but I do think the following observation may be of help.
Vim's default auto complete which can be quite noisy, often gets in the way of what you call with <C-x><C-o>. Specifically, I found myself calling up my tags based completions with <C-x><C-o> only to have them replaced with continued typing with Vim's default suggestions using my open buffers.
The suggestion of shutting off one of the plugins makes sense. In my case the key was how to shut down Vim's default behavior. I have seen several people (and to which I now include myself), set the length of the expression to a high number before triggering Vim's default. For me that is:
let g:deoplete#auto_complete_start_length = 99
... this way you eliminate the default layer of completions that comes and goes regardless of the commands you intended to inform your work.
This still feels like a hack but it helps keep my work focused on the tag-based completions.
FYI: I use NVIM on a Mac.
I've been working on a project I have to do for school,
They basically asked us to separate every question to a file of its own,
so what I was trying to do was comment the rest of the files or exclude them off the project, and when I try to 'Start without debugging', I end up getting this message. I did this before and everything was fine:
the weird part is that if i remove the solution and make a new one and only make one .c file it works...
I was also trying to remove the "Ex2" folder and made it again, it didn't help.
When I choose move to vault it doesn't find the file.
Edit: I've run a scan and it didn't find any infections on the computer and now that i'm trying to run the program i don't see the threat anymore, I only get this message:
Please, i would really appreciate some help (again... )
I it find very interesting that your build failed. As a result, it is HIGHLY likely that no output was built.Yet your virus scanner flags a compiled file.
If your code didn't compile, where did this executable come from?
Perhaps you do have a real virus?
It seems the last error, that is partially cut off, is "Link: Fatal Error LNK1104. Cannot Open File". That suggests that the file is locked, write-protected, or otherwise blocked.
Is anything else holding open your executable, which prevents recompilation?
I wouldn't blame your virus scanner from flagging an attempt to write to a running .exe as suspicious.
I'm attempting to build Firefox on my Windows Vista Ultimate machine. I keep getting the following error:
nsinstall: Bad file number
I've read that this error is caused because of UAC in Vista. Here are the two articles that lead me to this conclusion. https://wiki.mozilla.org/Penelope_Developer_Page#Windows_Vista and http://www.kevinbrosnan.net/mozilla-build-error-nsinstall-bad-file-number
Using the standard "Run as Administrator", I've attempted to redo my build but I get the exact same error. I also started a normal command prompt as admin and then went to the batch file in mozilla-build (start-msvc8.bat) and ran it. Still, same error at the same point.
Any other insights on how I might either get around this error or perhaps something else is causing the error?
Note: I also posted something here in the hopes to get topic-specific help but I've not heard a peep... After I posted that I found the info on nsinstall. Anyway, I prefer SO so I thought I'd try here...
Update: I've attempted to completly disable UAC to correct the problem as is suggested by cnemelkasr. I've received the exact same error. This new knowledge is making me think that a file or folder is missing... Does anyone who has experience with NSInstall know what the given error -- Bad file number -- might mean? I figure it might be referring to a file handle...
If it really is a UAC error, you can try turning off UAC altogether. I've had to do this for several packages. There are numerous places on the web to get the instructions for doing that.
http://www.petri.co.il/disable_uac_in_windows_vista.htm is one of them.
I found the answer to my question. I'm posting the answer here to share the answer with others and to close this question.
After disabling the UAC, it was suggested that the directory depth was interfering with NSInstall. I moved the folder from c:/Users/Frank/Documents/hg-repos/firefox-src-hgRepo/mozilla-fv-expirement/ to C:/mozilla-fv-expirement/. Cleaned all previous build attempts and finally redid my build (with UAC off) and I received a working debug binary.
The suggestion was posted at: mozilla.dev.builds
The "Bad file number" message in the cases I have seen, is caused by too many arguments passed to execvp (command, argv) (or similar) function. But only from some programs. An old bash, sh or a Borland/Watcom program in your PATH is an likely candidate.
So when you shorten the name of the build directory, the total size of the command line (that eventually gets passed to CreateProcess()) gets shorter. I don't think UAC has anything to do with this since I've seen this on Win-XP too. But it's a bit strange Mozilla would not use relative paths while building. I guess it uses some directory prefix value in it's makefiles (I've never tried building it).
If you look at the documentation for _execvp():
http://msdn.microsoft.com/en-us/library/3xw6zy53.aspx
E2BIG is one of the possible errno values:
The space required for the arguments and environment settings exceeds 32 KB.
Now, here is the strange part.
Fact 1:
On Visual-C/MingW (any version), strerror(EBADF) doesn't return "Bad file number" .
(it return "Bad file descriptor").
Fact 2:
On Borland's CBuilder 5.6 and Watcom 1.9 (these do not use the MSVC runtime), strerror(EBADF) does indeed return "Bad file number".
Theory:
Is possible that Borland, Watcom (and other CRTs too?) mixes up the meaning of E2BIG and EBADF. Did that make any sense? Someone please correct me if you have a better theory.
I'm a bit confused myself...
Conclusion: Either shorten the size of your environment (easiest) or shorten the command-line (not always easy).
--gv