Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vim for Humans

vimebook.com

Post reply on HN
Print view View original

201–210 of 251 posts

Re: Vim for Humans

#201

Post by Annatar »

exDM69 wrote: post #5
gbrown_ wrote: post #3

I've only skimmed this but there seems to be a focus on customizing and plugins from the get go. I think it's worth getting to know Vim "as is" before doing such things. Indeed there certainly some things that aren't the most useful or obvious but it's good to understand their original intent. Not to crap on the author of this but I'd recommend Drew Neil's Practical Vim over this (and pretty much every other Vim book…

I kind of agree but vim's defaults are awful. Tim Pope has put together a good set of non-opinionated defaults which don't change key bindings or customize it otherwise [0]. I have a very similar vanilla setup with no plugins apart from syntax highlighting for some languages not included by default. [0] https://github.com/tpope/vim-sensible

I kind of agree but vim's defaults are awful.

I wonder whether that is because of vim compiled defaults or the way people who package vim think things should be, or both?

I get so angry every time I log into my newly created Linux account and fire up vi, wanting to get some work done, only to find out that it's been aliased to vim, and there is that horrid syntax highlighting turned on. Unbelievably irritating, and frustrating to no end.

Ironically, on AmigaOS where vim comes from, there are no customizations and no syntax highlighting - vim just works there as one would expect vi to work on UNIX.

Re: Vim for Humans

#202

Post by jjcm »

BurningFrog wrote: post #84

I continue to be baffled that software written 40+ years ago, to deal with constraints and realities that are long long gone keep being used by people on the cutting edge of technology change.

In my opinion, vim's command line usage (while quite nice) isn't the reason why people are so die hard about it. Vim is one of the very few editors out there that provide language based commands, allowing you to chain and build a command in the same way that you'd tell a human how to work. Vim's shortcuts have nouns, adjectives, and verbs. Try implementing something similar in a modern IDE and you'll find that vim's syntax for hotkeys is actually really well designed. That's why you always see vim-modes for modern IDEs - they want the language that it provides, not the command line functionality/ubiquity of vi.

Re: Vim for Humans

#203

Post by Annatar »

t4nkd wrote: post #66
JoshTriplett wrote: post #54

Earlier quoted context omitted.

> As someone who only uses Vim casually, what's an example of a bad default? By default, vim doesn't enable filetype detection or syntax highlighting, so even though it can easily recognize a source file's language, it doesn't.

Anecdotally, this is exactly the sort of thing I have never needed while using vim on a server. Just let me modify content in the word hole...

Upvoted! Same here; I hate it when syntax highlighting makes it difficult for me to see the code, when I'm on a server and am just trying to get some work done. I cannot comprehend why I would want to see code in all those colors, with horrible contrasts, hard to read? Why? I know the syntax of the code, don't need or want anyone shoving what they think I need or want down my proverbial throat!

Re: Vim for Humans

#204

Post by flukus »

gepoch wrote: post #91
Philipp__ wrote: post #68

It took me a while to realize what really vim is for. What led me to realization was switching to Emacs. I read this post, and second checkbox says "modern customizable IDE". And I stopped there. Why you may ask? Well, I used Vim for 3 years before trying Emacs this spring. And I loaded it with all the heavy plugins(YCM), but Emacs led me to realization that Vim is more of an editor than IDE. Even with plugins I thin…

I will add some of my own opinions: My feeling is that real value of Vim is its novel approach to modal text manipulation, and you shouldn't let the fact that it has a standalone lightweight reference implementation usefully installed on almost every machine that you use confuse you. Vim script is not a great plugin language, and the vim runtime itself is not fantastic at doing things beyond the text editing. I think…

I'd disagree that vim script is not a great plugin language, it's php like in it's simplicity and has a few novel features (like scopes) that are ideal for text editors and wouldn't fit into the variable scoping rules of other languages. Now it finally has a thread/process model too, making it better than ever.

Creating a user specific script in vim is an order of magnitude simpler than atom.

Re: Vim for Humans

#205

Post by Annatar »

JoshTriplett wrote: post #169
chongli wrote: post #165

Earlier quoted context omitted.

I must be weird or something but I've gone back and forth between vim and emacs for years before finally settling on just vi (Keith Bostic's nvi, to be exact). I've spent countless hours reading about and installing plugins on both of those big editors instead of just getting work done. Now that I just use vi, I realize how little of that stuff I need and how much I can get done with just macros and ! (the shell out…

I've encountered several quite painful behaviors of traditional vi that vim fixes. For instance, with traditional vi, if you start out changing a region, you can't move or change text outside that region without exiting insert mode.

That's the way vi is supposed to work, since it is based on the paradigm of a modal editor.

I learned vi in vi on UNIX, so the modal way stuck and I can glide and float between vi on UNIX and vim on Linux without getting busted on trying to move with cursor keys. I see Windows/Linux users get busted on that a lot, because they didn't install UNIX at home and learned on that first. It's frustrating to watch them get busted by that in person, over and over again.

Re: Vim for Humans

#206

Post by Annatar »

JoshTriplett wrote: post #169
chongli wrote: post #165

Earlier quoted context omitted.

I must be weird or something but I've gone back and forth between vim and emacs for years before finally settling on just vi (Keith Bostic's nvi, to be exact). I've spent countless hours reading about and installing plugins on both of those big editors instead of just getting work done. Now that I just use vi, I realize how little of that stuff I need and how much I can get done with just macros and ! (the shell out…

I've encountered several quite painful behaviors of traditional vi that vim fixes. For instance, with traditional vi, if you start out changing a region, you can't move or change text outside that region without exiting insert mode.

That's the way vi is supposed to work, since it is based on the paradigm of a modal editor.

I learned vi in vi on UNIX, so the modal way stuck and I can glide and float between vi on UNIX and vim on Linux without getting busted on trying to move with cursor keys. I see Windows/Linux users get busted on that a lot, because they didn't install UNIX at home and learned on that first. It's frustrating to watch them get busted by that in person, over and over again.

Re: Vim for Humans

#207

Post by ufo »

AceStar wrote: post #173
justinmk wrote: post #56

Earlier quoted context omitted.

That's why Neovim carefully implemented[1] most of the defaults (and a few others) from sensible.vim. [1] https://github.com/neovim/neovim/issues/2676

Which would you recommend more out of Neovim, or vim with sensible.vim?

In my experience the only con of neovim is that it doesn't come installed by default like vim does. Other than that its very compatible.

Re: Vim for Humans

#208

Post by Annatar »

JoshTriplett wrote: post #81
t4nkd wrote: post #66

Earlier quoted context omitted.

Anecdotally, this is exactly the sort of thing I have never needed while using vim on a server. Just let me modify content in the word hole...

vim isn't the "on a server" editor for me, it's the "everything" editor. I like that it works the same way everywhere, but I primarily use it to edit files that do have recognized filetypes. (As an aside, for me the main value of syntax highlighting isn't the normal case, but rather the case where the syntax highlighting emphasizes a problem, such as an unterminated string or other typo.)

I like that it works the same way everywhere, but I primarily use it to edit files that do have recognized filetypes.

UNIX doesn't care about filetypes, since the paradigm is working with binary streams of data, and it's implemented in a way that users don't need or have to care either. File types are a concept from MS-DOS, popularized by Windows, and a major hindrance to a UNIX user's workflow.

Re: Vim for Humans

#209

Post by cma »

t4nkd wrote: post #66
JoshTriplett wrote: post #54

Earlier quoted context omitted.

> As someone who only uses Vim casually, what's an example of a bad default? By default, vim doesn't enable filetype detection or syntax highlighting, so even though it can easily recognize a source file's language, it doesn't.

Anecdotally, this is exactly the sort of thing I have never needed while using vim on a server. Just let me modify content in the word hole...

It can be pretty useful when editing a bash file and the color highlighting shows you a missed close-quote, etc.

Same for config files.

Re: Vim for Humans

#210

Post by flukus »

Annatar wrote: post #208
JoshTriplett wrote: post #81

Earlier quoted context omitted.

vim isn't the "on a server" editor for me, it's the "everything" editor. I like that it works the same way everywhere, but I primarily use it to edit files that do have recognized filetypes. (As an aside, for me the main value of syntax highlighting isn't the normal case, but rather the case where the syntax highlighting emphasizes a problem, such as an unterminated string or other typo.)

I like that it works the same way everywhere, but I primarily use it to edit files that do have recognized filetypes. UNIX doesn't care about filetypes, since the paradigm is working with binary streams of data, and it's implemented in a way that users don't need or have to care either. File types are a concept from MS-DOS, popularized by Windows, and a major hindrance to a UNIX user's workflow.

So if we look through the source tree of a random unix I won't find any .h or .c files?
Post reply on HN