> 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:
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.
You could still use a VT100 terminal, no need for fancy modern X terminals and vi.
>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).
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
>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.
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.
Seems to work on Chrome on Sierra for me.
Not on macOS Safari it seems.
OT: This website breaks the back button in Chrome on Windows.
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.
We love bikeshedding. Changing keyboard layouts and editors is a "fun" distraction from work.
Yes, this is the fundamental problem with editor tweaking.
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?
Minimal config files are unwanted, I heard.
Two lines from his "minimal" config file:
I agree. I grew up using vi on SysV on a Wyse-60. I don't want to go back there.
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.
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.
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" :)
Vi is not nvi either, by the way.
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)
* 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
* 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.
I stopped having performance problems when I switched to NeoVim.
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.
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.
I think `set autoindent` works across most versions of vi. It's not language aware. It just indents the next line to the same place as the previous. For me, that was enough.
A feature he didn't mentioned was language indentation support, wouldn't it be tedious to not have it?
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? ;)
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.
Lately I've been wishing there was a way to use Vim's plugins without having to use vim.
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.
My inner Asian is screaming.
Your post reads a bit like, hey you think my config is too small? i'll show small!
Pssh, yes it is- alias vi='vim'
I feel confused at this comment, even suspicious.
But did you know that ^C does not actually exit vim?
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.
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.
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.
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?