▶ No.991861
Assume I don't. Now fuck off.
▶ No.991865>>991866
I think using different modes as opposed to key combos is for a different type of brain. Your mother as prefers more flexibility being fingered rather than staying in one spot.
▶ No.991866
▶ No.991867>>992091
i like vim, it's just not programmed in rust.
▶ No.991868
It's bloat, but atleast it's not retarded when using over ssh.
▶ No.991869
>terrible scripting language
>shitty defaults
>benefits people far away from the author instead of people near to the author--using it is to promote civilizational cuckoldry
>makes it easy to use a really terrible encryption system
>too much cruft, too much code, too much bloat, for too little gain
>'c' commands just delete the original text instead of letting you overwrite it because author is lazy shit
▶ No.991871>>992044
▶ No.991874>>993919 >>993968
>look mom, no mouse!
You just make things harder on yourself.
▶ No.991876>>991879
https://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-vim/
Literally explains everything wrong with VIM.
Neovim is pretty good too, but could be a bit more minimal.
▶ No.991879>>992246 >>992496
>>991876
Beat me to it. From Geoff's patch submission, you can see how stupid some of the Vim developers are, too.
https://groups.google.com/forum/#!msg/vim_dev/-4pqDJfHCsM/LkYNCpZjQ70J
>This patch adds asynchronous functions to vimscript
<It looks like this is not really "asynchronous" behavior, but rather adding a timer-like hook into the main loop.
>You are correct in that we added a timer to the main loop. Looking over the code once again, I think we should have altered the calls to select/poll instead, but lets discuss the practical effect of this patch since we can work out the details some time later.
>Async does not imply parallelism nor safety- it only provides the illusion of concurrency. Idle cpu time spent waiting is instead used to perform some other task. Async frameworks make no such guarantee that every call not block the event loop; it is incumbent upon the programmer to ensure that the event loop is not blocked indefinitely. This is the definition and standard interface of async programming for every popular framework I can think of that lives in a scripting language- JavaScript, nodejs, twisted, event machine, and luvit.
>The current alternative in Vim is to block forever, or worse yet, not write useful software because it is impossible to do so as a Vim plugin. With a proper settimeout, plugins have the option of returning control to the main loop and checking in latter.
<I'm more familiar with C/C++/Java, and even shell scripting, where "async" means it doesn't block the main program flow, as wikipedia says on http://en.wikipedia.org/wiki/Asynchrony: "Asynchronous actions are actions executed in a non-blocking scheme, allowing the main program flow to continue processing."
<So, in my mind..."async" normally implies parallelism.
Neovim > Vim
There's also some nice GUIs built on Neovim, pics related.
https://github.com/onivim/oni
https://github.com/dzhou121/gonvim
▶ No.991882>>991900
All the shit to do with extensions and scripting is trying to turn it into emacs, while lacking (by initial design) any foundation in such usage. So we're heading into a situation where emacs' evil-mode is becoming a better "vi" than Vim is.
▶ No.991891
>>991858 (OP)
Muh Ugandan nigglets.
▶ No.991894>>991905
Vim is one of the rare sane choices. Like everything, it has its bad sides, but it's far better than today's (((Electron))) editors, like (((M$ Visual $tudio Kode))) for example. If you really mind Vim's downsides, you can go with some of others like Emacs, Ed, Nano. If you are such a soyboy to use (((GUI))) exclusively, the only I can recommend without losing my dignity as a non-NPC is Sublime.
▶ No.991900
>>991882
>heading into a situation where evil-mode > vim
that's actually already the case. I use vim in some niche cases still, but evil-mode is unquestionably a better vi.
▶ No.991905>>992236 >>992362 >>992367
>>991894
Next time, can you type like a human, instead of a markov chain? Thanks
▶ No.991906
Chords > Modal when you must always switch mode for advanced movement (words, lines, paragraphs).
▶ No.991907>>991911
vimscript is ass.
I've used vim for a good long time. Then I started picking up Scheme (Guile and Chez) so I switched to Emacs for that. It is so much better to configure. Now I use it for most programming I do.
I still use vim for tiny edits or CLI stuff but I should probably train fingers to type nano instead of vim for that.
I still haven't tried evil mode because I'm afraid of how much I'll like it.
▶ No.991909
>>991858 (OP)
I do not hate it, but I prefer GNU Emacs because I can easily extend it.
▶ No.991910
>>991858 (OP)
Typescript support and in general autocomplete and syntax checking is either cumbersome to setup, slow, fails too often, or all of them. I would be using Vim were not for these problems.
I use VSCode.
▶ No.991911>>991926
>>991907
>nano
your a idiot
▶ No.991926>>991928
>>991911
You're going to have to explain what you think is better for small text edits and why using nano is idiotic.
▶ No.991927>>991930
Vim's problem is that it didn't actually live up to its name. It didn't "improve" vi outside of the most basic conception of an "improvement." About the only thing it has over vi is text objects, but that's not really worth all the extra problems that it causes.
▶ No.991928>>991932
>>991926
>have to pass a flag to not let the editor fuck up long lines
>all the downsides of a terminal interface with no compensating benefits
>people only use it because typing 'vimtutor' , pressing enter, and then concentrating for 30min is too much trouble
▶ No.991930
>>991927
What extra problems?
▶ No.991931
You can't use it to edit files on remote machines.
▶ No.991932>>991935 >>991937
>>991928
>have to pass a flag to not let the editor fuck up long lines
What part of "small text edits" did you not comprehend?
>all the downsides of a terminal interface with no compensating benefits
What part of "small text edits" requires loading up a whole fully featured editor?
>people only use it because typing 'vimtutor' , pressing enter, and then
What part of "I've used vim for a good long time" did you not comprehend?
The critical thinking on this board is lacking.
▶ No.991935>>991936
>>991932
>small text edits
>xir meant editing small text not small edits to text
>muh reading comprehension
Improve your writing skills duder.
▶ No.991936>>991938
>>991935
>your a idiot
>no punctuations
>Improve your writing skills duder.
>duder
So much bait!
▶ No.991937>>991940
>>991932
if you've used vim for any length of time, there's no reason to use nano at all.
▶ No.991938
>>991936
I_have_autism.txt
▶ No.991940
>>991937
Fingers are getting used to emacs movements and non-modal editing.
▶ No.991997>>992012
I've been trying to use Vim for awhile now, but I cannot find any way to jump to a C/C++ function definition which is found in some arbitrary library outside of my project. The only solution I can find would be to create ctags for literally every library on my machine, which sounds incredibly stupid. Is this really the state of Vim or is there a better way to do this? I'm porting some software from library X to library Y where neither library has appropriate documentation, so I have to jump to read the source of both of them as I work.
▶ No.992012>>992022
>>991997
>The only solution I can find would be to create ctags for literally every library on my machine, which sounds incredibly stupid
If what you want is something like Visual Studio's behavior, keep in mind that it uses project files which hold (or link to) equivalent information. It can abstract some details because it can afford to make a large number of assumptions where an environment-agnostic text editor can't.
The first problem you'll face is trying to figure out where your libraries live. VS has a project variable for that. Makefiles, for example, don't. Making heuristic assumptions will yield more bad than good. Even assuming that such a problems were trivial to solve, you'd then end up having to re-implement a ctag-like indexing system as a plugin for your text editor. Well, you don't *have* to, but if you don't care about indexing then ack/ag are already available.
▶ No.992022>>992028
>>992012
How is it that a plugin like syntastic is able to determine whether or not I have a syntax error without building this database of information? Presumably, if I use a particular function, it must know which header file that function is defined in to be able to determine the proper syntax and compare to what I have in my code. It seems like whatever functionality is being leveraged for syntastic should also be able to be leveraged to jump to the function declarations.
▶ No.992023
>>991858 (OP)
It's flat out terrible for generic, low volume text viewing and editing, and it's terrible for coding as any non-IDE solution is.
When notepad is a better tool you really need to pause and think about what went wrong.
▶ No.992026>>992028
>>991858 (OP)
Comparing Vim with others is pure autism.
First of all, it's released in 1991. 17 years before Sublime text.
Secondary I think the usage areas are different. I'm using Vim if a little error occurs while running my script on a terminal. I'm fastly fixing the problem with it. But using it for your serious projects is stupid.
▶ No.992028>>992033
>>992022
Never used it but I assume it just looks at whatever files you have or had opened and builds a declaration/definition/assignment/reference database in your RAM or in your .vim. Maybe it looks through "usual suspect" library directories. There would also have to be some ugly "good enough" magic happening behind the scenes that have likely led developers on wild goose chases, e.g. it read the right file from the wrong lib version and gave someone a real head scratcher as they ended up looking at filter_next instead of filter_prev because between the two lib versions, lines were added or removed before these code blocks, offsetting the line numbers.
Obviously, jumping to and from entities within a single file isn't subject to these issues. The lexer built for the syntax highlighter not recording and remembering them is more of legacy issue as well as plugins or even just string searches already doing the same thing. See >>992026
>First of all, it's released in 1991. 17 years before Sublime text.
However,
>using it for your serious projects is stupid
is stupid
▶ No.992030
It doesn't take commands from stdin like ed does
▶ No.992033>>992046
>>992028
>but I assume it just looks at whatever files you have or had opened
It is aware of files I have never opened which are part of system installed libraries that I have never touched with a text editor.
>Maybe it looks through "usual suspect" library directories
All libraries are installed in a standard location. Headers can be found in /usr/include which I'm sure is passed around in some environment variable. I'm sure any sensible plugin would leverage that.
It seems clear to me now that Vim is not meant for serious development work. Guess I'll just stick to using an IDE.
▶ No.992043
>>991858 (OP)
nvim is better.
▶ No.992044
>>991871
This guy has never used vim before.
▶ No.992046>>992051
>>992033
>this nigger tier behavior trying to get someone to hand hold him through installing plugins
lmfao back to your IDE pleb
▶ No.992051>>992058
>>992046
You don't need to tell me twice. I'd way rather use something that works and has basic functionality that has been around for decades compared to your toy editor. Have fun working on your hello world program, anon.
▶ No.992054>>992065 >>992078 >>992082 >>993172
Vim is a terrible hack. It's a gigantic monster that implements its own (terrible) scripting language; and the defaults suck so people use the broken plug-in system. It has more legacy code than OpenSSL, is designed for QWERTY, and is used by ricer glitterboys who love to extol superficial minimalism (because if it has a TUI, it must be minimal, right?) -- Vim is thousands and thousands lines of C with API bindings for every other programming language. Vim is hard to extend and improve, so users resort to limited hacks with its language bindings. Vim is the definition of crappy software. A bunch of amateurs on github are trying to clean it up, but it is a monolithic hack by design. The so-called "superiority" of model editing is also patently false, because:
a) It is designed around the worst keyboard layout
b) If you're really in love with modal editing, you can emulate it using Emacs.
The editor part of Emacs is temacs - which is just a few hundred lines of C. Everything else is elisp. What do I recommend? ed, mg, even nano. Barring those, use Emacs. When you start Emacs, the extensions (written in elisp, much better than vimscript) are loaded into temacs, and then the core is dumped as the Emacs executable. The binary size of Vim used to be much smaller, which was something Vim users loved to bring up, but now they're getting close -- proving that Vim is just hacks upon hacks.
Do you know how much trouble people are having trying to make Neovim good? A lot, because the Vim codebase is dogsoykaf*
>I started programming in C almost 20 years ago. Vim is, without question, the worst C codebase I have seen.
>Copy-pasted but subtly changed code abounds. Indentation is haphazard. Lines contain tabs mixed with spaces. Source files are huge.
>There are almost 25,000 lines in eval.c. That file contains over 500 #ifdefs and references globals defined in the 2,000 line globals.h.
>Some of Vim’s source code isn’t even valid text. It’s not ASCII or UTF-8. The venerable file can’t figure out the encoding.
>Many of Vim’s #ifdefs are for platforms that became irrelevant decades ago: BeOS, VMS, Amiga, Mac OS Classic, IRIX. These preprocessor statements may seem innocuous, but they slow development and inhibit new features. Also, Vim doesn’t even work on most of these platforms anymore.
*https://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-vim/
*https://geoff.greer.fm/vim/#realwaitforchar
The people who use Vim _love_ superficially "minimal" software (i.e. software that appears minimal but has a terrible codebase). Software like i3, cmus, and urxvt. How many people use the Vim defaults? Almost none, that's how many. Emacs is (relatively) modular unlike Vim (It does have a lot of legacy cruft, not going to deny that; Stallman holds the project back). Emacs is a Lisp engine/interpreter with an editor-like interface. Parts of the buffer can be interpreted as Lisp, the session is a dynamic Lisp runtime, Lisp is its configuration language. Vim is all the code bloat of Emacs with the magic of ifdef hell, and people use tons of plug-ins/thousand line .vimrc config files making it even more adipose, because the defaults are egregious.
▶ No.992058
>>992051
You forgot to mention 'out of the box' and then run your fingers through your wispy combover to add further emphasis.
▶ No.992063
Because it's impossible to use. I prefer something really easy to use like emacs, even though it's bloated.
Also it can make you sound like you're programming to your colleagues while you're really playing tetris.
▶ No.992065>>992066 >>992076
>>992054
>thing is bad
>therefore everything about thing is bad
qwerty's fine. You think you benefit from alternative layouts because you grew up on qwerty and then only learned to type properly with those layouts. t. someone who had to re-learn qwerty years after completely overwriting his muscle memory with proper dvorak.
modal editing is fine. Yes, Emacs does it very well with evil-mode. Remember to add melpa to your package managers and immediately install evil-mode, kids. You don't need to go full spacemacs.
>superficially "minimal" software
what's stopping them from liking software that's actually minimal, like dwm, sic, and st?
... oh? nothing? the impulse that draws one to the mirage also draws one to the oasis?
people mostly deal with vim's problems by not improving it. on servers, for editing random files, it still beats utterly worthless programs for idiots like nano, or utterly worthless recommendations by idiots like mg and ed. And it's still more minimal than Emacs.
I have :set ts=4 sts=4 et sw=4 in muscle memory. That and variations on that is enough for vim as a server editor. neovim would be fine too, but most other vi-likes are just buggy or less pleasant, and non-vi editors mostly aren't even worth speaking of: an editor just can't be any good without having keybindings you have to learn, be they original or a copy of vi or emacs.
▶ No.992066
>>992065
decent vi-likes that aren't vim:
vile (but its handling of long lines is painful)
vis (maybe)
▶ No.992070>>992075
>>991858 (OP)
>Assume you hate it. Now tell me why.
Because ed.
Ed is the standard text editor.
Ed, the greatest WYGIWYG editor of all.
ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN SHINE AND THE BIRDS SING AND THE GRASS GREEN!!
When I use an editor, I don't want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!! Not a “viitor”. Not a “emacsitor”. Those aren't even WORDS!!!! ED! ED! ED IS THE STANDARD!!!
▶ No.992075
>>992070
go home Ed, you're drunk
▶ No.992076>>992079 >>992082 >>992084
>>992065
>>thing is bad
>>therefore everything about thing is bad
Everything about Vim is, in fact, bad.
>qwerty's fine. You think you benefit from alternative layouts because you grew up on qwerty and then only learned to type properly with those layouts.
Nice projection?
>what's stopping them from liking software that's actually minimal, like dwm, sic, and st?
The fact that those are unusable garbage; dmenu is their only worthwhile project.
>on servers, for editing random files, it still beats utterly worthless programs for idiots like nano
200 hours learning Vim for a 2% advantage over a nano user.
▶ No.992078
I've never understood why people keep recommending Sublime on forums/boards like this?
>Sublime Text is a proprietary cross-platform source code editor with a Python application programming interface (API).
>License Proprietary software,[2] Nagware
>OS Only Windows, OSX, and Linux (select distros)
Proprietary, Python, nagware.. I'm not personally a fan of those things. Admittedly I've never used it but honestly it seems to espouse things I only put up with in gaymz.
>$80
Is it really worth that much though? Maybe it is and I just don't know but why when Emacs is free in multiple meanings of the word.
>>992054
>even nano
Uh oh. Watch out saying that here. People might get upset.
▶ No.992079
>>992076
Does Nano even support go to definition or autocompletion?
▶ No.992082>>992252 >>993217
>>992054
>Software like i3, urxvt
>>992076
>dwm and st are unusable garbage
Ok, mister contrarian. What WM and terminal emulator do YOU recommend?
▶ No.992084
>>992076
>200 hours
vimtutor.
time it.
you can go on to learn one new vim feature at a rate of once per year and still benefit. meanwhile even the most basic file navigation is painful in nano
>projection
it beats having nothing at all to go on
>unusable garbage
dwm and st? maybe if you can't figure out how to read their manpages. sic is fine enough as a starter kit for your own IRC client.
get your tabs from tmux.
▶ No.992091>>992093
>>991867
Nothing good is made in rust.
▶ No.992093>>992096 >>992194
>>992091
tor
<inb4 I said good
▶ No.992096>>992194
>>992093
>335k lines in .c files
>4k lines in .rs files
<rust is so high level and expressive that these are comparable line counts really
▶ No.992132>>992150
>>991858 (OP)
>he doesn't use vis
>he has to deal with almost 1,000,000 lines of code, majority of which he'll never use
>he isn't comfy with a 20K line editor with advanced structural expressions
▶ No.992150>>992160 >>992164 >>992184
>>992132
ohh look a vis fag, maybe you can answer my question
is there any way to disable it's windowing system currently ?
last time I checked there wasn't
t. tmux+vi 4 life looking to migrate
▶ No.992160>>992185 >>992191
>>992150
Switch to nvim and use :terminal, it is way better than :term. Also I use tmux+nvim and frequently use terminal buffers due to how easy it is to search through them.
▶ No.992164>>992191
>>992150
why do you need to disable vis's windowing system to use tmux?
do you mean that you want vis to interface with tmux in some way, instead of being like all the other dumb terminal programs that tmux manages?
▶ No.992184>>992185
>>992150
do you mean the split windows? because you can just not use that, although i don't know why you would.
▶ No.992185>>992191
>>992184
i suppose you could go into the code and remove that yourself and just recompile, but there's really no point in doing that unless you know what you're doing
>>992160
>using neovim
▶ No.992191>>992217 >>992272
>>992160
I don't want to use nvim because there's no fucking way I can compile without uneeded garbage (personal opinion).
Vim had tiny and you could go even lower than that but from what I know neovim doesn't have that.
And I was talking about vi not vim.From what I can see both neovim and vim now have terminals ? what in the name of fuck
>>992164
>do you mean that you want vis to interface with tmux in some way, instead of being like all the other dumb terminal programs that tmux manages?
no,for example in vim from what I remember if you :open another file it opens another buffer and focuses on it; when I tried vis it just split into another window showing both windows.
I just want one buffer, one window, one tab, minimal vi like editor which won't have/do something I don't like. I'm at the point where I'd rather write my own editor.
>>992185
>but there's really no point in doing that unless you know what you're doing
too tiresome for an editor I practically know nothing about
▶ No.992194>>992197
>>992096
>>992093
What in tor requires rust?
I just did a quick emerge --pretend and doesn't pull in rust at all.
If it does use rust, then it's not for key functionality.
▶ No.992197>>992198 >>992199
>>992194
They're in a process of migrating the project to Rust piece by piece.
▶ No.992198
>>992197
That doesn't mean it's good at all, it just means they're confirmed pozzed and stupid.
▶ No.992199
>>992197
three years in the making, and already 4k lines of code! This must be the most successful RIIR endeavor yet.
▶ No.992212
no programs manual should be larger than the source code.
▶ No.992217>>992225
>>992191
>I just want one buffer, one window, one tab, minimal vi like editor which won't have/do something I don't like.
Have you checked out nvi? It's just the Berkley version of the original vi. I'm a vis guy myself, so I don't know much about it. But providing you don't care about all the new features vis offers, then I'd consider giving that a look.
▶ No.992225
>>992217
It's what I'm using.
▶ No.992236
▶ No.992246
>>991879
>There's also some nice GUIs built on Neovim
Are they good for a daily use?
▶ No.992252
>>992082
i3 is heavier than Window Maker and FVWM.
▶ No.992270
>>991858 (OP)
I's hard to use and I can't close it. I always remove it and then make symlink to nano.
▶ No.992272>>992308 >>992319
>>992191
It's a shame, deoplete is probably the best completion engine available right now. It just works and works better than basically any other completion engine I have used before.
▶ No.992292
>If you're editing multiple files you can change to the next file with :next
>or go back to a previous file with :previous or :Next
>next file = :next
>previous file = :Next
▶ No.992308>>992521
>>992272
>deoplete
please expand on this if you have time
I feel like using autocompletion makes me too dependent on it.
▶ No.992319
>>992272
I've had some problems with deoplete, it's just plain froze my vim before. It also spews errors I don't care to look at or fix with some of the completion engines too python
▶ No.992362>>992366
>>991905
ITT reading comprehension is below 0
▶ No.992366>>992367
>>992362
>Next time, can you type like a human, instead of a markov chain?
Sorry, which time do you mean. Next time or next time? previous time? Is there a Previous time?
When will then be now?
▶ No.992367
▶ No.992416
>>991858 (OP)
I don't hate it, I just personally dislike it and prefer Emacs
Its mode based editing thing just doesn't jive with me, you know?
▶ No.992424
>>991858 (OP)
I don't use it. I think Gnu Emacs is better. Because Gnu Emacs has better docs, better extensions and better customizability. You can emulate the (((uganda editor))) in Gnu Emacs, if you really want to.
▶ No.992430
▶ No.992457
The codebase is shit and it shows in how fucking slow it is compared to something like vis, Vim (the software) is shit, Vim (the editing style) is good.
>inb4 muh dvorak
▶ No.992464>>992469 >>992472
>>991858 (OP)
>shitty customization language
>written by a literal HIV-positive cuck
>used by web devs
>c code base is bigger than the emacs one
Daily remainder.
The holy editor war was between Emacs and vi, not vim.
Vi is UNIX way. Emacs is Lisp way.
The keybindings were irrelevant.
If you want a minimalist vi-like editor, use nvi or vi itself.
If you want a customizable development environment use Emacs, it completely implements vi.
For those retards who still use Vim.
Why haven't you yet donated some money to Bram with his AIDS treatment?
▶ No.992469
>>992464
s/to Bram/to help Bram/
▶ No.992472>>992523 >>992568
>>992464
>The holy editor war was between Emacs and vi, not vim.
And they are both shit.
ed was given to us by Ken Thomson and Dennis Ritchie themselves.
ed is the standard Unix text editor.
Ed is for those who can remember what they are working on. If you are an idiot, you should use Emacs. If you are an Emacs, you should not be vi. If you use ED, you are on THE PATH TO REDEMPTION. THE SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE
FAITHLESS. DO NOT GIVE IN!!! THE MIGHTY ED HAS SPOKEN!!!
▶ No.992496>>992503 >>992563
>>991879
Is there any reason to use this over vscode since its an electron abortion as well?
▶ No.992503
>>992496
I wonder how soon an editor with this many pop-ups, hints, tips and completion suggestion will cause retardation.
It also looks gay as fuck, probably could give you AIDS as well.
▶ No.992521>>992544
>>992308
tldr: You start typing and things pop up asyncronously. I primarily use it for go as it is smart enough to detect everything in the standard go library, also works on files, things in other buffers, tmux panes, and basically anything you can imagine.
I don't think I've ever seen it freeze with nvim. Maybe you are thinking of another completion engine like YCM or VimCompletesMe.
▶ No.992523
▶ No.992544
>>992521
How this 20 line long pop-up is even helpful?
What a nigger would put a struct or a static inside a main function?
▶ No.992547
It's not a good example. Best case is if you have a class and you don't want to open the class's declaration in another buffer or constantly Ctrl+] to see the definition of things.
▶ No.992551>>992552
>deoplete
>Shougo/deoplete.nvim
Hmm, any of you using Shougo's dein.vim then?
▶ No.992552>>992560
>>992551
Yes I use dein as well but I am not fond of it, I feel like there are other plugin managers that work better are are less likely to randomly break.
▶ No.992560>>992564
>>992552
There is literally nothing wrong with Vundle
▶ No.992563
>>992496
>electron
If you're referring to the Neovim frontend, the docs said it was implemented in Go. Tbh I wouldn't use it because its still pretty new and probably has kinks to work out. I prefer Sublime.
▶ No.992564
>>992560
I used Vundle before I moved to dein. Absolutely amazing plugin. I don't know why Shougo has so much hate for it.
▶ No.992565>>992675 >>993173 >>993188
I used it religiously for years until I gave Emacs a chance.
It’s much easier to write Elisp for Emacs than VimL for Vim.
Modal editing is trash and fucks with your muscle memory when you’re using other applications. This is why there are all kinds of browser extensions to enable Vim users to carry over their reflexes.
“Donate to kids in Uganda!”
Plain old text editors are not powerful enough for modern programming. With Emacs you can approach the standards of a modern IDE. With Vim it comes nowhere close. You have to make the shell your IDE, which is extremely unproductive.
▶ No.992568>>992570 >>993050 >>993222
>>991858 (OP)
if IQ < 100 then
hate_vim = true
else
hate_vim = false
endif
>>992472
>ed
you are almost at the path of enlightenment qed is the father of ed
▶ No.992570
>>992568
*meant to post this one instead
▶ No.992675>>993098
>>992565
Emacs, despite being the same age as vi feels a lot more "modern" in a lot of ways. I use text editors for mostly long-form writing, and something like org-mode or rst-mode is far more intuitive than vim's markdown plugins.
▶ No.993050
>>992568
>enlightenment
Did Gary Kildall reach true contextual enlightenment with his version of ed? Or was that just blasphemy?
▶ No.993063
>>991858 (OP)
Assume OP suck dick. Now tell me why.
▶ No.993098>>993224
>>992675
WYSIWYG editing really is important. Markdown is just a way to emulate it in a text only editor, and of course it does a rather poor job. I see so many fags trying the fix markdown because it's ambiguous and hard to script, but they forget that whatever replacement they're proposing is piss ugly, and no one wants to look at it while writing.
▶ No.993167>>993188 >>993224
>>991858 (OP)
Vimscript is ass and Neovim's plan to replace it with Lua will only make the situation marginally better. They should leapfrog emacs (elisp is old and crusty by lisp standards) and integrate a Scheme implementation.
▶ No.993172
>>992054
The author of emacs crippled himself with RSI by using his own creation. This is proof that emac's defaults are downright harmful. You should be using evil mode if you value your good health.
▶ No.993173
>>992565
>Modal editing is trash and fucks with your muscle memory when you’re using other applications.
This isn't true if you're smart and set a custom color scheme for your modal text editor. When you see that color scheme, your modal editing muscle memory kicks in. When you don't see that color scheme, you modal editing muscle memory is not activated.
▶ No.993188>>993191
>>992565
>With Emacs you can approach the standards of a modern IDE.
hahah oh wow
>>993167
Scheme is garbage and slow.
▶ No.993190
Just use an IDE.
>all the features you ever need out of the box without spending years setting it up
>sane defaults so no modal editing trash or RSI
IDEs are the future and you know it
▶ No.993191>>993192
▶ No.993192>>993200
>>993191
>compiles to C
>suggesting this as an alternative to Lua
retard bots begone
▶ No.993200>>993226
>>993192
it's not trash and it's not slow, and "compiles to C" is the objection of a brainlet.
▶ No.993217
>>992082
Not him but I use i3 but DWM is good too
And I use ST
▶ No.993222
>>992568
We have displays, Grug.
▶ No.993224>>993280
>>993098
reStructuredText fixes everything wrong with Markdown and looks even better.
>>993167
Vimscript is fine for what it was meant to be: a language to configure your text editor, there is nothing wrong with using it for that purpose. It ended up growing out of control though.
Neovim allows you to use any language for scripting the editor as long as there is an API client for it. If you want Scheme you can use Racket.
https://github.com/neovim/neovim/wiki/Related-projects#api-clients
There is also Common Lisp and Clojure if you like other Lisps.
▶ No.993226>>993227
>>993200
>why not compile editor plugins
Genius of our time. That MIT degree in scheme has served you well.
▶ No.993227>>993230
>>993226
why not? how many hours do you think that'd add onto a typical update to a plugin?
▶ No.993230>>993231
>>993227
The amount of hours required to recompile the editor.
▶ No.993231>>993246
>>993230
>what are shared objects
>what is dlopen
▶ No.993246>>993248
>>993231
>muh magic binary knows about future shared objects
lol
▶ No.993248>>993252
▶ No.993252>>993288
>>993248
/g/ tier. Next thing you'll be posting about HRT and anime.
▶ No.993280>>993353
>>993224
Restructured text is designed for writing python documentation and struggles outside that narrow domain.
▶ No.993288>>993291 >>993373 >>993455
>>993252
#define _GNU_SOURCE
#include <dlfcn.h>
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
#include <dirent.h>
#include <string.h>
#define MAX_PLUGINS 3
#define MENU \
"[0] Run plugins\n" \
"[1] Update plugins\n" \
"[2] Quit\n"
static void (*plugin[MAX_PLUGINS])(void);
static int plugins = 0;
void *open_here(char *filename, int flags) {
void *res;
char *path;
if (-1 == asprintf(&path, "./%s", filename)) {
perror("asprintf failed");
exit(1);
}
res = dlopen(path, flags);
free(path);
return res;
}
void update (void) {
DIR *dir;
struct dirent *file;
void *handle;
if (NULL == (dir = opendir("."))) {
perror("opendir failed");
exit(1);
}
errno = 0;
while (NULL != (file = readdir(dir))) {
if (NULL != (strstr(file->d_name, ".so"))) {
printf("Loading %s\n", file->d_name);
if (NULL == (handle = open_here(file->d_name, RTLD_LAZY))) {
fprintf(stderr, "dlopen failed with object %s: %s\n", file->d_name, dlerror());
exit(1);
}
if (NULL == (plugin[plugins++] = dlsym(handle, "plugin"))) {
fprintf(stderr, "dlsym(\"plugin\") failed with object %s: %s\n", file->d_name, dlerror());
exit(1);
}
}
}
if (errno) {
perror("readdir failed");
exit(1);
}
}
int main (void) {
char *line;
size_t len;
int i, n;
for (;;) {
printf("(Plugins loaded: %d)\n" MENU "\n: ", plugins);
if (-1 == getline(&line, &len, stdin)) break;
if (1 == sscanf(line, "%d", &n)) {
switch (n) {
case 0:
for (i=0; i < plugins; i++)
plugin[i]();
break;
case 1:
if (plugins == MAX_PLUGINS)
printf("You've had enough plugins, friendo.");
else update();
break;
case 2:
exit(0);
}
}
puts("");
}
return 0;
}
#include <stdio.h>
void plugin (void) {
printf("I'm a plugin wee.\n");
}
$ gcc -Wall -o brainlet brainlet.c -ldl
$ gcc -fpic -shared plugin.c -o plugin.so
▶ No.993291
▶ No.993353>>993386
>>993280
It can fill in any domain that Markdown can. reStructuredText is extensible, you could define new roles and directives for new domains, it's just that no one bothers to.
▶ No.993373>>993374
>>993288
>this many errors in such a small sourcefile
sasuga /tech/, c is truly the best language
▶ No.993374>>993455
>>993373
errors are error handling?
who cares, it's a thing that picks up plugins and runs them at runtime. It's easy and obviously done.
▶ No.993386
>>993353
The goal is to have the input be pretty; reST can feasibly handle any document, but it only remains pretty for python docs.
>you could define new roles and directives for new domains
Markdown is sufficiently popular that there are already extensions written for just about anything. If you started out thinking of doing a writing project, you don't want to get sidetracked into a programming one.
▶ No.993455>>993456
>>993288
oh yeah just like printf("Hello World!"); oh shit now I get it
>>993374
Totally obvious. Just like run_plugin() then it's a simple trivial thing to be like bam a plugin that does something or like bam a plugin I can run with a button press.
▶ No.993456>>993463
>>993455
we're reaching levels of brainlet that shouldn't even be possible
▶ No.993463>>993464
>>993456
int main(){printf("Hello World!");}
It's pretty easy and obvious. It's a thing that can run at runtimes. It can probaly print many things.
▶ No.993464>>993471
>>993463
Jesus Christ, is your point that the plugin isn't interesting enough? Give it some arguments and pass them. Maybe you should comment on whether shared objects vs. a scripting language will do for editor plugins
AFTER YOU LEARN THE FIRST FUCKING THING ABOUT PROGRAMMING
▶ No.993471
>>993464
I comment that yes chicky scheme is the best for editors but also for Dlls and such maybe.
int main(){
load_plugins('*.so');
run_pugin[i]();
}
void plugin(int a, int b){printf("Hello World this is plugin 2!");}
Yes yes I see now very easy to make plugins.
▶ No.993507>>994099
not enough macros, And i remember the auto indentation to be bad.
▶ No.993919>>994007 >>994099
>>991874
>look mom, no mouse!
>You just make things harder on yourself.
Lel, can't even macro the mouse in a generic, reusable way.
You can record keystrokes and generic text landmark motions, though.
▶ No.993968
>>991874
if you like the mouse so much why don't you throw away your keyboard and type using the virtual keyboard?
HMMMMMMMMMMMMMMMMM?
▶ No.994007
>>993919
>:set mouse=a
Checkmate guicucks.
▶ No.994040>>994044
I hate it because...I don't know. I don't really.
▶ No.994044
>>994040
Jesus would spit your opinion out.
▶ No.994063>>994085
Vim's learning curve is honestly the worst part for me. You need to spend weeks of using nothing but vim until you can get super comfortable with it.
▶ No.994085
>>994063
Are you saying to make it as usable as something else, or just in and of itself? If the latter, all you really need to know (for any text editor to be usable really) is how to search/replace, copy, paste, delete in mass, block comment/uncomment, and goto.
I.e. s & / with varying parameters for search & replace, yy or v+y for a copy, dd or v+d for a cut/delete, p for pastes, ctrl+v mode for block comment/uncommenting, and :num for goto. Not too much, but it takes at most 10 minutes to memorize the aforementioned.
▶ No.994099
>>993507
>>993919
set mouse=a
set tabstop=4
set shiftwidth=4
set smarttab
set expandtab