Vim-stay

>vim-stay
1047 lines for a plugin that does literally the same thing as 10 lines of au commands
why do people do this?

Attached: 190717-1253-59.png (997x999, 155K)

Explain, retard

Just use nano lmao

>1047 lines for a plugin that does literally the same thing as 10 lines of au commands
vimtards slowly are realizing that uganda-cum and huwhite-hacks are used to hold together this piece of shit software.

Attached: vim_drill_small.jpg (518x376, 70K)

Emacs doesn't have this problem.

I already had this copied from some old vimrc

"" Jump to last cursor position
augroup vimrcex
au!
autocmd bufreadpost *
\ if line("'\"") > 1 && line("'\"")

It's 755 lines when you exclude the doc... but that's still absurd

If it does the job, it does the job. What's the problem?

>a shitty community plugin means the whole editor is shitty

Speaking of bad vim plugin developers, has anyone actually read Tim Pope's plugins?
He is actually shit at vimscript

You got a lot of nerve complaining about bloat as a powerline user.

Afaik your second autocmd is not necessary because mkview and loadview save the cursor position by default.

This is all I have between OP. Do you see something wrong with it?

" restore the cursor position
au BufWinLeave * silent! mkview
set viewoptions-=options
" use 'silent!' because ':silent' silences everything but errors:
au BufWinEnter * silent! loadview


It works for cursor position, folds etc.

>Powerline user
>Reeeeing about loc bloat
Pottery

Nodejs, does the job
let's program OS in it

I read a reddit thread about a vim user being obsessed over minimalism and having like 100 lines long vimrc and trying to be productive with it

What's so remarkable about having a 100-line vimrc? Are you trying to make some kind of a point?

Vim users are obsessed with their editor and spend alot of time learning it than coding. Emacs is the thinkings man editor

dont pretend emacs isnt the same way
t. somebody that uses both

>vim users learn stuff and think about their toolchain
>yet somehow emacs is the thinking man's editor
I can see you're not a thinking man for sure. Besides, it's usually vimfags who do less customization than emacsfags, emacs is a known timesink, owing to its flexibility.

Emacs encourages maximalism not minimalism. The packages are quality and every single one of them are reviewed before getting pushed to any repository. You wont have dumb niggers doing dumb shit. Emacs has packages for everything, you dont need to know elisp. Emacs interfaces are way better and not as raw and ugly like in vim, way better language integration, proper IDE like debugger, code overlays etc theres just too much to name why emacs is superior.

Not really, you dont obsess over minimality on emacs. Everything is implemented, you just need to install packages. In terms of customization you customize more by adding packages true, but you dont stay learning the core features or have 100 lines config like on vim because muh minimality. You lower your productivity too much

>but you dont stay learning the core features or have 100 lines config like on vim because muh minimality
What the fuck does this even mean? You're quite obviously a brainlet regardless your choice of text editor, so I won't waste my time arguing with you further.

Being productive on a vimrc thats 100 lines long requires knowledge on vimscript and vim core features. You are learning random irrelevant stuff about editor while i just install a package that does what you want to do on vim 10x better, kek

cope
seething
yikes

oof

>He is actually shit at vimscript
Maybe, I don't know vimscript to dispute that claim. His plugins are still goat though. Vim-surround is comfy as fuck.

vimrc is no different from init.el, brainlet

They are good but I expect you would see better performance, cleaner interfaces, fewer bugs, and lower bar of entry for contributors if they were rewritten.

You can definitely be productive with a .vimrc of that size. I have < 200 lines and I still have tons of modern conveniences and extra stuff that is not at all minimalist. As you use vim more and more, you realize a lot of the features plugins add are already handled by the editor in a nicely integrated way.

What do you use?

>learning stuff about an editor you don't use is irrelevant information
Nice lack of theory of mind, literally autistic

Editor is for editing, not interested in learning vimscript or going through vim help pages for hours. Pretty useless information that just wastes time i could put towards code. Emacs is opposite while being highly customizable. Everything is implemented. No need to take time to learn elisp or learn deeply about editor

Okay so stick to emacs then? No one gives a fuck.

Seething vim tranny

Trolled me hard

vim is poorly written bloated trash and is a productivity hindrance in any case

just bind alt+hjkl and stop larping

based

You call everything "implemented" because it uses your workflow and you consider all configuration and features in vim a waste of time while your packages and features that you use take 0 effort because you've learned them already. You are still autistic and have no concept of other people, perfect example of the "emacs is the perfect editor" poster.

People who say this have no understanding of the Vim editing model, the keybindings are the absolute surface level part of it. I've noticed a lot of people who switch 100% to Emacs never bother to learn how to properly use it, and certainly the lifelong Emacs users don't understand it.

True. Best of both worlds is a highly tweaked emacs+evil setup, but people who use normal emacs control scheme are like cavemen compared to proficient vim users.

I would say best of both worlds is learning both editors personally, but yeah that works too.

A .vimrc will be user generated eventually, as long as remembering :x is save and exit isn't a total roadblock to your learning curve.
Otherwise, you install nano.
Just like if you can figure out how to configure top, pretty soon you're gonna have a .toprc. If you don't learn to configure top, you install htop.

>If you don't learn to configure top, you install htop.
that's not true, you can't configure top to send out signals the same way htop is able to.

You could and people have done it. If you have high standards but no donations to cover them, shut the fuck up. Nobody will waste his time optimising code for you.

they are a fucking mess. I've replaced a few with ruby scripts that run faster and work better (in neovim at least, not sure how well a ruby plugin would perform in normal vim i know they've improved but its been years since i used it)

>"lower bar of entry for contributors"
>the software is inelegant because a novice wrote it
>if we make it more elegant, novices will be able to understand it
>if novices are able to understand it, they'll be able to contribute
>if novices can contribute, we'll be able to make the software inelegant again
wait what

Attached: 1559573693756.gif (388x394, 33K)

>a novice wrote it
Tim Pope is not necessarily a novice. He is just not pragmatic and does not make clean software. Plenty of experienced developers do this, sometimes their entire career.
>if novices can contribute, we'll be able to make the software inelegant again
If you write simple, clean, modular software, contributors are less likely to break things and the changes will be easier to check for mistakes.
Also, I would prefer that novices be able to submit rough patches for issues that I can then clean up rather than submit untraceable issues.

Making clean software also makes it easier for everyone to make changes, not just new developers, but yourself in the future when you've forgotten the function and other good contributors who didn't write the project.

Overall the benefits of writing clean software vastly outweigh any downsides, and you can always raise the bar in other ways if you don't want anyone to be able to submit a patch.

k is kill. r is renice. You are prompted for a pid, then a signal (or niceness)