Vi is not vim(hugodaniel.pt)
hugodaniel.pt
Vi is not vim
http://www.hugodaniel.pt/posts/2017-08-12-vi-is-not-vim.html
66 comments
> I find myself jumping between languages far too often to trust myself to use the correct syntax on the first try, so much so that I consider in-editor linting to be an indispensable tool.
I've been sorely tempted several times to:
1. pick one syntax for things like array initialization, ranges, for loops, string quoting, and various other things that are all reasonably similar from a functionality point of view in Perl, PHP, Python, and JavaScript but use different enough syntax that I sometimes forget which one is right,
2. start writing my Perl, PHP, Python, and JavaScript using that syntax, and
3. write some sort of preprocessor that takes in files that are Perl, PHP, Python, and JavaScript but that use my syntax instead of the native syntax, and replaces my syntax with native syntax.
I usually didn't go ahead with it because I just figured I was being silly and everyone would make fun of me. :-)
But now it seems quite common for people to define new languages that are just existing languages with some better syntax or other features and that are translated back to the original language.
So now I don't do it because I assume someone else will do it soon, and I'll be happy to just grab theirs and use it.
I've been sorely tempted several times to:
1. pick one syntax for things like array initialization, ranges, for loops, string quoting, and various other things that are all reasonably similar from a functionality point of view in Perl, PHP, Python, and JavaScript but use different enough syntax that I sometimes forget which one is right,
2. start writing my Perl, PHP, Python, and JavaScript using that syntax, and
3. write some sort of preprocessor that takes in files that are Perl, PHP, Python, and JavaScript but that use my syntax instead of the native syntax, and replaces my syntax with native syntax.
I usually didn't go ahead with it because I just figured I was being silly and everyone would make fun of me. :-)
But now it seems quite common for people to define new languages that are just existing languages with some better syntax or other features and that are translated back to the original language.
So now I don't do it because I assume someone else will do it soon, and I'll be happy to just grab theirs and use it.
Syntax highlighting doesn't bother me; I don't disable it. But when I learned to program I used monochrome terminals like VT100 or ADM-3a and it just wasn't a thing that could be done, so I also feel quite comfortable without it.
Syntax highlighting is most useful to me to make things like unclosed quotes stand out. I don't find the highlighted reserved words and other highlights to be all that beneficial.
Syntax highlighting is most useful to me to make things like unclosed quotes stand out. I don't find the highlighted reserved words and other highlights to be all that beneficial.
You could still use a VT100 terminal, no need for fancy modern X terminals and vi.
[deleted]
>No syntax highlighting
>If you still struggle with syntax then please use syntax highlighting, it will help those special words stand out.
I find syntax-highlighted code far easier to read, in part because it becomes less just a blob of amorphous text. Our eyes are better at noticing blobs of text that are green than blobs of text which happen to be preceded by a "//" or some such.
>If you still struggle with syntax then please use syntax highlighting, it will help those special words stand out.
I find syntax-highlighted code far easier to read, in part because it becomes less just a blob of amorphous text. Our eyes are better at noticing blobs of text that are green than blobs of text which happen to be preceded by a "//" or some such.
I found that line beyond pretentious. You don't need to "struggle with syntax" to find highlighting useful.
I actually find that this "blob of amorphous text" is helpful for me, I seem to read code more thoroughly with syntax highlighting off
I find syntax highlighting to be quite distracting. There are reasons why it is still an option and not mandatory.
The best option is to have a option.
As long as I can use it, doesn't bother me at all that you don't. Doesn't affect the code at all.
Its a open discussion, no bothering required
During the golden age of computing, vi was my editor (and my only choice as it was either vi or emacs, but emacs was too slow on our school server running Multics, while we were connected to it via terminals on 9600baud serial). 20 years forward and rediscovering its cousin, vim, I don't miss vi that much.
I remember the pain of using vi on old terminals, but despite its shortcomings, it was better than coding on printer-based terminal, editing on ex.
I really cannot use vi (nvi, elvis, etc) instead of Vim, because I need visual mode. I need unicode. The op mentioned lacking unicode as a feature, but I disagree. It's not that I use Unicode in source code, but I work in international open-source projects, where codes might contain anything, including emojis and foreign characters in the comment.
Also I really would miss CtrlP (fuzzy file finder), vim-surround, etc. Pressing ctrl-p is ingrained in my fingertips, and it feels awkward when an editor doesn't respond to ctrl-p.
Also stock Vim feels just like vi especially with 'compatible' mode enabled. With Vim, you don't have to install plugins or features you don't need, and it runs fairly fast. Also I can recommend neovim, if performance becomes an issue.
I remember the pain of using vi on old terminals, but despite its shortcomings, it was better than coding on printer-based terminal, editing on ex.
I really cannot use vi (nvi, elvis, etc) instead of Vim, because I need visual mode. I need unicode. The op mentioned lacking unicode as a feature, but I disagree. It's not that I use Unicode in source code, but I work in international open-source projects, where codes might contain anything, including emojis and foreign characters in the comment.
Also I really would miss CtrlP (fuzzy file finder), vim-surround, etc. Pressing ctrl-p is ingrained in my fingertips, and it feels awkward when an editor doesn't respond to ctrl-p.
Also stock Vim feels just like vi especially with 'compatible' mode enabled. With Vim, you don't have to install plugins or features you don't need, and it runs fairly fast. Also I can recommend neovim, if performance becomes an issue.
I'd rather spend my time learning how to write better code than spend that same amount of time learning a completely different keyboard shortcut system just to edit faster.
Seriously. How many of us are actually at the point where our limiting factor is how fast we can edit instead of how fast we think about the code we want to get on the screen?
Seriously. How many of us are actually at the point where our limiting factor is how fast we can edit instead of how fast we think about the code we want to get on the screen?
People say that most of coding is thinking, but I'm not sure that's even true, and even if it were, it's still possible if you typed faster and stayed in the flow you'd also end up thinking faster.
My friend used to type at 70 wpm in a regular editor. After failing some interviews because he couldn't work fast enough, he started doing http://keyhero.com and practicing vim keybindings half an hour a day. Now he types at 130 wpm, more than doubled the amount of code he writes a day, and won't shut up about it.
There's certainly nothing to lose by getting faster at typing/editing code.
My friend used to type at 70 wpm in a regular editor. After failing some interviews because he couldn't work fast enough, he started doing http://keyhero.com and practicing vim keybindings half an hour a day. Now he types at 130 wpm, more than doubled the amount of code he writes a day, and won't shut up about it.
There's certainly nothing to lose by getting faster at typing/editing code.
We love bikeshedding. Changing keyboard layouts and editors is a "fun" distraction from work.
Yes, this is the fundamental problem with editor tweaking.
Two lines from his "minimal" config file:
set tabstop=2
set ts=2
Minimal config files are unwanted, I heard.
I used bash/tmux/vim exclusively for development for about three years. The whole time I felt very pleased that I was minimizing bloat in my toolchain, understanding everything I used, and getting amazing speeds. Six months ago I switched to Visual Studio Code with vi keybindings. I found every benefit above, plus plugins for everything that just worked, an intuitive configuration system, and all the benefits of being an IDE instead of just a text editor. Some functionality is even faster: ctrl+p filename search, for example.
I've come to think that insisting on minimalist tooling is misguided once you have fast computers.
I've come to think that insisting on minimalist tooling is misguided once you have fast computers.
I agree. I grew up using vi on SysV on a Wyse-60. I don't want to go back there.
Vi is not nvi either, by the way.
Unless you're on a BSD!
One reason to learn the basics of plain vi (not vim) even if you are in the emacs camp -- if you find yourself needing to do something in a pinch on an unfamiliar unix machine, it's very rare to find one that doesn't have vi installed.
I love plain vi. I spent a few years using it exclusively, despite the availability of vim. It helps you realize how much you can do with plain vi and ex commands that you'd often rely on plugins for with vim.
If you can ssh into the remote box, you can edit files there via Tramp, even via sudo - C-x C-f /ssh:user@host|sudo:otheruser@host:/path/to/file, it'll prompt as needed for whatever credentials are required.
Still worth knowing the basics of vi, but Tramp has made it vanishingly rare at this point that I ever have to edit anything outside my main local Emacs session, which is nice.
Still worth knowing the basics of vi, but Tramp has made it vanishingly rare at this point that I ever have to edit anything outside my main local Emacs session, which is nice.
There's always ed. (Which is surprisingly good.)
In college, I once spent a month using ed exclusively, to force myself to really learn to use it. I wouldn't really want to go back (except for the perverse challenge), but it did make me really appreciate the power of ed/sed/awk/perl and ideas like Plan9's sam/samterm.
nvi is a acronym for "not vi" :)
Unless you know what you are doing, a heavily configured vim can be really slow. It can approach a level of slowness comparable to atom at times. If you have to heavily configure vim to get it to a point that it's useful for your workflow, I highly recommend giving sublime a try, it has truly made writing code more enjoyable for me.
Well modern plugin managers have lazy plugin loading based on the current filetype. You open .cpp vim transforms into a cpp "ide". You open .hs ghc-mod and friends has you covered. Lazy plugin solved the old problem of having hundred vim plugins loaded at the same time resulting in an slow ide like experience.
Moved from Sublime to VS Code for font ligature support. (I like Fira Code)
Stayed for:
* Integrated terminal that also supports ligatures
* Pluggable debugger: one interface across gdb, delve, node, Chrome and other browsers, etc...
* Built in git support that's nicer in my opinion than any of the plugins for Sublime
* Markdown previews
* Seriously good Intellisense, it even tells me the schema of nested objects returned from another function in JavaScript.
* Probably some more that I forgot...
I don't regret buying Sublime, but VS Code targets the same platforms, has way more features and a faster release cycle, and did I mention it's free and open source?
Stayed for:
* Integrated terminal that also supports ligatures
* Pluggable debugger: one interface across gdb, delve, node, Chrome and other browsers, etc...
* Built in git support that's nicer in my opinion than any of the plugins for Sublime
* Markdown previews
* Seriously good Intellisense, it even tells me the schema of nested objects returned from another function in JavaScript.
* Probably some more that I forgot...
I don't regret buying Sublime, but VS Code targets the same platforms, has way more features and a faster release cycle, and did I mention it's free and open source?
Personally I've had Sublime approach near Atom levels of slowness from plugins as well. I'd imagine it depends on the plugins, but that's essentially what slows any of these editors down a lot.
For what it's worth, I always use Sublime for really large files.
For what it's worth, I always use Sublime for really large files.
I stopped having performance problems when I switched to NeoVim.
[deleted]
I've managed to disable syntax highlighting in the past and not miss it, but at least the comments must be different from normal source code! Comments can get really noisy without any highlighting.
My Slackware boxen come with 'vi' symlinked to 'elvis'. I'm an Emacs user but I'm conversant with bare-bones vi enough to use vim or elvis to do quick config changes or bang out short scripts.
That is one of the scenarios where I would use another text editor. nvi is strictly a code/config editor.
An there lies the problem, what other editor is he going to use? Vim? ;)
An there lies the problem, what other editor is he going to use? Vim? ;)
I love @ buffer. A long time ago that was my first exposure to a kind of programmable editor.
I loath the manipulation of the back button.
I loath the manipulation of the back button.
Lately I've been wishing there was a way to use Vim's plugins without having to use vim.
But alas there is none. :(
But alas there is none. :(
vis is another lightweight but modern alternative to vim these days. I recently switched from vim and sam to vis myself, and recommend it.
https://github.com/martanne/vis
https://github.com/martanne/vis
>no Unicode
My inner Asian is screaming.
My inner Asian is screaming.
Your post reads a bit like, hey you think my config is too small? i'll show small!
[deleted]
Pssh, yes it is- alias vi='vim'
I feel confused and even suspicious when people tell, non-jokingly, that they couldn’t find a way to exit vim. Have they never used ^C in their terminal?
I feel confused at this comment, even suspicious.
But did you know that ^C does not actually exit vim?
:q!
:q!
Pressing ^C in normal mode tells you how to exit vim.
It does _now_.
One of the most important UX advances of recent years, IMO. Introduced in Vim 6.3, released in June 2004.
One of the most important UX advances of recent years, IMO. Introduced in Vim 6.3, released in June 2004.
>recent years
>2004
:)
>2004
:)
That's way after I had to reset a terminal and log back in the first time that I tried to use vi.
First Time I saw that, I was like 'but typing doesn't work'.
Then, I fumbled my way into insert mode and managed to type :q . It didn't do anything.
VIM is hard for first time users.
VIM is hard for first time users.
[deleted]
It's possible he was actually trying to exit a non-vim vi that doesn't pop up a useful message explaining how to quit when you hit ^C.
Vim might do that but other implementations of vi don't. Instead, they flash the screen, ring the bell or print something to the effect of "interrupted".
He mentioned that this occurred very early in his career, perhaps as a child.
He named Red Hat 5, which had a lot fewer niceties than are default today.
>Your focus will be in semantics and it is easier to get into it without the syntax aggressively jumping at your face.
I'm not sure I agree with this. As a programmer, your tool for expressing semantics is through syntax. While the author argues that disabling syntax highlighting makes the syntax less important, I feel that removing syntax highlighting places undue stress on the author by removing the first level of immediate validation that the syntax is correct.
I find myself jumping between languages far too often to trust myself to use the correct syntax on the first try, so much so that I consider in-editor linting to be an indispensable tool.
Perhaps if someone only ever wrote one or a few very different languages, they wouldn't have to worry about if their language indexes by range with [a:b], [a..b], or .slice(a,b).