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

History and effective use of Vim (2019)

begriffs.com

Post reply on HN
Print view View original

41–50 of 98 posts

Re: History and effective use of Vim (2019)

#41

Post by asicsp »

yakubin wrote: post #35
asicsp wrote: post #24

Earlier quoted context omitted.

Again, I don't understand your point. GVim is GUI, not TUI.

A GUI can draw vector graphics, like lines, arcs, arrows etc. GVim still behaves like a terminal, which just has a grid of characters to work with. Any such vector graphics is done awkwardly with fonts, which doesn't give the best result, and patching fonts is not the best UX.

Thanks for further clarification. I haven't needed such capability in a text editor, but probably I should look into what that provides.

And I don't see how such features are necessary to rule GVim as GUI. I have a fairly basic classification: TUI runs in a terminal, GUI have their own windows.

Re: History and effective use of Vim (2019)

#42

Post by sophacles »

citrin_ru wrote: post #40
yakubin wrote: post #9

If Vim was a GUI application (and could smoothly handle long lines), it would the perfect editor for me. Alas, the best I've seen so far is Neovim's discontinued GUI frontends.

When your are working with huge files or files with huge lines it makes sense to disable syntax highlighting to improve performance (:syntax off).

If you use neovim with tree-sitter, this is not really true anymore! Or at least it extends the huge file/huge line boundary pretty far.

Re: History and effective use of Vim (2019)

#43

Post by TobTobXX »

yakubin wrote: post #25
cgeier wrote: post #16

Earlier quoted context omitted.

Which discontinued Neovim GUI do you mean? As far as I know, while there are lots of discontinued ones, there are also several actives ones, see [1]. The "Activity" column in the linked table doesn't always show the correct age, e.g. vimr [2] is at least three years old. [1] https://github.com/neovim/neovim/wiki/Related-projects#gui [2] https://github.com/qvacua/vimr

I was mostly thinking about Neovide[1], which is active, but I've read somewhere that Neovim was planning on not supporting this idea (of multiple GUI frontends) and that they were going to focus on the terminal UI. Maybe that was wrong though, since it's still listed on the Wiki you linked, and Neovide is still getting new commits. [1]: https://github.com/neovide/neovide >

Neovim is not developping GUIs themselves, but they are actively maintaining the API these GUIs use. It's even listed as a feature on their homepage[0].

[0]: https://neovim.io/

Re: History and effective use of Vim (2019)

#44

Post by kekebo »

herodoturtle wrote: post #7
vaylian wrote: post #3

Earlier quoted context omitted.

> You can only imagine how, in command mode, he effectively summons the textual equivalent of the Nine Hells of Ba'ator upon my open documents if I am not quick enough... There's always [u]ndo. Or you can use :earlier 2m to go back 2 minutes in time.

> to go back 2 minutes in time. Wut. ~27 years of using vim, you just blew my mind.

[distant yelling of human segmentation faults]

Re: History and effective use of Vim (2019)

#45

Post by Izkata »

h0l0cube wrote: post #21
christophilus wrote: post #17

Earlier quoted context omitted.

This is me all the time. The worst is “kkk”. I can’t remember why I type it in vim (it’s muscle memory, and I’m not at a computer to try it out), but it has really bad connotations here in the US south, so… no bueno.

Unsolicited advice for scrolling without spamming j and k: - C-u and C-d to jump up/down - [ and ] to go prev/next empty line (I have a macro to clear empty spaces at the end of lines so this works well for jumping functions in code) - from the article: 50% to go the halfway point of a document - 100gg to go to line 100 - 100k to go 100 lines down Are there any more good ones? Edit: occurs to me that you might have r…

  :set relativenumber
The line the cursor is on is now shown in the left sidebar as 0, counting up for each line away from the cursor. So now it tells you what number to use for "10j" and "10k" to move up and down a specific number of lines.

   m[a-z]
   `[a-z]
Mark a point in a file into a register, and jump back to that point. Or even more interesting:

   m[A-Z]
   `[A-Z]
Same as above, except capital marks are global and work across files.

Also,

   ``
Jump back to the last place you jumped from (but only within the same file).

Re: History and effective use of Vim (2019)

#46

Post by petepete »

sophacles wrote: post #42
citrin_ru wrote: post #40

Earlier quoted context omitted.

When your are working with huge files or files with huge lines it makes sense to disable syntax highlighting to improve performance (:syntax off).

If you use neovim with tree-sitter, this is not really true anymore! Or at least it extends the huge file/huge line boundary pretty far.

Tree sitter is amazing. It even works really fast on huge minified files.

Re: History and effective use of Vim (2019)

#47

Post by petepete »

mianos wrote: post #34

What amazed me is pathogen does not seem to be used anymore. Maybe I'll have to try the new way.

I was a Pathogen user for a long time, from about 2009-2020. It was a total gamechanger. I'd still use it except for the fact that with vim-plug I can more easily keep my config under version control. git submodules are a hassle.

Re: History and effective use of Vim (2019)

#48

Post by Izkata »

yakubin wrote: post #19
doix wrote: post #15

Earlier quoted context omitted.

What's wrong with the way it handles long lines? It can either wrap or not wrap depending on your configuration. Personally, I disable wrapping in every editor I use because I find it extremely off putting. I'm curious which behavior you desire and if you have any examples of editors that you think handle long lines well.

Performance. I mean really long lines, not merely lines which exceed window width. Vim is a bit better at that than Emacs, but it still slows to a crawl on some large lines. Sublime Text e.g. never has any problems with long lines on the other hand, no matter how long.

I've found that to mainly be a problem with syntax highlighting. Turning it off speeds it up significantly.

Re: History and effective use of Vim (2019)

#49

Post by Izkata »

asicsp wrote: post #41
yakubin wrote: post #35

Earlier quoted context omitted.

A GUI can draw vector graphics, like lines, arcs, arrows etc. GVim still behaves like a terminal, which just has a grid of characters to work with. Any such vector graphics is done awkwardly with fonts, which doesn't give the best result, and patching fonts is not the best UX.

Thanks for further clarification. I haven't needed such capability in a text editor, but probably I should look into what that provides. And I don't see how such features are necessary to rule GVim as GUI. I have a fairly basic classification: TUI runs in a terminal, GUI have their own windows.

You said above you use it without the menu/toolbars, which is the GUI interface. What you've described is identical to, say, "xterm -e vim", so, TUI.

Re: History and effective use of Vim (2019)

#50

Post by Karunamon »

asicsp wrote: post #41
yakubin wrote: post #35

Earlier quoted context omitted.

A GUI can draw vector graphics, like lines, arcs, arrows etc. GVim still behaves like a terminal, which just has a grid of characters to work with. Any such vector graphics is done awkwardly with fonts, which doesn't give the best result, and patching fonts is not the best UX.

Thanks for further clarification. I haven't needed such capability in a text editor, but probably I should look into what that provides. And I don't see how such features are necessary to rule GVim as GUI. I have a fairly basic classification: TUI runs in a terminal, GUI have their own windows.

GVim is a GUI in the same way that a terminal app is technically a GUI. It is surrounded by GUI chrome and has menus and such, but you are working with unstyled plaintext as you would in any other terminal window.

Put this another way, you can tell the difference between something like vim and Emacs versus Kate and Microsoft Word. It is not necessary to get into the minutia of what makes all these text editors different to understand that they are fundamentally different kinds of applications. The former two are clearly terminal apps with GUI chrome around them, the latter two are clearly GUI apps.

Post reply on HN