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

231–240 of 251 posts

Re: Vim for Humans

#231

Post by sheer_horror »

nol13 wrote: post #70
sheer_horror wrote: post #24

Earlier quoted context omitted.

> it just doesn't make sense to me. Here's how to think of Vim that will make sense. Suppose you have two identical codebases that each need to have the same 200 lines changed. Functions need to be added, comments to be removed, templates need modifying, and so forth. In one of the two codebases, you use Nano to apply those changes. In the second codebase, you use Vim. Assuming the Vim user was proficient at Vim, you…

I hear you for nano, but what about compared to [graphical mouse-clicky editor of choice] (in non-vim mode)? I know enough of the basic vim commands that I could edit a file if I ever needed to but how much hand effort could it save me vs. kate or VS Code? (though i really prefer notepad++ to both of those) I feel relatively efficient in a good graphical editor but maybe I just don't know any better? Really just give…

To prove that Vim is faster than a graphical editor as well, I might make a WebM where I edit two identical files, one with notepad++ and one with Vim. Would you appreciate that? I will do that if you respond to this.

Because yes, Vim ultimately will be faster.

Re: Vim for Humans

#232

Post by JoshTriplett »

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.

Vim recognizes and cares about file types. If I edit a file with "#!/bin/sh" at the top, I'd like vim to provide syntax highlighting for a shell script. And if I edit a file named "*.c", I'd like vim to provide syntax highlighting for C. That highlighting makes it far easier to spot typos.

UNIX didn't support a wide variety of things people expect and find more user-friendly on modern systems. At an OS level, the OS should absolutely treat everything as a bag of bytes; that doesn't mean every tool built upon it should.

Re: Vim for Humans

#233

Post by weaksauce »

Veen wrote: post #216
Philipp__ wrote: post #213

Earlier quoted context omitted.

I know about spacemacs, and don't like the idea of core editor. Tried it and ended up using not emacs, not vim, but mix of both, and commands from both. And I do not like that.

I had the same experience. I love the idea of the space leader and the mnemonic keymappings, but too much of Emacs leaked through. I've taken the lessons learned from Spacemacs and applied them to vim, remapping the leader to space and using mnemonics for remapping of some commands — all the markdown based commands are under space m, for example.

I had my leader set to spacebar in vim and used mneumonics for the bindings already, but the main thing other than the discovery of forggoten leader keybindings(how many can you really remember even with mneumonics?) that I dislike about vim is how almost every extension just feels broken and hacked together. there are some that work well but a lot of them are just crap and I attribute that directly to extension authors wanting to use viml as much as possible to keep maximum compatibility and reduce external dependencies. Lisp is a good language that is self documenting as well as being usable. viml is a terribly hacky language that is awkward at best and counterproductive at worst. I still love vim but vim needs a better language around it. perhaps when neovim picks up steam the lua backend will lure people to write good plugins in it.(lua is a pretty good language overall). just depends on who wins the war now between vim and neovim now that vim has better async support.

Re: Vim for Humans

#234

Post by flukus »

Annatar wrote: post #227
flukus wrote: post #210

Earlier quoted context omitted.

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

You are likely to find .c and .h files, but for UNIX, that is also just another stream of bytes - it cares not that the stream of bytes happens to be in the ASCII, 7-bit range. Where are you going with that?

The point is .c and .h are recognized file types and Unix has them.

Re: Vim for Humans

#235

Post by pacomerh »

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…

Nice, "practical VIM" is how I learned VIM. Very easy to understand given the examples.

Re: Vim for Humans

#236

Post by Annatar »

flukus wrote: post #234
Annatar wrote: post #227

Earlier quoted context omitted.

You are likely to find .c and .h files, but for UNIX, that is also just another stream of bytes - it cares not that the stream of bytes happens to be in the ASCII, 7-bit range. Where are you going with that?

The point is .c and .h are recognized file types and Unix has them.

UNIX doesn't treat them in any special way. There is no such thing as file types on UNIX. That concept does not exist, nor is it needed on UNIX.

If one wants to classify a file at-all-costs, we have the file(1) command on UNIX, and that command consults /etc/magic (see magic(4)); if magic(4) does not contain the required byte stream excerpt, the output of the file(1) command will be an untrustworthy approximation at best. And still, the file(1) command is strictly for humans who feel the need to classify-at-all-costs, not for the operating system.

Re: Vim for Humans

#237

Post by flukus »

Annatar wrote: post #236
flukus wrote: post #234

Earlier quoted context omitted.

The point is .c and .h are recognized file types and Unix has them.

UNIX doesn't treat them in any special way. There is no such thing as file types on UNIX. That concept does not exist, nor is it needed on UNIX. If one wants to classify a file at-all-costs, we have the file(1) command on UNIX, and that command consults /etc/magic (see magic(4)); if magic(4) does not contain the required byte stream excerpt, the output of the file(1) command will be an untrustworthy approximation at…

Windows doesn't treat them in an special way either. You can open a text file with any/no extension.

Re: Vim for Humans

#238

Post by Annatar »

JoshTriplett wrote: post #232
Annatar wrote: post #208

Earlier quoted context omitted.

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.

Vim recognizes and cares about file types. If I edit a file with "#!/bin/sh" at the top, I'd like vim to provide syntax highlighting for a shell script. And if I edit a file named "*.c", I'd like vim to provide syntax highlighting for C. That highlighting makes it far easier to spot typos. UNIX didn't support a wide variety of things people expect and find more user-friendly on modern systems. At an OS level, the OS…

Vim recognizes and cares about file types. If I edit a file with "#!/bin/sh" at the top, I'd like vim to provide syntax highlighting for a shell script.

Well I wouldn't, and the entire purpose of using UNIX or a UNIX-like operating system is that such things are a strictly intimate, individual, private affair.

The example you cite serves extremely well for the purpose of illustration, of how there are no file types in UNIX, and how neither the operating system, nor the user should care.

Why should the user care? For example, I don't want files in the bin/ directory to have .pl, .py, .sh, .exe, or .com extension! Does it have an x bit set, thereby being executable? It does? OK, run it, and I couldn't and shouldn't care less what it's written in, because that's the main reason why I use UNIX to begin with!

Same for coloring: I hate colors in vim(1); hate, hate, hate, and do not need or want coloring in order to spot syntax errors, as I have the compiler, the linker, and the shell's set -x for that ("do one thing, and do it well")! Why should I suffer if you like colors and syntax highlighting? That should, and on UNIX is, an entirely private affair. GNU/Linux broke that, because users came from Windows, expecting GNU/Linux to behave like Windows but with a shell which isn't braindead. If I wanted to use Windows, I would be using it. If I wanted to use an integrated development environment again, I would be using it instead of vi(1) to write code. vi and vim, by the way, are text editors, dedicated to doing one thing and doing it well, and to expect them to behave like an integrated development environment leads to sadness, pain, misery and confusion.

UNIX does not have, recognize, or care about file types; consequently, it is up to the application to implement mechanism for dealing with the stream of bytes which the operating system does provide. In your case, that application is vim(1), and the file type recognition is proprietary to it. It has nothing whatsoever to do with the operating system.

On AmigaOS, where vim(1) comes from, no such vimrc file is provided; consequently, vim(1) doesn't treat .h, .c, or AmigaDOS shell scripts in any special way. This is because AmigaOS does implement data types, which are generic file type drivers, and still neither the operating system, nor the user care about file type extensions!

On Solaris and illumos-based operating systems, for example, vim packages do not deliver such customizations as they do on GNU/Linux, and consequently, there is no highlighting or any other special handling of .h, .c, or any other file type. (z/OS on the mainframe is even better, there are no files or byte streams to speak of, only records, and they are all binary.)

It's just a very bad Microsoft screw-up from MS-DOS days which has conditioned an entire generation of hapless Windows-now-turned-GNU/Linux users to still think of files in terms of file types and integrated development environments, because MS-DOS and Windows came without dedicated tools out of the box, so people started writing one-program-does-it-all, monolithic applications. What would you do on z/OS, where there are no files, just records?

This is one of the core concepts of UNIX: policy over mechanism; UNIX specifies policy (stream of bytes); mechanism is left up to the implementer.

Rule of Separation: Separate policy from mechanism; separate interfaces from engines.

http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2...

As someone who authored XCB, you should be no stranger to separation of policy from mechanism.

Re: Vim for Humans

#239

Post by Annatar »

flukus wrote: post #237
Annatar wrote: post #236

Earlier quoted context omitted.

UNIX doesn't treat them in any special way. There is no such thing as file types on UNIX. That concept does not exist, nor is it needed on UNIX. If one wants to classify a file at-all-costs, we have the file(1) command on UNIX, and that command consults /etc/magic (see magic(4)); if magic(4) does not contain the required byte stream excerpt, the output of the file(1) command will be an untrustworthy approximation at…

Windows doesn't treat them in an special way either. You can open a text file with any/no extension.

You can, but Windows will ask you which program to open it with every time, because it uses extensions to classify file types, and since the file doesn't have an extension, Windows is incapable of handling it automatically. The fact that it has to handle files at all is a lost cause, conceptually. One bad decision begets another in Windows, which is all well and good, just not when that nonsense starts permeating into UNIX, where it is neither wanted nor needed - it's an artificial, unnecessary thing there.

Re: Vim for Humans

#240

Post by mikegerwitz »

eikenberry wrote: post #94
mikegerwitz wrote: post #61

Earlier quoted context omitted.

C-[ is equivalent to , and is much more natural. I also bind caps lock to ctrl (setxkbmap -option ctrl:nocaps on a GNU/Linux system), which makes this all the more natural.

Why not just change caps-lock to esc. setxkbmap -option caps:escape

Personally, because it offers me no benefit: [ is on the other hand, so it's the same speed as hitting a single key, and I use Ctrl for many other things; Esc is specialized. I'm also an Emacs (and vim) user (Evil mode, of course).
Post reply on HN