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

Bill Joy's greatest gift to man – the vi editor (2003)

theregister.co.uk

Post reply on HN
Print view View original

131–140 of 186 posts

Re: Bill Joy's greatest gift to man – the vi editor (2003)

#131

Post by alexhutcheson »

pmoriarty wrote: post #112
DonHopkins wrote: post #81

Earlier quoted context omitted.

Also: Emacs has shell windows, process management, and output filtering, and keyboard macros, so it can run and control and respond to sub-processes (kind of like "expect" on steroids). I could not give up running shells in an emacs shell window, capturing all the output as normal text I can edit and search with the full power of emacs, instead of a dumb scrolling terminal emulator, and the ability to make keyboard m…

So what do you do when some shell command you run chooses to spit out a bunch of really long lines? Emacs would freeze on me when this happens. Is there a way around this apart from running a shell under libvterm? Or is this even still an issue under libvterm too?

Not OP, but that hasn't come up for me very often. If a command output is really long or takes a long time to run I'll normally run it using M-& (async-shell-command) instead of running it in a shell buffer.

Long lines are a more general issue with Emacs, but there's changes in Emacs 27 that should mostly solve it.

Re: Bill Joy's greatest gift to man – the vi editor (2003)

#132

Post by pmoriarty »

alexhutcheson wrote: post #131
pmoriarty wrote: post #112

Earlier quoted context omitted.

So what do you do when some shell command you run chooses to spit out a bunch of really long lines? Emacs would freeze on me when this happens. Is there a way around this apart from running a shell under libvterm? Or is this even still an issue under libvterm too?

Not OP, but that hasn't come up for me very often. If a command output is really long or takes a long time to run I'll normally run it using M-& (async-shell-command) instead of running it in a shell buffer. Long lines are a more general issue with Emacs, but there's changes in Emacs 27 that should mostly solve it.

"that hasn't come up for me very often"

The fact that it can happen and does happen leads me to avoid Emacs' shell modes altogether. I just don't want my Emacs freezing on me ever. Considering how much I do in it, it freezing on me is an utter and complete disaster that I want to completely avoid even if it doesn't happen often.

"there's changes in Emacs 27 that should mostly solve it"

If you're talking about the solong mode integration, that's just a hack that kind of works for static buffers, but won't help in dynamic buffers like shell-mode.

To really and truly fix this issue, a core part of Emacs will have to be rewritten, and since that part is written in C and is pretty hairy, no one seems to want to deal with it. So it probably won't happen any time soon.

I'm just hoping Emacs' libvterm integration provides a good workaround, at least for using a shell from within Emacs. I'll have to give it a try one of these days.

Re: Bill Joy's greatest gift to man – the vi editor (2003)

#134

Post by wbkang »

kmarc wrote: post #113
sacks2k wrote: post #98

Earlier quoted context omitted.

"This is especially important if you have to edit a file on a remote server" This may have been true a decade ago, but editors like Visual studio code now have remote editing abilities over SSH. I regularly have 50+ files open at a time for editing/compiling and I've never found editors like VI very helpful. If I need to make a quick edit to a config file, it does the job.

Now imagine that SSH going from a Citrix windows desktop running on a Windows 10 VM on your linux laptop. Every key press reacts in around a second. Welcome to banking "security"! Now let's say I want to `d5}`, to delete the next 5 paraghraph. In vi(m) I can do this by telling it "hey vim, delete those 5 damn paragraph!" In fancy VScode I have to say more like... "Hey editor, wait a sec, I'm moving my cursor over the…

vscode remote will actually perform better than vim over laggy ssh because the UI portion is completely local.

Re: Bill Joy's greatest gift to man – the vi editor (2003)

#135

Post by nameless_me »

reddit_clone wrote: post #124
coliveira wrote: post #23

I used Emacs for 5 years before learning vi. What a change! While Emacs tries to put the kitchen sink inside the editor, vi tries simply to be a keyboard interface to the rest of the system. I've never looked back since I learned this way of working.

Emacs user here. Emacs' real value is not really in text editing, though it is no slouch in text editing. It does so many other things so well, at this point it is unthinkable for me to not have it. Eg. OrgMode, Magit, Helm, Tramp, Dired and slime to mention a few. Its a lifestyle ;-)

Agree. Emacs is so much more than a text editor, it is more accurately described as a lifestyle. Operating systems are merely bootloaders for Emacs. ;D

Re: Bill Joy's greatest gift to man – the vi editor (2003)

#136

Post by combatentropy »

ben7799 wrote: post #91

Vi is the ultimate example of software that is "easy to use" as opposed to "easy to learn", it is great that we still have Vi and so many other unix tools that use the same philosophy. One of the biggest things that has happened to computer software in modern times is the balance between "easy to use" and "easy to learn" has shifted dramatically towards "easy to learn". There is some software that can achieve both at…

I agree. While vi has an unusually steep learning curve among software, I think of it sometimes when I design user interfaces. Design with the 2-week user in mind, not the first-time user.

What I would call fraidy-cat designers work themselves into a tizzy asking themselves, yes, but will users like it or understand it the first time they see it? I encourage people to instead be a bit bold and ask, will the user grow to like it after using it for a week or two?

There are three kinds of software:

1. Easy at first, and mediocre for the rest of your life.

2. Takes some getting used to at first, and awkward for the rest of your life.

3. Takes some getting used to at first, and wonderful for the rest of your life.

I suppose there might be tools that are easy at first and wonderful for the rest of your life, but they are rare. Most classic tools are in the last category. And it's not just software. An audio engineer probably took a long time to learn how to use a mixing board, but now it's second nature. Manual focus on a professional camera, also something that's hard at first but effortless and even preferred after practice.

The thing is, if you optimize for the first-time user, you might be blocking yourself from making something really powerful and simple, though at first strange. Some of the best things in life are at first strange.

In case someone is still trying to read my post in bad faith, of course you should not make it harder than necessary for first-time users. Designing interfaces is hard work. This is not an excuse to be lazy. It is an invitation to make your software as good as possible for long-term users.

Re: Bill Joy's greatest gift to man – the vi editor (2003)

#137

Post by bdamm »

gen220 wrote: post #85
scottlocklin wrote: post #32

Earlier quoted context omitted.

> So much insight is cooked into those little key mappings. Just a point of historical order, didn't those key mappings mostly come from ed? Aka Ken Thompson and Ritchie?

yes they definitely do. ed -> ex -> vi It's fascinating to read comments praising how great it is that you can edit text without a mouse. ed was written to interface with tty systems, where mice weren't even a thing to be avoided. :)

It's not about doing it without a mouse, it's about doing it fast, comfortably, and powerfully. Pointers are a useful addition to graphic capable vi implementations, but if you do everything with mouse or trackpad movements then I don't think you can claim the zen of vi.

Re: Bill Joy's greatest gift to man – the vi editor (2003)

#138

Post by gen220 »

bdamm wrote: post #137
gen220 wrote: post #85

Earlier quoted context omitted.

yes they definitely do. ed -> ex -> vi It's fascinating to read comments praising how great it is that you can edit text without a mouse. ed was written to interface with tty systems, where mice weren't even a thing to be avoided. :)

It's not about doing it without a mouse, it's about doing it fast, comfortably, and powerfully. Pointers are a useful addition to graphic capable vi implementations, but if you do everything with mouse or trackpad movements then I don't think you can claim the zen of vi.

oh to be clear, I totally agree.

My fascination is that the original motions were not invented to escape the imprecision of graphical pointers, even though that's their main selling point today. They were invented to minimize (1) excessive tty printing, because printing is slow (2) keystrokes.

That, in 2020, these optimizations made in 1960 allow you to avoid the imprecision and slowness of a graphic pointer, we get for free :)

Re: Bill Joy's greatest gift to man – the vi editor (2003)

#139

Post by gen220 »

zerr wrote: post #84
nouveaux wrote: post #58

For those who do not understand why people are fanatical about vi, here are some reasons: Vi is keyboard only. This means that actions with the mouse are optimized through the keyboard. There are "hotkeys" for most tasks you use with a mouse. Vi has the idea of objects. Words, lines and paragraphs are objects you can operate on. Vi defines a "language" for operating on objects. For instance, 'd' is delete. You can de…

What I observe is that most vim fans who swear by it use it as a bare bones editor, syntax highlighting at most. No auto-completion, go to definition or any other IDE stuff. Yes, it is possible to make vim IDE-like but very few do so.

I used to be like you describe, mostly because language-specific plugins were a dumpsterfire of hidden complexity, that really slowed down your editing experience.

While some plugins are brilliantly-designed, it takes a long time to learn how to configure one language plugin to your tastes, and that learning is generally non-transferable to other language plugins. (vim-go fits this to the T, ime).

https://github.com/dense-analysis/ale (along with the language-server movement in general) changed my perspective. I now do at least the go-to and autocomplete half of IDE things, now.

Re: Bill Joy's greatest gift to man – the vi editor (2003)

#140

Post by nouveaux »

supernova87a wrote: post #73
nouveaux wrote: post #58

For those who do not understand why people are fanatical about vi, here are some reasons: Vi is keyboard only. This means that actions with the mouse are optimized through the keyboard. There are "hotkeys" for most tasks you use with a mouse. Vi has the idea of objects. Words, lines and paragraphs are objects you can operate on. Vi defines a "language" for operating on objects. For instance, 'd' is delete. You can de…

Unfortunately, the barrier I faced with even trying VI is that you cannot discover any functionality intuitively. Exaggerating (but just a little) I could not even figure out how to type without someone giving me a tutorial. That was enough to make me stop.

I understand the frustration since even as a veteran users of Vim, there are lots I do not know about.

Vi is a completely different way of thinking. I would compare it to learning to program. When you first start, there isn't very much that is discoverable. You just have to sit through the learning. Once you do, you have access to a lot of power.

Post reply on HN