Related
I am trying to find a good IDE. I always found Vim's modal behaviour interesting but, Vim is more of a text editor than an IDE. Even though I have made a few changes to my .vimrc file Vim isn't IDE enough. Any suggestions?
FYI: By IDE I mean it's got to have a debugger, autocomplete and easy compilation
Edit: I do web development, backend node.js, python and Ruby on Rails
I'd start by listing features you need from your IDE in order of importance.
Think about (random order):
Language support (native support/need to import specific plugin)
project tools support (eg. cmake, maven, gradle, so you can easily switch between different environments)
editor power (make your changes fast, refactor easily, repeat changes, shortcuts and tricks etc.)
version control support
easy to use
completion, snippets, etc.
speed (how long it takes to launch, how much memory/cpu it consumes)
compilation speed/support
Of course you can consider many more features and find them much more important than the ones I listed here. It's totally individual preference, since that's you who has to be comfortable.
If you want to use the power of VIM you have basically three options:
1. use VIM, customize it and make it your unique IDE, totally adopted to your needs
Start with vanilla VIM and incrementally add settings and plugins you need. Check out existing configs and adapt them. To make it fully fledged IDE I'd recommend some plugins:
CtrlP - fuzzy seach, really powerful, must-have
NerdTree - classic file browser
vim-dispatch - for deployment, fast and easy
vim-git, vim-gitgutter, vim-fugitive - for awesome version control
xptemplate, supertab, syntastic - for autocompletion and snippets
vimgdb - for debugging
2. Use existing VIM config
I recommend one of these:
Example VIM configs
or this:
janus
3. Use IDE with VIM plugin/mode
Many of today's top IDEs have vim-mode or vim plugin easily available. For C++ I recommend QtCreator, because it's really fast and easy-to-use, and it's FakeVIM mode works really well. For JVM-based languages I recommend IntelliJ IDEA, because it's really powerful and stable. It's VIM plugin also works really well, and you can easily mix IDE's shortcuts with VIM commands, adapting it to your needs.
Both can be customized with many useful settings placed in your home directory (for IntelliJ it has to be .ideavimrc).
To be good at vim you need time, but it will eventually pay off
The mindset 'hunt for cool plugins to assemble your IDE' often leads to suboptimal solutions
Start with a small .vimrc and maybe a small amount of plugins (if you tell what is your programming environment people could help you here)
Use what you have for a while and observe where are you spending most of your time struggling
Search for a way to alleviate that problem and repeat
Get use to read vim help (:h). It may sound boring but is one of the best sources to really grok vim and that will bring you closer to the 'vim mindset'
Vim is an investment, not a tool you can decide to start using by tomorrow and be good at it.
If you want to spend most of your time coding (text editing) and are willing to put the time and effort it will pay eventually off and you would be very efficient. If you don't accept this it can be frustrating and make you quit.
Take a look at this: What is your most productive shortcut with Vim?
It also depends what your programming environment is. Having autocomplete and compiling from in the vim editor is no problem. Debugging depends, but you can also do debugging with other tools and be perfectly fine. Just because other IDEs do it doesn't mean it's the best way.
Don't try to get it perfect just from the beginning and don't try to copy every feature your known IDE has. Accept the initial pain and enjoy all those little improvements that you can make every single day. All those improvements will sum up and after a while you will be very proficient. Even years after you still will find ways to improve your workflow.
There has been recent development in (at least) those three projects, based on nvim extensibility, and addressing your very concern:
oni
veonim
gonvim
[update] lunarvim
I seems that they are all in early alpha though, let's hope the best for them :)
I have installed the spf13 package with tons of plugins for testing.
When I type a ( or a " or anything that looks like the beginning of a comment, a plugin adds the corresponding closing character ) or ".
How could I find which plugin is the "culprit" ? In general, what is the logical way to investigate such category of question ?
Vim "distributions" like spf-13 and Janus lure you with a quick install and out-of-the-box settings, but you pay the price with increased complexity (you need to understand both Vim's runtime loading scheme and the arbitrary conventions of the distribution) and inflexibility (the distribution may make some things easier, but other things very difficult). Vim is incredibly customizable, using someone else's customization makes no sense.
That said, the functionality is from one of the available auto close plugins that apparently ships with spf13. In general, if you need to find out which plugin is behind a mapping, the :verbose map command will tell you where the mapping comes from. In your case, this is likely triggered by the ( key in insert mode, so the query would be:
:verbose imap (
The only sane way to deal with plugins is to go shopping yourself when you need something that's not available in Vim (assuming you actually tried to find a built-in solution to your problem first) and read the plugin's documentation thoroughly. That way, you'll take control of your configuration and never come across an unexpected behavior.
Distributions like the one you installed pretend to make configuration simpler by forcing all kinds of plugins and settings and unnecessary complexity layers onto unsuspecting newbies thus actively preventing proper learning.
I suggest you drop that crap as soon as possible.
As for "the logical way to investigate such category of question", you'll have to go through all your plugins to find the plugin responsible for that unwanted behavior.
FWIW, I know the name of the plugin but it is very important for you to go through that process on your own.
No tool is perfect, and I'm about to start several long-term projects using Trac, and wanted a heads up of the kinds of problems I may or may not experience with it. In other words, Trac meets my needs in the short term, and I've already made the decision to use it, but I want to know what to expect down the road.
I am not looking for:
"Use product X instead of Trac because..." answers.
"Trac is great because..." answers.
A comparison to any other specific system.
"Trac doesn't support Feature X" answers. I can read the feature list too, thank you very much.
I am looking for:
"Feature X does not behave as expected..."
"Trac behaves oddly when..."
"Trac doesn't fully support..."
"Trac itself has a known bug that will likely never be fixed..."
And especially "Trac can't handle..."
etc
So, what Trac-induced headaches do I have to look forward to?
For future reference, this question was asked while Trac v0.11 was the latest stable release.
There is still no common view on how to handle multi projects. If this is not your case - the rest should work for you.
One issue that I have run into with a long-term Trac instance is the 'version' field. There is no distinction between the list of versions that can be assigned to a ticket, and the list of versions that can be queried for in the custom query interface. So if the version list for that field starts getting cumbersomely long, you can't really trim it without limiting what you can search for.
One of these days I'll get around to fixing that...
Trac 0.11 is rather more of a resource hog than 0.10 was; in large part due to the switch to Genshi for the templating engine. You may want to keep an eye on resources on the server, memory in particular. I expect to see some increased attention paid to performance in 0.13 or so.
Oh, and if you run into problems, #trac on freenode can be a nice resource.
Disclosure: I'm one of the Trac developers
We've used Trac for several years with multiple projects. After thinking for a minute I still can't come up with any significant problem to list.
http://trac-hacks.org/ticket/131 - Persistent Logins (i.e. persistent login session cookies across browser restarts) is still not committed.
It means when you get your svn post-commit mail with the trac link then
if your browser isn't already loaded (remembering your login) you have to enter your credentials to see content (depending on how you have security set). This is only an issue if you only trust a certain class of users on your network. Browsers remembering credentials mitigate this, and for high-security situations you may not want the option at all, but for us it is slightly annoying.
0.12 is quite close to release, i would go straight for r9125 trunk or thereabouts:
multiple source repository support (branch landed in trunk with r9125)
live text editing previews
ticket comment editing with diffs are
those are three primaries why i went ahead and moved all my envs into 0.12dev. there are many more minor nice things that make a difference over 0.11, though.
i think running trac out of SVN working copy provides very nice upgrade and general manageability, so that is what i would recommend.
multiple project support is the biggest culprit so far and i'm looking to put in some work myself to improve that situation.
When someone else reassigns your ticket, you don't get notified.
I recently started picking up vi, going through some tutorials and trying to get used to it. But I still have some questions about it.
It seems to be nice for small one file changes, but as soon as I start to try doing bigger things it seems to be lacking. For example I'm used to have code formatting, import organizing, simple overview over all packages and other things that an IDE gives me. I saw some tutorials on how to use vi as an IDE, but it felt awkward at best.
Now I'm just wondering, what are the typical use cases for vi? Is it typically used to edit small files, or can it be used for larger projects? And if you use it in larger projects, how do you make it work? Or would it be a lot easier to use an IDE with vi keybindings?
People use non-IDE editors like Vi(m) for coding due to the following reasons,
They are non-distractive, allows you to concentrate on the job.
They do not clutter you screen area, offers you more code space
They are faster
They have better/faster/cooler text manipulation at the stroke of the finger
You happen to move your hands out of the keyboard less to hold the mouse, drag it here and there and click.
They also have the flexibility to support other tools like debugger, document viewer, etc.
They also have ways to get things like code folding, etc.
For a normal programmer whose ideal work cycle is sit, write code, test, debug, more code, test debug.. Vi offers a simplistic yet powerful environment to get the work done faster and more efficiently.
For someone who had years of using some IDE, it might be like using some prehistoric tool, but once they have been through the initial days, then there is no looking back. They'd feel like there is no better thing.
Why, oh WHY, do those #?#! nutheads use vi?
I've haven't done anything that you'd call a big project in python (only little test scripts), but I use Vim exclusively for writing large embedded C applications and I have never really felt the need for an IDE.
Vim is fast to start up, extremely fast to use and (with a bit of customisation) can do most things that an IDE can do. It'll do code completion, code auto-indentation and reformatting and it is very good at refactoring. The project plugin http://www.vim.org/scripts/script.php?script_id=69 makes it very easy to manage projects with lots of files and the taglist plugin http://www.vim.org/scripts/script.php?script_id=273 is great for browsing source code. It also allows you to have the C code open side-by-side with python code, assembly code and latex documentation without having to use a different tool for each.
Overall though, I think there is one really valuable thing that Vim gives you that very few other editors do and I would find it very hard to lose that: I can have a window split into three parts like this:
Each of the subwindows can either show a separate file or (as in the screenshot) a separate part of the file. I imagine emacs can do this (although I could be wrong), but I doubt many IDEs can. This can be invaluable for refactoring and for referring to other parts of the file.
I've used VI(M) and Emacs as my primary editors for years... I've tried switching to IDEs but find they can't get out of my way enough. I always end up back in VI(M) or Emacs after a while. One major reason is that I find my hands need to leave the keyboard too much in IDEs as they require the mouse too often... And I'm too lazy to setup my own shortcuts for everything.
Here's why I use it.
it's fast to start up
it's available across multiple platforms and is on all Unix machines
it's fast to use (keystrokes for common operations, operations based around words/paragraphs etc.)
However, I use IDEs for large scale development work, since I can't believe they can be beaten for productivity, given their code-awareness and refactoring capability. I use Eclipse, but I plug a VI editor emulator into it. See this answer for more details.
I saw some tutorials on how to use VI as an IDE, but it felt awkward at best.
There's one thing to do at the very beginning: throw your sense of aesthetics overboard. You will never get the same kind of graphical experience in VIM as you do in a decent IDE.
That said, VIM actually does offer many of the features of a full-blown IDE and has a lot of advantages besides. I use VIM for almost all of my developing work and all of my text documents (using Vim-LaTeX) – even though I've actually paid money for Apple’s office suite, iWorks.
There's one point that's still nagging me, though: I can't get IntelliSense to work. For me, that's a huge problem, especially when using languages such as VB, C# or Java, for which excellent IDE support exists.
So, the learning curve for VIM is steep but once you've passed a certain point it's everything but awkward. In fact, compared to VIM's editing experience, you will find that it's the IDEs that suddenly feel awkward because while they're good at bookkeeping stuff, they suck at editing.
I frequently work on a remote system, programming for a cluster, or editing config files on a headless box. All of these could be done with a file transfer, a regular IDE, and another file transfer, but it is so much faster to just use VIM through SSH.
You can find it (or easily install it) almost anywhere - Runs on all systems that can implement the standard C library, including UNIX, Linux, DOS, Windows, Mac, BeOS, and POSIX-compliant systems.
The ability to log into a remote server and confidently edit a config file is priceless.
Vim is not very good at code awareness. What it is good at is text manipulation. It provides you with the tools for you to edit text, not to edit for you. If you just do "small" edits and don't read up on the occasional "vim commands you wish you knew" you'll never understand the power provided.
code formatting
Formatting is done with =. You can also point equalprg to an external program to do the formatting for you.
import organizing
Vim won't be able to remove unused imports but if you select the import lines
:'<,'>sort
simple overview over all packages
:vs .
This will open a vertical window containing the current working directory :)
In conclusion, vim can't replace your IDE but it will let you edit your text.
As usuall: Choose your tool depending on the work you have to do! ;-) I'm using Vim and Visual Studio. You don't have to choose only one.
If you need an IDE, use an IDE. Vim is made for text manipulation.
It supports any languages. Try to edit a Ruby script with Visual Studio.
Performance on large files is much better than for most IDEs. Try to analyze a logfile having 100k lines and more using your IDE.
It runs on many plattforms and you can use it via a remote console, if you have to edit files on a server.
...
IDEs are specialized tools, which are good for problems they are made for. Vim is an incredible flexible and powerfull generall purpose tool.
This is obviously a hot topic so I'm going to give a list of reasons why I prefer IDE editor for coding.
1) I prefer to be able to fold sections of my code (I don't know whether Vi(m) can) without having to remember the command to do so or type it.
2) I prefer one click compile button/command as opposed to having to remember my compile command and it's library of options
3) I prefer the easier highlight copy paste operations without having to........ aah sod it!!
Well by now you get the picture. I'm not knocking Vi(m) I just think having your the elements and functionality of your coding environment visually represented makes for a clearer head and encourages exploration of options you may not know exists.
I much prefer vim over vi and prefer not to lump them together. Vim provides some features that are really handy and not always immediately obvious. Already mentioned was screen splitting. Also you may want to checkout ctags or exctags. These allow you to jump around the code base from within vim. I can place the cursor over a called method, jump to the definition, jump to a definition within that method, etc. Very powerful for tracing down bugs. Cscope is another similar program.
Vim will also allow you to run arbitrary shell commands within the environment and has powerful search and replacement features.
So an IDE will provide most of those, what will vim provide over a traditional GUI based IDE? That's easy, it runs on the CLI.
This allows me to login to my dev box, run screen (definitely something to checkout for the unfamiliar: http://www.gnu.org/software/screen/) and run multiple vim sessions within my screen session on my dev box. Now when I leave work for the day, I can leave my work session just as I left it, even while running builds. When I come into work the next day I can connect from my environment as if I never left.
Another reason to like vim or vi in particular, is that it can be found on virtually any Unix environment.
Recently I've been doing lots of weekend coding, and have began to really need a bugtracker as things are gaining speed. This is probably the worst case scenario because I basically have to let things cool down over the week,so I simply can't remember the bugs in my head. So far I've been using a text file to jot down bugs,but I'd rather use something a bit better.
The biggest points here are ease of use and very little setup time.Don't want to spend more than an hour learning the basics and trying to install something. Also in my case I'm on a Mac so that would help, but solutions for other platforms are welcomed as they will likely help others.
FogBugz has a student/startup edition that's free indefinitely, for 2 or less users.
Personally, I use Excel. (Wait, come back, I'm not crazy!) For a bigger / team project, I've gotten a ton of mileage out of Bugzilla, but that tends to be kind of overkill for a one-person project.
But, a well-organized spreadsheet, with columns for things like "status", "description", "code module", "resolved date," etc, gets you pretty close to what you'd need for a small project. Sorting a spreadsheet by column isn't anywhere near a search, but its a whole lot better than "find in text file."
Heck, if you use Google docs rather than excel, you can even publish the thing as an RSS feed and get it anywhere.
And, the major advantage is that the setup time and learning curve are both effectively nil.
Addendum: And of course, the instant your "One-Person Bug Tracker" becomes a "Two-Person Bug Tracker" you must switch to something better. Bugzilla, FogBugz, anything. Trust me, I've been there.
Trac or Redmine are both pretty good. I don't know how easy they are to set up on a Mac.
It's worth mentioning that FogBugz also has a free version for up to 2 users, which would suit you. It is hosted so there is no installation and you can use something like Fluid to access it in its own window.
I don't think you need a full blown bugtracker for your scenario.
Try tiddly wiki, store each bug in a tiddler and give them tags like 'open' or 'closed'.
There is no installation required (only one html file), and it's very easy to use.
And platform neutral.
If you're working on a LAMPP stack, then for ease of setup and use I would probably recommend Mantis. It's written in PHP / MySQL and the only installation involved was specifying where the database should be created and what credentials should be used.
Oh, and its FOSS.
I would suggest Omnigroup's Omnifocus - it's an excellent task tracker, and if you just make the mental leap from bug to task, I think it works famously for one man projects as well as being an excellent way to organize your no doubt burgeoning task queue.
Eclipse has a really interesting system--I don't know why so few people seem to know about it.
It's tied in with their to-do list. It gives you the ability to enter bugs with as much or as little info as you like. You can tie it to versioning or an external bug tracker if you like. It's a decent bug tracker in itself.
The real trick is how it works with your source code.
Before you begin work you select a bug from the list. All the time you're coding, it tracks what files you are editing. It can close old tabs for you, and will also highlight areas of the source tree that you have modified a lot.
The nice thing is, you can go back to any bug you've edited an you will get your "Environment" back. Not only all your notes and stuff, but the same tabs will open up and the same sections of code in the navigator will be highlighted.
Also eclipse works with virtually any language, it's not just restricted to Java...
let me put in a good word for ditz - it's a bit bare-bones, but it has the invaluable feature that bugs are checked into your repository. it's also very easy to use once you get used to its way of doing things
You can use fogbugz for free if you're a one man team.
It's super easy to use and quick to learn.
They made it so that bugs are really easy to enter, no mandatory fields.
I'm the author of BugTracker.NET mentioned in another post. If I were looking for a tracker for JUST ONE PERSON with MINIMUM hassle, I'd use FogBugz, because it's hosted. No installation, no need to worry about backups.
But, what are you doing about version control? Don't you have to worry about that too, and backing that up? If so, consider something like Unfuddle or CVSDude where you can get BOTH Subversion and Trac, or Subversion and Fogbugz.
I use Mantis at home and I'm happy with it. It can be a pain in the arse to get it working so you can choose to download a free and ready-made VM installation. Cannot be easier than that,
Maybe a spreadsheet would be the next logical step? I know it sounds really un-sexy, but if you're the only user, you don't have to worry much about others mucking it up, and it adds a few basic features over a text file like sorting. Then if you later need to graduate to something RDBMS-backed, you would likely have a feasible import path. I just know that for me, when working by myself, I don't tend to get around to putting bugs in anything that requires more care and feeding than that (of course when working with others the collaborative needs make a more defined repository a requirement, but that's a different story).
EDIT: After noting the availability of free, hosted access to FogBugz, I'm re-thinking the bar for care and feeding...
RT from BestPractical is great.
I also get a lot of mileage out of just keeping a list of items in a text file with vi, if I can express them all in one line. This is usually for many small todo items on a single component or task.
I've tried bugtracker.net and even though it's a little bit rough on the edges, it's free and was built with ASP.NET:
http://sourceforge.net/project/showfiles.php?group_id=66812
Are you using a source control repository as well? If not, you really should, even though you're only a one-man team.
My personal preference is to use a VMWare Virutal Application (free) that offers no-hassle setup gives you access to both Trac and Subversion. You can find many different virual appliances through searching. Here is one example of getting a Trac/SVN virtual appliance up and running:
http://www.rungeek.com/blog/archives/how-to-setup-svn-and-trac-with-a-virtual-appliance/
Trac is an excellent project management tool that sports a bug tracker, wiki, and integrated source control management. It's adaptable to your needs, and fits me very well personally.
I use bugzilla for this purpose. Plus for me was that it has integration with Eclipse (precisely with Mylyn). FogBuzz has it to but AFAIK it is nonfree.
Plus it sits on my laptop so I can code and add/remove bugs when offline (it was biggest disadvantage of hosted solutions for me)
Installation was not a problem in Ubuntu (and any debian-based distro I suppose).
I dig ELOG in those cases, it's more of a personal blog, but it's easy to handle and install, the data is local on your computer and you can search all entries via fulltext. Always sufficed for me.
If you have a Windows box with IIS and MSSQL (including SQL Server Express), you should look at Bugtracker.net. It is free and open source (you get the source code), and it is extensible.
Even if you are a one man shop, having a free bug tracking system with this much power will allow you to grow over time, because it is fairly easy to add future users into the system.
You can also customize it for the look of your organization, business or product.
Ontime 2008 by Axosoft is free for a single user licence. It's industrial strength and will give you alot more that just bug tracking!
http://www.axosoft.com
Jira which now has free personal licenses.
I am using leo for this purpose. To be more specific, its cleo plugin.
Of course you might need to spend some time to get used to leo, but it will pay off.
A flat text file is just a list, an Excel spreadsheet is a two-dimensional list.
leo lets you keep the data in a tree! And it also has clones.