Many times I have come across situations where I need to repeat a code template several times, usually it's boiler plate code. The only thing that would change between different blocks is a few parameter names, which are peppered throughout the block. Is it possible to automate this in Vim without much effort?
snippets are like the built-in :abbreviate on steroids, usually with parameter insertions, mirroring, and multiple stops inside them. One of the first, very famous (and still widely used) Vim plugins is snipMate (inspired by the TextMate editor); unfortunately, it's not maintained any more; though there is a fork. A modern alternative (that requires Python though) is UltiSnips. There are more, see this list on the Vim Tips Wiki.
There are three things to evaluate: First, the features of the snippet engine itself, second, the quality and breadth of snippets provided by the author or others; third, how easy it is to add new snippets.
Related
I found that arguments list is more useful than buffers list. With vim-airline plugin you can see all current buffers in the topbar. I wonder if there is a similar plugin or function to always display argument list? It would be useful if it could work together with vim-airline.
No, this is a bad idea. The argument list is frequently used for mass-editing many (hundreds) of files, and those wouldn't fit anywhere in the UI. That's why I'm also no fan of permanently displaying the buffer list. [1]
With tabs, windows, and buffers (and dozens of related commands), Vim has very powerful means to deal with multiple files. Each person's workflow is unique; you need to find your very own, personal one by learning the available commands (the :help is very comprehensive), and trying out different approaches.
[1] From a functional standpoint, buffer and argument lists actually are very similar. Both can be added to, removed from, and used for mass operations. It's only that the adding to the buffer list is done automatically.
I am a plugin lover, and apart from the time spent learning the Vim editor, I also try my best in mastering its plugins. However, if a plugin forces me to unlearn Vim-specific habits & commands, I generally try to avoid them.
This brings me to the topic of EasyMotion.
The plugin revolves around the concept of visual navigation, and provides the user with several visual textual tags to which the user may jump.
Now what I am getting at: Is this good practice?
Because it sure feels to me like it attempts to replace some very basic Vim skills & habits.
Examples are:
Writing quick search queries & regexes
Practicing eye coordination with boundary-jumps (say 4w, 2E, 14j for example)
It is the single installed plugin I have refrained from using due to this uncertainty, although this discussion could easily be applied to most plugins in some degree.
There's no standardized "best practice", if that's what you are after. There's only "what works for me". Well… and "what bloggers say and commenters repeat" but that's usually worthless.
If you don't like how it works and/or it doesn't provide you any benefit, don't use it. It's that simple.
I don't like EasyMotion because the red characters and the overall dimming make me actually loose my target and I have to re-scan its area to find my target again. It may not be bad design generally speaking (I think it is), but for me it doesn't work at all so I don't use it. Simple.
What works for me is /foo and ?bar in combination with set incsearch. That's what I use hundreds of times a day. Simple.
Because the default feature works for me I don't have to look for a solution.
And the corollary: there's no use looking for a problem when you find a shiny new solution.
By scrutinizing the documentation, I have learned that Emacs haskell-mode ships with three different, mutually exclusive methods of automated indentation. They are called haskell-indentation, haskell-indent, and haskell-simple-indent. Can anyone explain how these methods are similar and how they are different? I am interested not only in individual features but also if one is a de facto standard or if one or two are no longer maintained.
Really, as far as I am aware from asking people, there is no de facto standard, people have strong opinions about which they prefer but with little specific evidence other than “it works for me in most cases”.
The haskell-indentation package and haskell-indent packages are the most popular:
both have a tab cycle
both are complicated code-bases
both have plenty of edge cases where they break down
Each will Do The Right Thing in different cases, but again, there are no unit tests, no real parser, etc. just a bunch of special cases that the author(s) happened to think of, so the documentation and understanding on how they behave in a rigorous sense is sparse. haskell-indentation understands more Haskell than haskell-indent, but plenty of people will tell you, including me, that you spend a lot of time cycling through indentations to get to the right one.
The haskell-simple-indent package has no knowledge of Haskell, it only knows about column alignment and it does not have a tab cycle, it has indentation and de-indentation. This is the version I use because of the aforementioned edge cases in the previous modes, which can be rather distracting at times.
I think with such libraries it will be difficult to describe their differences other than anecdotically at this point. I would welcome some rigorous comparison (though time may well be better spent writing a better mode).
simple-indent is maintained by me. I don't know whether the authors of the others are actively interested in maintenance.
I believe that the 3 modes you mention correspond to the 3 haskell-modes descibed in this article, namely;
haskell-indentation == Tab Cycling
haskell-indent == Rectangular Region
haskell-simple-indent == Aligning Code
However since I'm not 100% sure, I'll look into more when I get home.
haskell-indentation and haskell-indent are misleadingly similar, both offer cycling through proposals via repeated typing of TAB which is their main feature IMO.
However haskell-indent is definitely my favorite, mainly because it will propose certain completions that are quite useful:
repeating a function name for you after you've written the type signature
repeating a function name for pattern match
pipes for case branches
I just recently switched environments and had to re-setup emacs, and used haskell-indentation by mistake, and boy did I miss these. OTOH, you might find some of these completions annoying; what's more they don't work in certain cases: if your function starts with an underscore, or (worse) if you're bird-tracking.
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.
I've been using Lisp on and off for a while but I'm starting to get more serious about doing some "real" work in Lisp. I'm a huge Vim fan and was wondering how I can be most productive using Vim as my editor for Lisp development. Plugins, work flow suggestions, etc. are all welcome.
Please don't say "use emacs" as I've already ramped up on Vim and I'm really enjoying it as an editor.
Limp aims to be a fully featured Common Lisp IDE for Vim. It defaults to SBCL, but can be changed to support most other implementations by replacing "sbcl" for your favourite lisp, in the file /usr/local/limp/latest/bin/lisp.sh
When discussing Lisp these days, it is commonly assumed to be Common Lisp, the language standardized by ANSI X3J13 (see the HyperSpec, and Practical Common Lisp for a good textbook) with implementations such as GNU Clisp, SBCL, CMUCL, AllegroCL, and many others.
Back to Limp. There are other solutions that are more light-weight, or try to do other things, but I believe in providing an environment that gives you things like bracket matching, highlighting, documentation lookup, i.e. making it a turn-key solution as much as possible.
In the Limp repository you'll find some of the previous work of the SlimVim project, namely the ECL (Embeddable Common Lisp) interface, merged with later releases (7.1); Simon has also made patches to 7.2 available yet to be merged. The ECL interface is documented in if_ecl.txt.
Short-term work is to do said merging with 7.2 and submit a patch to vim_dev to get it merged into the official Vim tree.
Which leads us to the long-term plans: having Lisp directly in Vim will make it convenient to start working on a SWANK front-end (the part of SLIME that runs in your Lisp, with slime.el being the part that runs in the editor - the frontend).
And somewhere in between, it is likely that all of Limp will be rewritten in Common Lisp using the ECL interface, making Limp easier to maintain (VimScript isn't my favourite) and being easier for users to customize.
The official Limp site goes down from time to time, but as pointed out, the download at Vim.org should always work, and the support groups limp-devel and limp-user are hosted with Google Groups. Don't hesitate to join if you feel you need a question answered, or perhaps even want to join in on development. Most of the discussion takes place on the limp-devel list. If you're into IRC, I'm in #limp on irc.freenode.net as 'tic'.
Good luck!
You might give slimv a break.
Here's a cool diagram by Xach that sums up the current situation.
Here we are 9 years later, and now we have Vim 8 and Neovim, both providing the ability to interact with plugins asynchronously.
vlime is an excellent, feature-rich plugin that takes advantage of the new async interface to provide a SLIME-like dev environment for Common Lisp.
Check out the Limp plug-in:
http://www.vim.org/scripts/script.php?script_id=2219
SLIME for EMACS is a wonderful tool for LISP programming. The best part is sending code written in your editor straight to a live LISP session. You can get similar behavior out of Vim using the tips here:
http://technotales.wordpress.com/2007/10/03/like-slime-for-vim/
I adjusted my own script so that I can send to either a SBCL or Clojure session. It makes you much more productive and takes advantage of the REPL.
":set lisp" starts the lisp indentation mode for Vim. But it won't work with some dialects like Clojure. For Clojure, use VimClojure.
Some people like LIMP also.
:set lisp
Vim has a mode to help you indent your code by Lisp standards.
Also, I modify the lispwords to change how vim indents my code.
:setl lw-=if (in ~/.vim/ftplugin/lisp.vim)
You can give Emacs with Vim emulation a try, is not perfect, but it may be somewhat familiar. I think Lisp shines if you use something like Slime or DrScheme doing iterative development, all other editors feel just wrong.
Vim add-ons: Rainbow Parentheses, Lisp syntax
SBCL add-ons: rlwrap, sb-aclrepl
Workflow: Ion3 (or some other tiled WM) with multiple terminal windows.
Edit Lisp in Vim
Switch to Lisp window (using the keyboard of course)
Use C-r to recall the line to reload the ASDF system in question so your changes become active.
Use X Window copy/paste for small snippets/changes.
Use DESCRIBE, TRACE and APROPOS heavily.
Repeat.
There seem to have been attempts at having a SLIME-like integration of Lisp in Vim, but none have really gone as far as needed to be really useful. I think ECL's integration has been done, though, but not committed upstream.
You should find all relevant links from Cliki's page about Vim.
I know you said not to tell you to use Emacs.
Use Emacs.
Serious, the SLIME setup for Emacs is pretty much the standard development platform for Lisp, and for very good reason.