I am working on a C++ project which makes extensive use of namespaces and doxygen. I prefer using the CHM file as compiled by MS HHC over the HTML directory for various reasons. One of them is the very convenient index search in the CHM viewer.
But the calls names in the index are always prefixed with their namespaces which forces the user of the CHM file to enter Namespace::Sub-Namespace::[...]::ClassName in the search.
Regarding this, I have changed the following settings in the doxygen configuration file (referring to the default that comes with the tool):
SHOW_NAMESPACES = NO
HIDE_SCOPE_NAMES = YES
This removes the namespace names everywhere except for the CHM index. (How) is it possible to get rid of the namespace prefixes in the CHM index as well?
As far as I know and tried with a small C# project the answer is - no.
One solution I see at this stage is to edit the resulting index.hhk and compile again by HTMLHelp Workshop. Please have a look into your index.hhk you'll find in your Doxygen HTML output subfolder.
The index.hhk file is a text file and can be openend by any text editor e.g. Notepad++. Having some namespaces only you make a RegEx for your needs and replace e.g. C_Sharp_CHM:: like shown in the screenshot below with NOTHING. But be careful using this and try before going to a production use case.
As you can see index.hhk is an old file format and not HTML as used today. Normally each index keyword has a link and a value (see screenshot, text format is edited here for better reading).
To compile the index.hhp you need to open the command prompt, navigate to your output folder and type "%programfiles(x86)%\HTML Help Workshop\hhc" index.hhp on a Windows 10 machine.
Does anyone know of a plugin where I can get the breadcrumbs of a file I am working on.
Lets say I am working on app/controllers/admin/crs/abc, So I can see this info at the top or start of the window.
I am using ember and due to pod structure its hard to know which file I am working as all of them have different folders but same names.
Simply edit your user preferences and add
"show_full_path": true
and the full path of the file will appear in Sublime's titlebar when the file is active.
Compare with the setting (OS X):
to without it:
I know this is an old question but still, I think this is an interesting Package that not many people know of.
On top of #mattdmo answer, you might even want to check the breadcrumbs for a nested structure (pretty much like you'd do in VS Code): just install Breadcrumbs for Sublime Text. Not as cool, but it works ok.
While using weka SVM ,the error is receiving "libsvm is not in classpath'.
I set the classpath through environmental variables, But the error still remains.I was using the weka svm for one year for data classification, but I haven't gone through this kind of problem. This problem surfaced when I have installed weka 3.6.12 after formatting my system. I am using window 7 32-bit PC. The error "jdbc.idbDriver is not in path" is also exists.
Open SimpleCLI in your weka GUI and execute following commands.
java weka.core.SystemInfo
Please look for following values
java.class.path: ./weka.jar;
...
weka.version: 3.6.13
As you can see, I do not have libsvm.jar in my classpath too.
I have to include using one of the ways explained in http://weka.wikispaces.com/LibSVM.
Below passage is taken from (http://weka.wikispaces.com/LibSVM Troubleshooting)
Troubleshooting
libsvm classes not in CLASSPATH!◦Check whether the libsvm.jar is really in your CLASSPATH. Execute the following command in the SimpleCLI:
java weka.core.SystemInfo
The property java.class.path must list the libsvm.jar. If it is listed, check whether the path is correct.
If you're on Windows and you find %CLASSPATH% there, see next bullet point to fix this.
On Windows, if you added the libsvm.jar to your CLASSPATH environment variable, it can still happen that Weka pops up the error message that the libsvm classes are not in your CLASSPATH. This can happen on Windows 2000 and XP and the %CLASSPATH% does not get expanded to its actual value in starting up Weka. You can inspect your current CLASSPATH with which Weka got started up with the SimpleCLI (see previous bullet point). If %CLASSPATH% is listed there, your system has the same problem. This Wekalist post explains how to explicitly add the mysql.jar to RunWeka.ini (works the same for libsvm.jar).
Note: backslashes have to be escaped, not only once, but twice (they get interpreted by Java twice!). In other words, instead of one you have to use four: C:\some\where then turns into C:\\some\\where.
Write a startscript that sets up everything for you.
The file could be called weka.bat und should look like this (untested- adapt as necessary):
WEKA_HOME=c:\weka
set WEKA_JAR=%WEKA_HOME%\weka.jar
set PATH=$WEKA_HOME;$PATH
set CP="%WEKA_JAR%;%WEKA_HOME%\lib\libsvm.jar"
set DIR=c:\weka\data
cd "%DIR%"
set WEKA_HOME=%DIR%
rem start small GUI Chooser
java -cp $CP weka.gui.GUIChooser 2 >>c:\weka\weka.log
This assumes that you installed weka to a dir called c:\weka,
that the subdirectories \data and \lib exist, and that you have copied libsvm.jar into the \lib subdirectory.
I'm wondering if there is a command or plugin for eclipse that will take a header file of mine and auto-generate all of the method stubs into the CPP file from that header? I've googled and the lack of results would say not so, yet I can see in the CDT preferences under templates that there is an option to enable stub generation... but cannot find the command to use it. Thanks!
Okay so, after doing some more searching I found the solution myself. In the header file, right click in white space and select "Implement Method" and a window will appear showing a list of method declarations within the header. You can select some or all, then click "Finish" and be done with it or "Next" to follow the rest of the guided wizard process.
Edit
I've noticed at times when using this that the formatting of the generated stubs can be screwed up, or can screw up the formatting of your existing CPP file. If that does happen, just right click within the CPP file white space, click "Source" and select "Format" to correct the issue.
Another Edit
For some reason after all this time, there's been a bunch of activity of people trying to edit my answer to change it completely. All the edit is trying to communicate is that there is apparently a CTRL+3 shortcut to bring up the implement methods window.
I got a little lost in the Eclipse CDT and could not find the Implement Method selection described above. So for clarity sake I am posting this.
In Eclipse CDT Mars (and maybe previous versions):
Right click on white-space inside the .h or header file. Initial menu appears...
Click on Source->Implement Method...
Popup window appears; check methods (stubs) to create in .cpp / implementation file.
.
You could also check out http://www.lazycplusplus.com/. It is more powerful than generating method-stubs. It generates header and source files. I managed to integrate it in Visual Studio, so it runs on every build. Maybe you can do that in Eclipse, too.
Edit:
On my blog http://itmuckel.de I wrote an article about integrating Lazy C++ in Eclipse. It works really good. Here is the direct downloadlink of the tutorial: http://itmuckel.de/wp-content/uploads/2016/04/lzz_integration.pdf
It is written in german, but the screenshots of Eclipse show the english version. Besides that Google Translate will do a good job, too.
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?