I have been using emacs for a while for mainly python programming, and have started C++ coding with it. When I open a c++ file, it opens without problems with c++-mode. The background and foreground colors are normal for the theme I have with color-theme, but keywords and strings are not colored differently. Below is the code in my .emacs to initialize color-theme.
(add-to-list 'load-path "D:\\emacs\\color-theme-6.6.0")
(require 'color-theme)
(color-theme-initialize)
(setq color-theme-is-global t)
(color-theme-hober)
I have not put in any code for c++. Any ideas?
Edit: I tried turning off color-theme to see if at least then there would be some coloring, and there was not, even after ensuring font-lock-mode was on. Also, this is GNU Emacs 23.1.1
Place the cursor over a keyword and do M-x describe-face. The face should be identified as font-lock-keyword-face and the description of the face given. At that point it should be easier to determine whether the keyword has the wrong face, or the face just has a default appearance. You could also double-check that font-lock-mode is on with describe-mode.
I finally got syntax highlighting by removing a folder called site-lisp from the folder d:/emacs. My Emacs installation is in d:/emacs/emacs-23.1, and somehow it was reading from these files. So, removing this folder forced Emacs to use the correct ones, I think.
(font-lock-mode) should help (with non negative argument to make sure it's turned on)
Generally this should work straight out of the box on a standard install - to verify start emacs with the "-q" option to avoid loading stuff from your init file. I have verified this with a quick install (on XP Pro) of the official 23.2 binaries. Here's the output: (apparently can't post images due to low reputation - the link is img444.imageshack.us/img444/2680/46117077.png).
If this displays code as you expect, then there's an issue with your init file - I suggest using the standard approach of commenting everything out and selectively adding things back in, until you come across the offending line(s).
Related
I have a CS class that requires (or at least strongly suggests) 8 spaces for C++ indentation. I normally use 2, so this is quite different for me.
I have until recently been just toggling the indent code in my .emacs and running eval-buffer, but that seems like a poor solution with a programmable editor.
So I am wondering: how might I go about creating a minor Mode (or is there a better function for this?)? I'd like to be able to enable it with M-x comp-mode or something similar.
I have seen minor modes, but they seem to instead focus on key mappings. Perhaps I am looking at the wrong Emacs feature.
Perhaps I can extend the C++ mode to create a comp-mode with different indentation settings?
You could probably do this with a minor mode, but an easier solution is to use directory variables. Create a file called .dir-locals.el in the directory containing your coursework and put something like this in it:
((c++-mode . ((indent-tabs-mode . nil)
(c-basic-offset . 8))))
I'm using VS2012 and I'm quite happy with it. But the problem is, whem I'm coding in C++, that the syntax highlighting is turning off an on all over again. Sometimes, the highlighting is off and I have to reload the file. Also, it highlighting is quite slow.
Does anyone know how to fix it?
I know this is a while ago but I have had this same problem appearing randomly until just now.
It would disable when the last line in a file was a single line comment. (// blah blah). As soon as i removed that the text highlighting worked again!
Edit: In this answer I assume that your problem description is correct. In other words, I'm assuming that occasionally C++ highlighting is working, and the other times the text appears as plain text: completely black and white.
My guess is you are using an extension which modifies or replaces the way Visual Studio highlights C++ code. Try temporarily disabling all of your extensions and checking again if the editor is working. Some extensions might have the Disable button disabled; in that case you'll need to uninstall the extension for this test (possibly through Control Panel → Programs and Features).
As an example of one common extension that completely replaces the C++ highlighter is Visual Assist. However, I do not personally use that product and I haven't heard of any specific problems with it of this nature. I am merely mentioning it as an example of an extension that completely changes the behavior of Visual Studio in regards to syntax highlighting of C++ code.
For me, highlighting always stops working when the first visible line in the editor begins with the characters '//' and I trigger reparsing somehow (CTRL + S for instance).
Highlighting always works fine when the first visible line in the editor begins with anything else, even with a whitespace, and I trigger reparsing somehow.
I could indent all my comments and never experience this problem, but now that I know about it, it's not so annoying anymore, so I let it be.
This is a bug in Visual Studio 2012:
https://connect.microsoft.com/VisualStudio/feedback/details/760154/syntax-highlighting-sometimes-not-working
If you're using only Intellisense, you may go to Edit->Intellisense->Toggle Completion Mode (or hit Ctrl + Alt + Space), play with it and see if it works (maybe you've pressed this combination of keys by accident).
I've also installed Update 3 and haven't had any problems since. Who knows..
I had the same problem. Disabling the extentions sadly did not work for me.
After searching around and realizing that it only happened on larger files,
I got it to work by turning harware acceleration off.
Tools->Options...->Environment->General
*Automatically adjust [...] (off)
*Use hardware graphics acceleration (off)
In my case, it turned out that a large block of code (a 200+ line method) was commented out with // starting in the first column, and this was causing the syntax coloring not to work. I changed the commenting delineation to /* ... */ for that method and all of the syntax coloring was fixed.
Personally, I found that things like:
#if 0// bla-bla
mess up syntax highlighting badly. The solution that works for is to put a space before a comment, like so:
#if 0 // bla-bla
I installed Visual Studio 2012 Update 3 yesterday and started experiencing the exact same behavior described in the original post. Based on some suggestions in this thread, I took at look at my extensions, and disabling AllMargins fixed the issue. I've since re-enabled AllMargins and everything appears to be working as it should.
Try disabling and re-enabling any of your extensions; hopefully that will fix the issue for you.
I made a simple regex search in Netbeans 7.3 on Windows (using Ctrl+F):
\{\{.*?\}\}
The results get highlighted correctly and the question is - how to extract highlighted text search results? Let it be copying to clipboard, saving as file or whatever else.
Is there any method doing this?
Maybe someone has any suggestion of alternative quick approach to such task in Netbeans? (or other editor)
What OS are you running? If OS X or Linux, read on!
I'm not sure about automatically copying the highlighted results to the clipboard, but I do workaround this quite a bit as well.
The easiest way to accomplish this for me without leaving NetBeans is to simply open a built in terminal window through Window>Output>Terminal (in 7.2.1) - I then navigate to my project, and run the RegEx that I built in the Find feature with my tool of choice. In fact, I use the built in terminal for this type of quick stuff in NetBeans quite a bit. If running Linux, using clipboard tools like xsel (http://linux.die.net/man/1/xsel) in combination with a built in terminal emulator can allow for devising some nice workflow shortcuts within IDEs if you are more comfortable working/coding at a terminal. Note that built in terminal emulators like the one in NetBeans is likely not going to play nicely with cut/copy/paste using the mouse, for various reasons that I won't get in to here.
As far as a built in/extension based solution for something like this, it would be helpful! I am not aware of one.
Hope this workaround helps in the meantime.
So, I've looked everywhere for a good rainbow parentheses plugin that will give different level parentheses different colors. I really like the couple that I've found, because they both do a good job of customizability while highlighting the right thing. It supports more than parentheses; chevrons, braces and brackets all get highlighted, which I really like.
It seems like there are quite a few plugins for this!; I'm currently using oblitum's because his is optimized for dark backgrounds (I often work straight from the shell).
So, following the tip at the github for that plugin, I have the "always on" snippet in my .vimrc. But when the always on block is above "syntax enable" it doesn't show {} as being highlighted for cpp files. When the always on block is below syntax enable, folding doesn't work. I think its the nature of the plugin that makes it do this; it goes though the file and adds coloration information. I notice that if I use the command :syntax enable after I've loaded the file when its not recognizing folds, then it does recognize the folds. But at this point, it removes the coloration that rainbow parentheses put on it.
In my .vimrc, I have the follow pertinent lines:
syntax enable
set foldmethod=syntax
set foldenable
set foldlevel=100
let g:rainbow_operators=2
au FileType c,cpp,objc,objcpp call rainbow#activate()
I think that, from looking at syntax files that come with vim, such as c.vim, you can see that certain blocks are annotated as folding. I bet that if you could just write a regex based upon it, you could identify characters as syntactic groups. Then you could just define a colorscheme for it. In fact, the rainbow plugin is actually calling "syn region" commands, so I think that this route is very doable, I'm just not that knowledgable with vim scripting.
Can anybody help me modify possibly the plugin or come up with a script or something that achieves both?
Sorry the lateness, I've tried to solve it at Fix disabled folding (issue #2)
I dimly remember having had the same or a similar problem.
Also XML code highlighting was broken IIRC.
I put 'always on' off, and activated the colored parentheses only when I needed it.
So my working solution was just a shortcut to toggle the plugin on and off.
I was going to create the C++ IDE Vim extendable plugin. It is not a problem to make one which will satisfy my own needs.
This plugin was going to work with workspaces, projects and its dependencies.
This is for unix like system with gcc as c++ compiler.
So my question is what is the most important things you'd need from an IDE? Please take in account that this is Vim, where almost all, almost, is possible.
Several questions:
How often do you manage different workspaces with projects inside them and their relationships between them? What is the most annoying things in this process.
Is is necessary to recreate "project" from the Makefile?
Thanks.
Reason to create this plugin:
With a bunch of plugins and self written ones we can simulate most of things. It is ok when we work on a one big "infinitive" project.
Good when we already have a makefile or jam file. Bad when we have to create our owns, mostly by copy and paste existing.
All ctags and cscope related things have to know about list of a real project files. And we create such ones. This <project#get_list_of_files()> and many similar could be a good project api function to cooperate with an existing and the future plugins.
Cooperation with an existing makefiles can help to find out the list of the real project files and the executable name.
With plugin system inside the plugin there can be different project templates.
Above are some reasons why I will start the job. I'd like to hear your one.
There are multiple problems. Most of them are already solved by independent and generic plugins.
Regarding the definition of what is a project.
Given a set of files in a same directory, each file can be the unique file of a project -- I always have a tests/ directory where I host pet projects, or where I test the behaviour of the compiler. On the opposite, the files from a set of directories can be part of a same and very big project.
In the end, what really defines a project is a (leaf) "makefile" -- And why restrict ourselves to makefiles, what about scons, autotools, ant, (b)jam, aap? And BTW, Sun-Makefiles or GNU-Makefiles ?
Moreover, I don't see any point in having vim know the exact files in the current project. And even so, the well known project.vim plugin already does the job. Personally I use a local_vimrc plugin (I'm maintaining one, and I've seen two others on SF). With this plugin, I just have to drop a _vimrc_local.vim file in a directory, and what is defined in it (:mappings, :functions, variables, :commands, :settings, ...) will apply to each file under the directory -- I work on a big project having a dozen of subcomponents, each component live in its own directory, has its own makefile (not even named Makefile, nor with a name of the directory)
Regarding C++ code understanding
Every time we want to do something complex (refactorings like rename-function, rename-variable, generate-switch-from-current-variable-which-is-an-enum, ...), we need vim to have an understanding of C++. Most of the existing plugins rely on ctags. Unfortunately, ctags comprehension of C++ is quite limited -- I have already written a few advanced things, but I'm often stopped by the poor information provided by ctags. cscope is no better. Eventually, I think we will have to integrate an advanced tool like elsa/pork/ionk/deshydrata/....
NB: That's where, now, I concentrate most of my efforts.
Regarding Doxygen
I don't known how difficult it is to jump to the doxygen definition associated to a current token. The first difficulty is to understand what the cursor is on (I guess omnicppcomplete has already done a lot of work in this direction). The second difficulty will be to understand how doxygen generate the page name for each symbol from the code.
Opening vim at the right line of code from a doxygen page should be simple with a greasemonkey plugin.
Regarding the debugger
There is the pyclewn project for those that run vim under linux, and with gdb as debugger. Unfortunately, it does not support other debuggers like dbx.
Responses to other requirements:
When I run or debug my compiled program, I'd like the option of having a dialog pop up which asks me for the command line parameters. It should remember the last 20 or so parameters I used for the project. I do not want to have to edit the project properties for this.
My BuildToolsWrapper plugin has a g:BTW_run_parameters option (easily overridden with project/local_vimrc solutions). Adding a mapping to ask the arguments to use is really simple. (see :h inputdialog())
work with source control system
There already exist several plugins addressing this issue. This has nothing to do with C++, and it must not be addressed by a C++ suite.
debugger
source code navigation tools (now I am using http://www.vim.org/scripts/script.php?script_id=1638 plugin and ctags)
compile lib/project/one source file from ide
navigation by files in project
work with source control system
easy acces to file changes history
rename file/variable/method functions
easy access to c++ help
easy change project settings (Makefiles, jam, etc)
fast autocomplette for paths/variables/methods/parameters
smart identation for new scopes (also it will be good thing if developer will have posibility to setup identation rules)
highlighting incorrect by code convenstion identation (tabs instead spaces, spaces after ";", spaces near "(" or ")", etc)
reformating selected block by convenstion
Things I'd like in an IDE that the ones I use don't provide:
When I run or debug my compiled program, I'd like the option of having a dialog pop up which asks me for the command line parameters. It should remember the last 20 or so parameters I used for the project. I do not want to have to edit the project properties for this.
A "Tools" menu that is configurable on a per-project basis
Ability to rejig the keyboard mappings for every possible command.
Ability to produce lists of project configurations in text form
Intelligent floating (not docked) windows for debugger etc. that pop up only when I need them, stay on top and then disappear when no longer needed.
Built-in code metrics analysis so I get a list of the most complex functions in the project and can click on them to jump to the code
Built-in support for Doxygen or similar so I can click in a Doxygen document and go directly to code. Sjould also reverse navigate from code to Doxygen.
No doubt someone will now say Eclipse can do this or that, but it's too slow and bloated for me.
Adding to Neil's answer:
integration with gdb as in emacs. I know of clewn, but I don't like that I have to restart vim to restart the debugger. With clewn, vim is integrated into the debugger, but not the other way around.
Not sure if you are developing on Windows, but if you are I suggest you check out Viemu. It is a pretty good VIM extension for Visual Studio. I really like Visual Studio as an IDE (although I still think VC6 is hard to beat), so a Vim extension for VS was perfect for me. Features that I would prefer worked better in a Vim IDE are:
The Macro Recording is a bit error prone, especially with indentation. I find I can easily and often record macros in Vim while I am editing code (eg. taking an enum defn from a header and cranking out a corresponding switch statement), but found that Viemu is a bit flakey in that deptartment.
The VIM code completion picks up words in the current buffer where Viemu hooks into the VS code completion stuff. This means if I have just created a method name and I want to ctrl ] to auto complete, Vim will pick it up, but Viemu won't.
For me, it's just down to the necessities
nice integration with ctags, so you can do jump to definition
intelligent completion, that also give you the function prototype
easy way to switch between code and headers
interactive debugging with breaakpoints, but maybe
maybe folding
extra bonus points for refactoring tools like rename or extract method
I'd say stay away from defining projects - just treat the entire file branch as part of the "project" and let users have a settings file to override that default
99% of the difference in speed I see between IDE and vim users is code lookup and navigation. You need to be able to grep your source tree for a phrase (or intelligently look for the right symbol using ctags), show all the hits, and switch to that file in like two or three keystrokes.
All the other crap like repository navigation or interactive debugging is nice, but there are other ways to solve those problems. I'd say drop the interactive debugging even. Just focus on what makes IDEs good editors - have a "big picture" view of your project, instead of single file.
In fact, are there any plugins for vim that already achieve this?