I'll just leave a shameless plug for my neovim GUI project here: https://github.com/vhakulinen/gnvim. It has a WIP PR[1] for implementing multigrid support, which would allow features such as scrollbars.
I just tried this. I get rendering artifacts when scrolling.
BUT! The scroll speed is absolutely wonderful. I've tried all the UIs and always find myself going back to the terminal, but this is something else.
Although I have to say fvim looks tempting as well and vimr(I'm not on MacOS anymore).
For those people mocking vim users and bragging about their IDE's. With languageserver and the other kind of refactoring daemons available for a whole host of languages nowadays these editors are much closer to IDE's than ever before.
The only things that are not really first class citizens are IMHO:
1. refactoring(outside of C++ and Java)
2. profiling
3. breakpoints
EDIT: I'm quite happy with the tmux setup I have but thanks for the suggestions. The main problem I see with neovim is that the separation of the python library while nice for update iterations causes issues with virtual environments.
>Although I have to say fvim looks tempting as well
Visited its page to have a look... I'm not sure why they'd put a screenshot with a variable width font, which automatically puts lots of people off when it comes to coding...
It's like having a screenshot of your bitmap editor, and showing it editing goatse.cx...
The option to use proportional fonts is a very rare feature in vim-like text editors (the only other way I know of is to use terminal vim in mlterm), so for people who want this the screenshot is good advertisement.
In fact, after reading you comment, I promptly startet to install it (still compiling as I type this). My use-case is creative writing: I'm very used to vim keybindings from coding, but prefer to have a variable-width fonts for writing.
fvim author here.
The font in the screenshot is `Iosevka Slab` which _is_ monospace -- `fvim` currently syncs with the neovim grid system and doesn't support proportional fonts well.
Sorry about the confusion -- I think you've already discovered that (after 46 minutes)!
>The font in the screenshot is `Iosevka Slab` which _is_ monospace -- `fvim` currently syncs with the neovim grid system and doesn't support proportional fonts well.
Aha, looked like a proportional font was used to me. I'd use a more well designed monospace font for the first impression!
I'm not going to mock you, but why not just use an IDE with a vi(m) mode or plugin in the first place, if you really want all those features?
Modern IDEs are following a platform + plugins architecture that is probably as flexible but more robust than whatever you can tape together around vim.
vim modes in IDEs are often inadequate (if this is not immediately obvious, you probably just don't use vim as fully as possible). The IDEs are often (too) complex in the sense of a hodgepodge of GUI options and menus which are hard to navigate. You often can't put the IDE configuration in a version control system easily. IDEs are often sluggish. The plugin system for vim is superior to most IDEs.
It's not that using an IDE with a vim mode is not a possible viable alternative, but it's a game of trade-offs, as usual.
I agree completely. For me, for now, I have vscode with vim emulation. I find that it's more convenient to have everything vscode has + vim keys for a lot of things, than have all of vim + try to make vim do what I like from vscode.
I really hope in the future I'll find the time to do that, but for now I am content. It's always a trade-off.
Have you noticed any sluggishness when using Vim commands in VS Code? I use nvim + tmux as my go to and it's pretty responsive (still has trouble catching up to me sometimes) but I often have to wait for VS Code.
I have to wait sometimes, but normally it's fast. It's only when (I think) somehow the vim emulation bugs out that I need to wait a couple of seconds or just hit esc 5 times. Thankfully it's not often.
Only if you run it without any plugins. Unfortunately if you have a lot of third party packages, vim startup times start to get closer to emacs startup times (both of which are still better than any IDE I have used, of course). I keep a vim.norc alias in my alias file which launches vim with an empty .vimrc for this very reason.
Strange. I use 15 plugins and according to the --startuptime flag NeoVim takes 32ms to start. Vim takes about twice as long, but that's still so incredibly fast I'd call it instant. I guess when it comes to plugins there are some real heavy-hitters out there that I somehow managed to never try.
You could use autocmd for filetypes that require plugins, so they don’t load for configs/texts. If your pm of choice allows this separation, ofc.
I’m not very experienced with complex plugins, but most of what I’ve seen did nothing unless explicitly initiated. Maybe there are global variables to control that.
> With languageserver and the other kind of refactoring daemons available for a whole host of languages nowadays these editors are much closer to IDE's than ever before.
Most likely true, though i think the "I" part of "IDE" is woefully ignored and (at least to me) is much more important than a hodgepodge of barely related programs strung together with duct tape.
That's precisely what every single python IDE does. They take isort, black, jedi or whatever other engine together and stitch them together in a user transparent way.
Omnisharp was literally the attempt of MonoDevelop to create an open source alternative to the Resharper engine.
The completion agents for VIM or VSCode do the presentation layer for the lower layer(the language server daemons, or custom completion agents. YouCompleteMe however is all that together in one not as fancy but I like it).
I get where you're coming from, but basically the difference is that vim by itself is a raw editor and until neovim came along never made an effort to merge the functionality that was required for something like this to happen in a nice fashion.
Editors like Oni are basically distributions like VSCode with defaults that are more inline with what you say plus a nicer presentation layer.
Yeah well, it isn't like Python IDE are much better :-P. I think in general most languages with unix-ish background do not tend to have truly integrated development environments as unix was always about stitching together stuff. Only Borland somewhat managed to make real integrated environments for their C/C++ tools and even then it wasn't as good as the stuff they had better control over (turbo pascal, delphi, etc).
Java and NetBeans is (or was, before Oracle botched it) probably the best IDE (in terms of integration) for a toolset with a unixy background.
Though none of those compare to something like Smalltalk, Lisp or even Microsoft's QBasic and (pre-.NET) Visual Basic.
Note that i'm talking about how integrated the IDE is with the language and its tools, not about how good or bad the language is.
I think this isn't about unix tools or philosophies. It's about the fact that for a very long time these big monolithic projects didn't really allow any integrations.
Vim didn't allow integration because there was no way interface to it, and it's not an easy codebase. Neovims work is proof of that. C++ compilers didn't allow integration because they were big monstrous projects and when you need to do proper c++ indexing you basically need to compile the whole project.
For C++ this changed with clang and even for clang it took a lot of iterations and bugs inside of libclang to allow for this capability.
Naturally one of the best C++ IDE's was therefore also by the producer of their own compiler (Visual Studio).
These boundaries are slowly fading, so these arguments are kinda moot. A few examples:
No i think it is actually about philosophies (or at least a way of looking at how software should be made) - again, i point out to Borland (whose IDEs were always provided a way more integrated environment than anything Microsoft ever did - e.g. for C++ MSVC always called out to a separate compiler program that had to reparse/restart its state for each file whereas BCC had the compiler as part of the IDE executable that would keep state across compilation in memory and even use the editor text buffer for 'input' if there was one instead of loading a file from disk) and Smalltalk (where the IDE and runtime are the same thing, you are modifying a live environment with tools written in that same environment instead of cold-running everything from start).
libclang might be a bit closer but it still is something separate from whatever IDE it is used for.
Honestly i do not believe it is even possible to what the sort of integration i'm talking about by stitching together separate projects no matter how many extension points and hooks those projects provide - by definition they aren't made with a singular coherent vision where everything is meant to work together, instead each project has its own idea of how it should work.
MSVC could in theory be able to do that since the IDE is made by the same company as the compiler, but in practice the teams behind it are probably acting as separate "sub-companies" inside the bigger organization. They're not seen as a single "C++ development environment" project but as two separate projects that happen to communicate with each other.
I'm not sure if 'philosophy' is the proper term here, but it is certainly about how you believe that software should be made and having that in mind at all times when designing it at all levels - be it the functionality to provide or how that will be implemented (e.g. a compiler that runs as a simple standalone application can just use globals for the state and perhaps not even free memory at shutdown - see dlang as an example - whereas a compiler meant to be integrated as a library cannot do that).
As an example, for a Borland-like approach (at least based on my understanding of it), adding a language extension to -say- provide meta-data for classes wouldn't be something that only the compiler developers cared about, but something that the developers of the compiler, the debugger (for being able to display the meta-data), the IDE (for editor auto-completion and automatic code editing - later Borland IDEs could modify the code - and debugger UI), the framework library (for taking advantage of it and providing a 'best use' scenario), etc. And all of those would influence the new functionality instead of being something that was added by the compiler team and then the rest would have to support (as it is done by pretty much every language that only exists as a standalone compiler or interpreter without any concern for IDEs, debuggers, UIs, etc nowadays).
If you're using pango 1.44, that is a known issue and there really isn't a proper workaround yet. Quite a few applications using grid based applications are currently broken with pango 1.44.
I am happy with Neovim in a terminal too. But I wanted I wanted it running as a separate application that I could launch and switch to, so I downloaded the iTerm2 source code and changed the icon and application name and created a profile that just runs Neovim. I find this works well, but maybe someone knows a simpler way, or a generic way, to do this on OS X?
I think you can use an applescript for that. I think you can compile the applescript to a .app and then run it. But it's been a while since I was in OSX
I just wish vim+languageserver would catch up to where vim+mlcscope was fifteen years ago. (Specifically, finer-grained distinctions that just references to a symbol, e.g. assignments and calls.)
Both neovim-gtk & gnvim are great but don't integrate nicely with standard ctrl + c, ctrl + v actions which is super frustrating.
VSCode with vim plugin handles this well with the Use Ctrl Keys option set. If you're in insert mode, ctrl + v will paste, otherwise ctrl + v will start visual mode. If you are selecting text, ctrl + c will copy.
Adding a bazillion one-off options like "Use Ctrl Keys" to avoid creating mappings, defeats the purpose of using vim, since creating mappings is the bare minimum way to configure it. (But Vim did so anyways for Windows, in the form of the "mswin.vim" plugin, which is enabled by default, causing confusion for users expecting vim to behave like vim.)
I wouldn't even know where to begin to approach these mappings as they are highly context dependent. If it is possible with just normal vim mappings then that'd be excellent.
A different way of tackling this if you don’t mind doing it “the vim way”: Most vim builds enable the + register to access the system clipboard (hopefully these two do so too, I haven’t verified!). “+p = ctrl+v, “+y = ctrl+c etc.
If you’re unfamiliar with registers look them up in the docs they are super useful. (Also have a look at the 0 register, e.g. “0p)
In addition to sibling comment - does any vi(m) work with the (non) standard (for vi) ctrl-v/c out of the box? I understand setting the star/plus as default registry so that paste and yank read/fill the system clipboard. But using ctrl-V for paste is surely alien?
Nothing wrong with custom keybindings, obviously. But it sounds rather non-standard?
> multigrid support, which would allow features such as scrollbars
also per-window font-size, dimensions, line-spacing--so Nvim UIs can add unlimited decorations to windows while the editor navigation remains exactly the same (driven by Nvim).
Looks nice, but I'm a bit surprised to see "No web bloat!" and then Webkit in dependencies. Is the UI built in web technologies, just not in Electron this time around?
I don't use vimr that heavily, but a few times now I've seen it chewing on the CPU when I've left it open in the background. I do use neovim heavily and haven't seen that.
I want to take a moment to thank the Neovim authors, as a VIM user. Thanks to you, VIM has felt the pressure and greatly improved, including the vim 8 async plugin feature (which has now trickled-down in all distros).
I can now use coc.nvim and ccls to have an IDE-like experience inside vim, which really helps reducing further the write-compile-test-fix loop.
Never attempted to make the move (friction, sizeable vimrc). I've mostly been using the distro builds, which for neovim often meant an outdated version.
I can also admit that I've benefited from the project, even if I've never used it. Like everyone using Firefox is currently benefiting from WebRender, despite never moving to Servo.
We often find criticisms of forks in OSS (waste of resource, we should work together through a common goal), but the truth is that this flawed mechanism allows for innovation and experimentation. Which is also why the BigCos that ship different competing products (say, messaging apps), are often the most innovative because it prevents (some kind of) in-fighting and cookie licking.
Agreeing with another response: I have a vimrc that I've accumulated over something like 20 years, I kept putting off switching to Neovim because I anticipated it would be a headache, and in the end it only required something like half an hour to make the switch, probably less. I would classify it as "easy peasy".
Speaking for myself; vim's always available whereas I have to faff about (especially on older systems, or where I'm not admin) to get neovim working.
The .vimrc files seem to have to live in different places meaning the scripts I've written to install vim/vim-plugins will need to be altered.
Some plugins don't work properly.
I've never got neovim working on windows (can't get the colours quite right)
I tried the built-in terminal and thought it was a great idea but struggled to seamlessly hop between panes, pipe the output into files and open in other windows or copy/paste them. Tmux solves all those problems so I never use the terminal (and if I needed to it's in vim now).
I liked the attitude of the project, but I still have no use for it. One idea which might make sense would be for the vim project to accept the neovim source; merge it back in as vim 9 so all the great refactoring, and other functionality is available for everyone and any wasted effort on two almost-identical projects is avoided.
The most interesting fact about this release - from my personal point of view - is that I don’t care. I am usually very interested in updates to software I use often. nvim/vim is a program I use every day but I never had the feeling that it was lacking anything. I never ran into bugs. I don’t even have the feeling that I will grasp all of its features anyway not to mention the countless plugins. And I expect this upgrade to be stable and frictionless as in recent years. A tremendous achievement compared to all the other programs I have the pleasure to work with.
Somewhat off-topic, but that's how I feel about Sublime Text 3. It's fast. It's snappy. It handles MB-sized files with ease. I use it for text editing, small scripting (shell scripting, JS), repetitive text transformations that can be reduced to a macro, and things of that sort. Anything heavier goes into an IDE.
> nvim_open_win: create floating windows (and external, for supporting UIs)
I've been running 0.4.0 since it came out for this feature.
Also I recommend you check out coc.vim for the best completer. It uses the same language server protocol that VS Code uses (and many of the plugins for coc.vim are forked fr VS Code plugins)
All completers will be able to utilize floating windows immediately, so it's not a special feature of coc.nvim. Using LSP is also not unique to coc.nvim. Deoplete, for instance, supports both as well. I personally have no interest in using coc since it's a javascript based project.
Yes, I wasn't trying to say it's only possible to use with coc.vim, and neither was I trying to say that LSP is unique to coc.vim. But I would not recommend Deoplete.
Just to make sure I understand correctly, that floating window is entirely within neovim (i.e. it isn't a separate window as far as your window manager is concerned)? And if that's correct, does this mean that it would work if you SSHed into a server?
Also, if I am not mistaken, the code that handles the multiplexing (multigrid) was not made only for this feature, but a generalization that improves a lot of capabilities for GUIs.
This is reasonable enough, but personally I'm not really convinced a text editor should be handling windows at all, especially since neovim allegedly is designed to be embedded by a ‘real’ UI (and presumably could be embedded by a terminal-based UI that handles windows—or just uses tmux).
I do recognize that I prefer software to be simpler than most people (for the record, much of the time I use ed(1)).
That's an extremely cool party trick but I'm also slightly concerned that neovim started to cut bloat in vim and ended up implementing a compositing window manager with fake transparency.
Though the idea is just pretty damn cool in general so I can't get too grumpy about it.
On the bright side, this is actually a demonstration of the extensive work the neovim team has done cleaning up the UI layers. justinmk's comment above goes into more detail, but basically vim has gone from having a single array of characters that gets manipulated by every type of display item to windows with their own positioning and dimensions. In addition, these windows will be exposed via APIs that external GUIs can use.
I have been using LanguageClient-neovim[0]. It is great, the main difference I have observed between LanguageClient-neovim and coc.vim is that LanguageClient-neovim provides a more vim centered UX (e.g. it automatically populates location/quickfix list with errors, warnings and hints which enables quickly jumping between error locations) while coc.vim provides a great out-of-the box experience but feels like VSCode strapped to nvim (It has its own extension ecosystem based on VSCode extensions) - I greatly appreciate the effort by coc.vim's developer, he has done great work and coc.vim defiantly has its advantages[1] over LanguageClient-neovim. LanguageClient-neovim requires a lot of customization in order to fit it to your work flow but once it is done, the experience feels a lot more native. On the topic of which, LanguageClient-neovim feels lighter and faster to me and has the added advantage of being usable without any external dependencies (because it is a compiled binary). I highly recommend checking it out.
tl;dr:
coc.vim is for those looking for a VSCode like experience out of nvim (stuff works out of the box requiring minimal customization, installing plugins to get the required functionality) where LanguageClient-neovim is for those who prefer a vim centric approach (extremely minimal, manually customizing everything to get it to fit you workflow).
If you are interested in LanguageClient-neovim you can checkout my config[2][3] you might find it helpful .
No problem, LanguageClient-neovim can be a bit overwhelming at first and if you are like me, you might need to rely on the included docs and GitHub issues, but it is well worth it. I am in my spare time working on getting floating window documentation working for completion items once that is done, I will have no need to keep coc.vim installed as backup.
The vim tricks I got used to in the past 15 years are neat for a quick remote edit, however, nowadays I enjoy RAM eating smart editors like vs code and intellij which makes me satisfyingly efficient without remembering to use my shortcuts.
What I do is mostly refactoring, finding files by name or contents and moving cursor to places I've been in which provides seamless navigation between files as well.
It's possible to get a best of both worlds setup if you try. Have you tried the Vim plugin for VS Code?
The VS Code plugin is interesting in context of this Neovim update because it will actually use parts of Neovim as a "native library" to speed some operations (mostly ex commands), if Neovim is installed.
Here's a random question for Vim users who might know Kakoune...
What can be done to make Vim behave like Kakoune? Odd question, I know. As a former Vim user, I switched to Kakoune about a year ago and absolutely love it. The multi cursor behavior, and selection before action combined to make a really excellent and visual experience.
With that said, after 15 years in the Terminal, I tire of it. I want a GUI. Neovim has made some great advancements to getting users out of the Terminal (should they want that), and I envy Neovim users! Yet, I can't get away from Kakoune.
Is there any hope? Appreciate any replies, thank you.
Say you want to replace the contents inside a pair of matching parentheses. Instead of ci( type vi( and if you are happy with the selection, then type c -- that takes an extra keystroke, but gives you visual confirmation of what you are operating on.
Or slightly differently, and this is useful only for "c"hange, add "$" to your cpoptions (that is, :set cpoptions += "$" in your vimrc).
When making a change to one line, don't redisplay the
line, but put a '$' at the end of the changed text.
The changed text will be overwritten when you type the
new text. The line is redisplayed if you type any
command that moves the cursor from the insertion
point.
I don't think the amount of people using any of the various (afaik all rather alpha-stage) GUI frontends is very high at all, at this point.
People use nvim in their terminal, and that will likely be the case for a long time.
In any case, there are many multiple cursor plugs for vim, now also supporting operator pending.
And :substitute includes built-in real-time preview.
So, I used Vim for years - but frankly I only used what I needed. I never played vim-golf extensively, so please don't take what I say as the reasons I enjoy Kakoune as evidence of shortcomings in Vim. With that said:
Kakoune's multi-cursor support sort of blew my mind when I first started using it. Combined with the always selection first model of Kakoune, it means you can plop down 10 cursors, navigate around, select, reduce and etc all of them separately will actively viewing what they have selected. Finally when you get all the selections you want, you can act on them. That's really my main workflow that I just have to have.
Plugins may perhaps solve my issue. We'll see. I also am not sure how realistic living entirely in visual mode in Vim is. I'm not too well versed in visual mode, so I can't speak on it too much.
Kakoune has really been a joy for me. I just want more advanced features that Terminals can't provide (multi fonts, more UI elements, etc)
Last time I checked neovim-qt on mswin, it couldn't make an explorer association due to non-standard command-line treatment, rendering it useless from gui pov. Reporting an issue got some friction, but now it seems that they fixed that. But from double-clicking .txt to editing it spends 2 seconds. Vim just opens instantly.
Also, neovim doesn't respect scroll amount setting, scrolling three fixed lines per scroll step instead. But I have set it to 6.
set guifont=* -- simply doesn't work
set guifont=Consolas:h10 -- "font reports bad fixed pitch metrics". What?
set linespace=3 -- it changes, but doesn't care to redraw contents (except the cursor) or resize a window so it could fit in a screen. If you're going from 0 to 3-4, it is not even obvious why everything froze and you can't : into command mode (it is simply hidden under the bottom of the screen).
I know that they're after fixing some internals that are hard parts in Vim, but if you're replacing a horse with a car, make sure it is more comfortable than a bicycle. I also know that neovim-qt is NOT neovim core, but...?
I really hope at some point we get one official blessed GUI implementation per platform a-la gVim and we don't have to pick and choose which particular one has the least shortcomings.
The most notable for all Vim users is probably forcing upstream vim to merge async support for plugins after refusing it initially; albeit with a different API. (there is quite some bitterness on both sides of this issue, I think)
The other big win is providing a embedding API so other editors can be built on top of the core editing engine. Which resulted in multiple interesting GUI projects which you can find in other comments.
Others are Lua plugin support, good terminal integration, way better default settings, ...
That's more to do with how you setup to trigger the commands.
Async here really means that it doesn't block with your typing, jumping around in the text editor if plugin starts doing some heavy work in the background due to some action that got triggered by whatever event you had setup for plugin to do. One of the plugin that I particularly remember was syntastic (I haven't kept up with it to know if they've fixed this or not) that would just create janks every now and then if the workload was heavy.
I have been running it for quite a few months and there are two improvements that I can think of:
1) In visual mode you have a block cursor and in insert mode it is a |.
2) With ':set inccommand=nosplit' you get live previews for substitution calls. For example :%s/foo/bar/ will update your foos on screen whilst you type the command.
Otherwise it is pretty much a drop-in replacement without issues.
No crashes here and I use it all day pretty much every day.
They only real negative in my view is the startup time which is noticeably worse than vim for me. Advantages I see are
- unix clipboard and middle mouse pasteboard both work out of the box without having to recompile (ie "*p and "+p and the corresponding yanks just work) whereas on vim for whatever reason I always have to rebuild my distro vim and faff about with terminals for ages
- the substitution preview thing above is really great
- the "terminal" window type which I don't use much but a lot of people do
- the fact you have native support for python3 and python2 plugins simultaneously. Don't even want to think about how many goats had to be sacrificed to build that feature but it's cool
- the ":checkhealth" diagnostic screen that gives you useful info to allow you to easily fix any problems you're having with terminal and plugin setup
> They only real negative in my view is the startup time which is noticeably worse than vim for me.
Check that this is not e.g. due to Python host detection/setup - you might have plugins that trigger both py2/py3 hosts to load for example. (hosts can be configured explicitly to skip it)
Also check `nvim --startuptime /tmp/nvimlog`.
I generally start vim in my src folder on Monday and exit it on Friday. Occasionally, just on a whim, I run nvim instead. Mostly its fine. But the times I've experienced crashes or other hickups like rendering bugs forcing me to :qa!, it's been on nvim.
Edit: Oh and I run it in the terminal, iTerm2 to be precise.
I wonder if any 2-4 of the folks who’ve never had it crash would find it fun to join in a mob-debugging session where you screenshare, we all open an discord* channel, and we try and figure out the cause and solution.
——
(* IM could be discord, gitter, slack, or whatever.
I’d argue strongly against IRC because I think the lack of support for code blocks and especially newlines makes it harder to talk about code/stacktraces.)
It also exists because the vim BDFL refused to merge some patches, notably async (vim did get async after it was proven a success in neovim). Since the fork neovim has modernized and cleaned up the codebase, and has an ambitious feature roadmap which includes adding Lua as a plugin language and adding APIs for external GUIs.
I use CoC.vim [0] with whatever Python plugin they recommend and it's easily been the most painless autocompletion I've ever used in over a decade of Vim. I wrote some (admittedly pretty basic) Python with it last week with no complaints!
The python plugin that is recommended has switched from `pyls` to the Microsoft Python
Language Server (the same one that powers the Visual Studio Code Python extension),
written in C#. The extension comes bundled with a .NET Core interpreter.
I use LanguageClient-neovim[0] with pyls[1], tests are run using `:make` which populates the quickfix list with errors. I also heavily use the location list which gets populated with errors and warnings etc. automatically by LanguageClient-neovim. All of this is accessible through convenient keybindings. Full python setup here: https://github.com/L0stLink/anvil
Status bar is lightline[2] with a custom theme, which I haven't gotten around to pushing yet. I can share it if you are interested. Other than the colors on the bar everything should work.
here is a function that takes a buffer id and creates a floating window based on it anchored to current cursor position:
let s:buff = 0
let s:buff_max_heigth = 12
function! CreateTempBuffer(buffer) abort
let text = nvim_buf_get_lines(a:buffer, 0, -1, v:true)
if s:buff == 0
let s:buff = nvim_create_buf(v:false, v:true)
endif
call nvim_buf_set_lines(s:buff, 0, -1, v:true, text)
let height = len(text)
if height > s:buff_max_heigth
let height = s:buff_max_heigth
endif
let width = 0
for index in range(len(text))
let line = text[index]
let lwd = strdisplaywidth(line)
if lwd > width
let width = lwd
endif
let text[index] = line
endfor
let width = width + 1
let opts = {'relative': 'cursor', 'width': width, 'height': height, 'col': 0,
\ 'row': 0, 'anchor': 'SW', 'style': 'minimal'}
let win = nvim_open_win(s:buff, v:false, opts)
return win
endfunction
The terminal is common to many operating systems and keyboard shortcuts leant there are pretty universal.
If you prefer a keyboard driven workflow learning to use a terminal and terminal based editor will give you a very portable solution.
Vi's commands are somewhat like a language for manipulating text. This is a different philosophy to many non-modal editors. In vi you can say change the next 3 paragraphs to foo or replace the text inside the this tag with bar. When you learn the language it's almost painful to watch someone trying to select text with a mouse. (I realise GUI tools often have vi plugins. I think that only proves that modal editing is useful and ergonomic once you've learnt how to use it).
CLI based tools are also very scriptable where that is often not the case for GUI based tools. Vi/Vim/NVim are part of a wider ecosystem of tools. If you learn the Ex commands for things like substitute/replace in Vim you're taking a step along the road of learning sed also.
You mention a lot of scripting, and also the terminal.
Would you also recommend vim for working on large projects with 100+ files? I believe in this case, a full on IDE is suited better.
Also I'm not so sure about the portability. Sure, some of the knowledge is reusable, but when all the vim installations are not "batteries included", every installation will be configured differently.
Another point: I think with strongly and statically typed languages one shouldn't think about writing code as writing text, but about building a syntax tree that happens to be text.
I think vim with a fuzzy finder plugin like FZF will easily handle 1000s of files not 100s. The project I'm currently working in has 6495 files, I don't regard that as a large number.
You would be surprised by what Vim can do out of the box simply by turning features on. It's also very easy to move configs about. I use github for that job but I can use Vi/Vim without a config if needed.
However what I really mean by portability is that once set up I have exactly the same shortcuts on both my own mac, client's linux laptop and servers. Currently I use tmux for window management but I could use NeoVim for that now. If I want to open a split terminal window or move an existing one about it's exactly the same short cut on each machine.
> Another point: I think with strongly and statically typed languages one shouldn't think about writing code as writing text, but about building a syntax tree that happens to be text.
That's in no way tied to a GUI and there's nothing to stop you adding IDE like features to an editor like Vim. The terminal is just another way of representing tooling to the user.
However if you prefer a GUI interface then nothing stops you from using that in preference to the terminal either. I only point this out as the grand parent asked why we would bother in 2019.
> Would you also recommend vim for working on large projects with 100+ files? I believe in this case, a full on IDE is suited better.
I do that now.
IMO, it depends on the language. For C#, nothing beats Visual Studio. For all of its warts, the autocomplete, go-to-def, and debugging just work too well. I do use a Vim plugin in it. It's missing some features that full Vim has, but the other advantages make up for it.
For Ruby, Python, etc, I think pure Vim wins, including with large projects. I know it's possible to get autocomplete support in Vim, but never found it to be worth the trouble for those languages. No issue in handling a bunch of files with Nerdtree and CtrlP. I think the terminal is better for actually running the program and related tasks than any IDE environment I've tried. Especially with Tmux to spin up new windows easily and switch between them, all without ever leaving the keyboard.
It is true that vim installs tend to be highly configured. IME, the bone-stock Vim on servers is easy enough to live with for the purpose of editing a couple of config files. Wouldn't be thrilled to use it on a large project though.
I'd say language support is the most important for productivity if we talk about programming. Having the whole API under your fingertips, doing safe refactorings easily, etc. are much more important for productivity than simple editing. If you can refactor a class, move functions, rename variables across the whole project safely (string replace is not enough) with a few clicks then you are much faster than when you have to do all of these manually.
I'm saying that as an emacs user. I prefer emacs, but if I had to work with a language (e.g. Java) where language support is much more sophisticated in a tool like, for example, IntelliJ, then I'd use that instead, because it would make me much more productive.
First of all, I don't know about vim/neovim, but I think a lot of the issues apply there as well.
When I develop software, I don't need an editor, I need a development environment. I spend 90% of my time reading code, so reading and navigating the codebase should be very straightforward. Most importantly I want to have a tree view of the files in the project, I want to be able to jump to function/class definitions and I want to show usages of functions.
Another big thing is debugging. IntelliJ has really good debugging capabilities.
Also auto-completion.
I think some of these you can get in vim/emacs, but it doesn't come out of the box. I sometimes miss some of my emacs shortcuts/features, but not enough to drop all the amazing things that IntelliJ is offering.
I often switch between several programing languages, I often switch between projects, I like being able to dig into the code source of some tarball I found online without configuration. I find that deep editor integration gets in the way more often than not.
For navigating the project I use helm on emacs, fzf on vim. I can just fuzzy-match anything I'm looking for instantly. I find filesystem treeviews useless, they use a lot of screen real estate and they're annoying to navigate, I don't see the point.
For navigation ripgrep does most of the job complex language engines do and it works across languages without any configuration. For C I sometimes use cscope and ctags but even there I often just call ripgrep because why not?
For auto-completion I also find that a very naive algorithm completing words from existing buffers works reliably and efficiently, with zero configuration and tweaking. Sure you don't get context-aware completion but that never bothered me too much to be honest.
For debugging I can't really disagree with you, both Vim and Emacs are very limited in that regard (Vim especially so).
That being said, maybe if I gave those big IDEs a chance I'd never go back, who knows. Besides I could spend an hour listing things I think Vim and Emacs do wrong so it's not like I think they're perfect editors.
Tree view and go to def plus basic autocompletion (through tags) are very much built into vim.
The rest can be done through plugins, these days very painlessly - but admittedly even a few years ago rather a hassle to set up.
Debugging, while perfectly doable depending on language, is I'd say the one thing still rather awkward.
For most of the code reading tasks that you list I would use a bash terminal in the project directory. What is the advantage of having them as functions in your editor?
>language support is the most important for productivity
That is a great point, and this is precisely the goal of the Language Server Protocol[0] (LSP). I agree that dedicated tools have more sophisticated support but LSP is quickly bridging that gap. With how extensible editors like vim and emacs are coupled with there powerful text manipulation capabilities the development experience offered by them in combination with a good Language Server and Client is not to be underestimated. Although editor ergonomics are very subjective so I know this topic can get very controversial.
In terms of what's been available for developers I'd agree with you that IDE's (especially JetBrains and especially for languages like Java) have had an advantage for some time. Language Server Protocol is taking this advantage away. It's not as if turning code into AST and transforming tree data structures is out of the reach :P.
Love vim but would hate to use it for Java where I found an IDE such as Eclipse much easier to work with. Back in the day when I used to do that sort of thing.
I feel like I need a PhD in configuring vim to do that stuff. The fact vim has been around forever and still hasn’t caught up with an IDE for ease of use doesn’t convince me at this point to use it for coding Java. Eclipse/IntelliJ is simple download and everything ready to go, git integration, all kinds of auto complete , debugger, etc... you hit the ground running pretty much. Can’t say the same about vim for Java, but think it’s fantastic that progress is being made to close the gap. Now where’s the simple one line config command to get me started ;) ....
Since Vim/NeoVim take a "batteries not included" approach to set up I'm just happy that we've gone from a state of "you have to use an IDE to get code aware features" to "it's hard to set up code aware features in NeoVim".
Hopefully other projects such SpaceVim or individual plugins can provide an easier path for those that want it. I think it's on NeoVim's own road map to add LSP support out of the box.
Of course it's also worth pointing out that whilst it's nice that NeoVim is learning new tricks nothing about having better CLI based tools available means that you can't still use GUI based IDEs if that suits your use case better.
I don't see there's a reason to use vim locally as other editors are far advanced when vim isn't changing at all.
But there's a use on the server side because you only have vim or emacs there.
As someone who's been doing sysadmin-ing things for a while... (10+ years) I don't think I've ever seen Emacs installed on any server where it wasn't maybe pulled in as a dependency by something else. Emacs is almost never installed by default, you could instead install micro (https://micro-editor.github.io/) instead, use normal keybindings, and call it a day :-)
> As someone who's been doing sysadmin-ing things for a while... (10+ years) I don't think I've ever seen Emacs installed on any server
Chances are the Emacs-users are working on files on that server remotely via TRAMP, from their nicely and 100% personally customized Emacs-installation.
Why bother replicating all that setup on a server when you don't have to?
True, but that also means that as someone who regularly SSHes into servers, you don't need to learn anything about Emacs. For local stuff on the servers, vi(m) is always there (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/v...), for remote operation you can use any other editor ranging from Emacs + TRAMP to VS Code + remote extension to ...
Ugh, Eclipse is disgusting. IntelliJ is much better, and also has a very nice VIM-mode plugin(last time I checked Eclipse one's were bad), so, I prefer having it both ways. Comments mocking vim(like the original parent) are really missing it badly, nothing has so much staying power for no reason.
It's a shame English doesn't distinguish between non-inclusive-we (the writer and the writer's peers) and inclusive-we (the reader, the writer and the writer's peers).
Non-inclusive-we 'need' it because we want it and will make it ourselves. Inclusive-we do not because your individual needs were never and should never be the concern of a project that you have no investment in.
Because we haven't come up with anything better. Neovim, Vim, or Emacs combined with
Unix make a better IDE than an IDE.
With a fuzzy finder, Neovim start up in milliseconds and can scale to projects with
several thousand files, complete with documentation, symbols, reference jumping, and
refactoring. An IDE just turns my laptop into a space heater with minimal
configurability and fewer features. In other words, I am investing more battery life
for a weaker program. If I need to use someone else's computer (or a container), I
can run Vim with my config file right in the terminal and never notice the difference.
The features I need:
1. FOSS
2. A reasonable amount of battery, CPU, and memory usage. The editor should not bring
a browser/JVM with it. Browsers eat RAM and need to be restarted within a couple
days of uptime, and the JVM kills the battery.
3. Cross-platform; should work on Linux and BSD.
4. Should scale to large projects with thousands of files.
5. Should support advanced features with something like the Language Server Protocol.
6. Minimal UI and keyboard-driven; screen space is often limited, and I hate the mouse
with a passion.
Vim and Emacs are the only editors I have ever used that have all of the above
features. Nothing else comes close.
I didn't get why this was important until I started working on a remote cluster. The only environment was the shell. Being used to VS code, I had a rough time with vim.
Learning neo/vim has been interesting in many regards. I now have a more "portable" setup (up to plug-ins)
There are many other GUIs too, such as oni/oni2, gonvim, neovim-gtk and neovim-qt. Extensive list can be found here: https://github.com/neovim/neovim/wiki/Related-projects#gui
1: https://github.com/vhakulinen/gnvim/pull/95