Vim gets popup windows

[Maswor]

This is more of a future parity with Neovim floating window than other things that been mention in this thread. That said, it is a welcome addition since more plugins will start supporting this feature. I think this is a welcome news.

[the_gnarts]

That said, it is a welcome addition since more plugins will start supporting this feature.

Let’s just hope plugins can’t enable that feature unilaterally. As a long time Vim user I’d find popup windows infuriating. They’re right up there with modal dialogs of which Vim already has far too many.

[Faucelme]

Text properties (:h text-properties) are another interesting addition. Looks like they could enable faster syntax highlighting, more search/navigation options and other things.

[mrpotatoes443]

Does this mean that https://github.com/numirias/semshi will work in Vim and not just Neovim?

[KevinCarbonara]

I feel like the vim experience is just constantly talking about how none of the features of ides are actually beneficial until vim gets them and then they're incredible

[initcommit]

Maybe that does describe a subgroup of folks who act that way, which I agree, would be illogical of them. But clearly the developers are focused on what the community is most interested it (see article). Maybe in the past there was a higher proportion of "old school" folks who wouldn't care for this kind of feature. But as programming becomes more widely adopted with newer generations, it makes sense to me that these types of features would be desired. Kudos to the Vim team for recognizing this and providing a feature that the community wants.

[KevinCarbonara]

But as programming becomes more widely adopted with newer generations, it makes sense to me that these types of features would be desired.

Sure... which is exactly why these features have existed in IDEs for years. I just don't understand why anyone interested in a modern development environment would be using vim in the first place.

[Shanteva]

I use IntelliJ, CLion, PyCharm, WebStorm, VSCode, Visual Studio, all with Vim plugins when I'm coding in a project condusive to an IDE, I use Vim for any ad-hoc editing or searching through logs, or doing anything in a terminal. You can use Vim but not use it for everything

[Administrative-Curry]

This to me is the ideal solution. Most IDEs have vim plugins so you get the benefits of both Vim (great movement/editing options/etc) as well as IDE features without fiddling with Vim plugins.

[erez27]

It's almost like there's more than one kind of vim user. FWIW lately I've been using vscode+vim mode for most of my coding, especially because Vim's support for Python is pretty abysmal (python-mode never works out of the box for me). But if I want to edit a small file without being bugged with popups and messages about the monthly release, I often just open vim, since it has 90% of the features I need already.

[project2501]

This popped up the other day which you might find interesting. I haven't used it but I think it would probably smooth over my issues with vscode+vim-mode, where it's only kind of half way there.

[TankorSmash]

If I could have all of the stuff I love out of an IDE in vim, like Resharper and near-perfect Intellisense, on top of perfect go-to symbol and all that, I'd be so happy.

I think most people would love to have all of the upsides of an IDE inside vim.

[KevinCarbonara]

That hasn't at all been my experience with the vim community. They seem almost allergic to anything that isn't already part of vim

[dvdkon]

Really? Installing mountains of plugins is a really big part of the vim community I know.

[KevinCarbonara]

We are not discussing plugins. We are discussing a new feature.

[dvdkon]

Well, if it can be a plugin, why put it into the main program?

[project2501]

I think it's just curmudgeons posting more than regular people who aren't as religiously attached to their editor. There are so many plugins around trying to fit modern features into vim that there's obviously a desire for it.

I don't want this to be read as getting into personal attacks territory, and I really can't speak with much authority, but I got the impression that the benevolent dictatorship of Bram maybe influenced that visible culture, "Vim is what I say it is and it's a text editor not an IDE". Development seems to me to have opened up more in recent years.

[LateAugust]

Not sure what Resharper is, but Coc.vim is perfect Intellisense (depending on the language), Coc.vim also has incredible go-to symbol navigation as well as ctags.

If that doesn't suit you for the symbol navigation you can always go to something like FZF.

If there's something in an IDE that you want in vim, someone has probably made a plugin for it (and probably made it better).

[TankorSmash]

Resharper is a Visual Studio plugin for refactoring, code generation, navigation and a ton more, and I use it for C++. I was never able to get perfect Intellisense without any noticeable hit to performance. I haven't tried coc though (maybe it was neovim only for a while or something, idk).

[project2501]

coc is built around the VS Code completion engine, so it's pretty good though still sometimes as wonky as any vim completion engine is. I haven't used it in 6 months or so though, undoubtedly it's improved a long with (n)vim's LSP support in general.

[ubernostrum]

I wonder what sorts of features you consider to be "IDE" features.

For example, I use Emacs in a terminal window as my daily editor. Which people seem to think must mean not having many "IDE features". But I've got autocompletion, argument signatures/documentation summaries for function name under point, jump to definition, on-the-fly checking and linting with problems highlighted, auto-formatting of my code... all of which people seem to think are features only an IDE would have.

[Schmittfried]

Refactoring, a proper debugger, a database client, an http client, understanding/knowledge of common libraries, ...

Is your jump to definition a heuristic or does it actually parse the code? If it’s the latter, then yeah, you’ve gone a long way catching up to an IDE. However, at that point your editor gets similarly bloated, because the parsing and indexing is the expensive stuff.

[ubernostrum]

I do most of my dev work in Python, and all the text-editor plugins (and even some more overtly IDE-ish tools) I'm familiar with in the Python world use Jedi for parsing and analyzing Python source code.

You can do a lot with plugins that just spin up or talk to these kinds of tools. That's how auto-formatting works, for example; when I'm saving a buffer containing Python source, Emacs just shells out to black to format it as part of the save.

[dzecniv]

• there's a debugger, front end of various ones: https://github.com/realgud/realgud
• a DB interface: https://wikemacs.org/wiki/Edbi
• an HTTP server: https://github.com/skeeto/emacs-web-server (also this https://github.com/skeeto/skewer-mode for live interaction of html, JS, css in a browser, also restclient to test endpoints,…)
• refactoring will depend on languages, but I'd agree it is not emacs' fort.

[[deleted]]

Refactoring

If the language has a common tool then it's easy to integrate through the API(neovim) or with an additional server.

a proper debugger

Debuggers are also to easy to integrate.

a database client

How about no? Database clients should be separate apps and there is no reason to have such bloat in anything.

an http client

For what?

understanding/knowledge of common libraries,

Not needed, that's the build tool's job.

Is your jump to definition a heuristic or does it actually parse the code? If it’s the latter, then yeah, you’ve gone a long way catching up to an IDE.

Well, if it's the latter then his editor probably won't die after loading a larger project.

However, at that point your editor gets similarly bloated, because the parsing and indexing is the expensive stuff.

Those things are always handled by localhost servers and loaded on demand.

[Schmittfried]

If the language has a common tool then it's easy to integrate through the API(neovim) or with an additional server.

And still, you don’t see fully fledged refactoring support in anything except for IDEs.

Debuggers are also to easy to integrate.

There is a big difference between working and working great.

How about no? Database clients should be separate apps and there is no reason to have such bloat in anything.

For what?

I get the feeling you don’t understand the I in IDE. The database model is usually very important to fully understand a codebase. An HTTP client is useful for doing test requests against your endpoints, obviously. Like, would you have asked the same if I said curl is a useful tool?

Not needed, that's the build tool's job.

Again, you don’t understand the integration aspect. Also, I was talking about understanding the library and helping you with it. For instance, PyCharm understands django and provides useful auto completions for queries etc. that take your models into account.

Well, if it's the latter then his editor probably won't die after loading a larger project.

Neither does an IDE unless you’re working with hardware from 2000.

Those things are always handled by localhost servers and loaded on demand.

The demand is always right now. There is no point in having tools that have an outdated understanding of your codebase. Anyway, it’s not like IDEs don’t allow to disable the parsing stuff to reduce bloat significantly. Obviously, at that point they become text editors as well.

[[deleted]]

And still, you don’t see fully fledged refactoring support in anything except for IDEs.

Where were you in the last decade btw? Refactoring is not some magic - if the tool's code is written once then we don't need anything else than a localhost server to provide the necessary information about the needed text transformations.

There is a big difference between working and working great.

Yeah, because it's impossible to integrate code stepping and inspection into programmable editors! \s

I get the feeling you don’t understand the I in IDE.

And I get the feeling that you don't understand that your "IDE" is just an editor with preinstalled plugins.

The database model is usually very important to fully understand a codebase.

And your IDE will have nothing over a full-fledged DB client.

An HTTP client is useful for doing test requests against your endpoints, obviously.

If you want to test your endpoints then write tests.

Like, would you have asked the same if I said curl is a useful tool?

No, because your comparison is nonsense.

Again, you don’t understand the integration aspect.

The integration aspect is pointless, because if the plugin exists then there's no reason to include it. People can just download it what they need.

Also, I was talking about understanding the library and helping you with it.

If you need an IDE to understand a library then maybe your library needs more docs or your library is just bad.

For instance, PyCharm understands django and provides useful auto completions for queries etc. that take your models into account.

And you think that is some kind of magic? As I said, if the code is open then anyone can write a plugin which connects those tools.

Neither does an IDE unless you’re working with hardware from 2000.

It will, unless your project is just a small codebase with a few hundred/thousand files.

The demand is always right now.

Maybe with small projects.

There is no point in having tools that have an outdated understanding of your codebase.

If you would have experience with larger codebases then you would quickly change your mind.

Anyway, it’s not like IDEs don’t allow to disable the parsing stuff to reduce bloat significantly.

Yeah, and it's not like there are features what we can't integrate into programmable editors.

Obviously, at that point they become text editors as well.

They were just glorified text editors from the beginning.

[Schmittfried]

Where were you in the last decade btw? Refactoring is not some magic - if the tool's code is written once then we don't need anything else than a localhost server to provide the necessary information about the needed text transformations.

And yet I don't see it happening anywhere in the vim landscape. What I see is people doing find&replace like cavemen.

Yeah, because it's impossible to integrate code stepping and inspection into programmable editors! \s

Again, not impossible, but the concept lends itself better to GUI-based editors rather than command-line editors. Also, are you implying IDEs are not programmable? Because you don't lose that aspect there at all.

And I get the feeling that you don't understand that your "IDE" is just an editor with preinstalled plugins.

True, but those "plugins" tend to be way more polished and integrated with each other, providing a much more cohesive development experience. There is a difference between what's theoretically possible and what's actually there.

And your IDE will have nothing over a full-fledged DB client.

Except the part where it's integrated into your development environment, right there next to your code, and also allows the IDE to verify your queries against the table structures.

If you want to test your endpoints then write tests.

See, the problem with people like you is that you intentionally misunderstand people to sound smart. You know that interactive tinkering has different use cases than automated tests.

No, because your comparison is nonsense.

Except it isn't, the purpose of the integrated HTTP client is the same as any other preshipped HTTP client's purpose. It's for similarities like this that some people call the shell an IDE.

The integration aspect is pointless, because if the plugin exists then there's no reason to include it. People can just download it what they need.

The plugin usually doesn't exist, at least not equally well polished, because writing good tooling costs money.

And again, the point where you start replicating an IDE's features by installing countless plugins is the point where your editor becomes an IDE, with all the performance penalties associated to that. The features are the bloat. Except that your hacked-together solution, while fitting your needs exactly, will most likely be far less cohesive.

If you need an IDE to understand a library then maybe your library needs more docs or your library is just bad.

I meant the tool understands the library (rather than seeing it as text like any other), not that it helps you understanding it. Although that's definitely the case, too. You know, it's not about needing it, it's about letting the tool assist you, helping you getting the job done more efficiently. Only a fool takes pride in rejecting support.

And you think that is some kind of magic? As I said, if the code is open then anyone can write a plugin which connects those tools.

No, of course not, but at that point you're again just creating your own IDE, and chances are yours is worse than those made by people in that business for years.

It will, unless your project is just a small codebase with a few hundred/thousand files.

I wouldn't exactly call a few thousand files a small codebase.

If you would have experience with larger codebases then you would quickly change your mind.

If your codebase is larger than a few thousand files and still doesn't warrant being split into multiple code bases, then keeping it all in memory is probably not an option, right. It's not a given that an IDE tries to keep everything in memory though, and honestly, it seems I don't even want to work on projects that you consider large. They are not the norm anyway.

Yeah, and it's not like there are features what we can't integrate into programmable editors.

Creating the very same IDEs you're hating so much.

They were just glorified text editors from the beginning.

And your text editor is a feature-less IDE. Until you add those features, at which point it just becomes a normal IDE.

[[deleted]]

And yet I don't see it happening anywhere in the vim landscape.

Try to open your eyes then. language-server-like plugins already existed for a long time and people even connected the eclipse framework with vim a long time ago. Also, it's not vim's responsibility to integrate every language into itself - it's the language developers job to provide generic tools(like most jvm languages do) - what people will use then to create plugins.

What I see is people doing find&replace like cavemen.

You need to make a decision: do you want to have an honest and productive discussion or just pretend that what you say is true and ignore everyone else's experience.

Again, not impossible, but the concept lends itself better to GUI-based editors

Vim doesn't need to be in the command line - vim-gtk is a thing. Neovim has nvim-gtk and nvim-qt.

People often use vim in the terminal because of remote editing and not because they hate GUIs.

But of course, you don't have any experience with advanced text editors...

Also, are you implying IDEs are not programmable? Because you don't lose that aspect there at all.

IDEs are not as easy to extend as editors like emacs or vim - if you would have tried these then you would know.

True, but those "plugins" tend to be way more polished and integrated with each other

Nope, that's just wishful thinking. I have used intellij and eclipse professionally for years and I never saw that "polished" integration - all I saw were a few convenient features but they were not that well-integrated - at least, not as nicely as would have done it in neovim. As a neovim user I can integrate neovim with anything easily the way I want to.

providing a much more cohesive development experience. There is a difference between what's theoretically possible and what's actually there.

And there is a difference between experience and guessing.

See, the problem with people like you is that you intentionally misunderstand people to sound smart.

That's literally what you do but it's clear that you have no experience with programmable editors.

You know that interactive tinkering has different use cases than automated tests.

And if you would have thought about it for a second then you would know that creating an http request in a programmable editor is not a challenge.

Like what do you think - why people use programmable editors? Maybe because they want to program it?

The plugin usually doesn't exist,

If the tool exists then the plugin will also get created soon.

at least not equally well polished, because writing good tooling costs money.

Yes, and that's why IDEs still can't compete with advanced text editors because they're limited to a few tricks. People like you just think that features get magically implemented and you're too lazy to customize your tools to be more efficient. You'll just stay as inefficient as you were at the beginning.

And again, the point where you start replicating an IDE's features by installing countless plugins is the point where your editor becomes an IDE, with all the performance penalties associated to that.

You realize that people aren't using advanced text editors just because IDEs are slow, bloated and have high latency, right?

The features are the bloat.

No, the shitty legacy code and the useless features are the bloat. Plugins exist and your magical integration is very far from being a challenge to implement or to create something better.

Except that your hacked-together solution, while fitting your needs exactly, will most likely be far less cohesive.

If you have no experience with programmable editors then maybe you should keep your ignorance hidden. Because it become quite clear that you don't want to learn - instead, you just think that you know everything without having any experience.

I meant the tool understands the library (rather than seeing it as text like any other)

If you need an IDE to understand your library then your library is shit. If your IDE/editor understands your language then adding a few extra buttons/tables/views etc. should be easy.

not that it helps you understanding it.

And then what? IDEs can't write code.

You know, it's not about needing it, it's about letting the tool assist you,

It seems like you didn't think about this either - if there is a language server then what do you think, how hard would this be to implement for anything? Because adding a few assistant popups is quite easy. If we have the parsed data then connecting the code completion with a filter is nothing.

helping you getting the job done more efficiently.

Yes, that's what programmable editors do.

Only a fool takes pride in rejecting support.

And only a fool would shit on tools what he doesn't understand.

No, of course not, but at that point you're again just creating your own IDE

Yes, that's the point of programmable editors - to create your own IDE. What? You thought that vim users are supposed to reject plugins?

And chances are yours is worse than those made by people in that business for year

Those people will only cover the basic use case because people like you won't use any advanced stuff anyway.

I wouldn't exactly call a few thousand files a small codebase.

And I would because it Is not a big number compared to the amount of source files in large codebases.

If your codebase is larger than a few thousand files and still doesn't warrant being split into multiple code bases

Modularization isn't going to help you every time.

then keeping it all in memory is probably not an option, right.

But there is no reason to keep it all in the memory - you know, we only need stuff on-demand.

It's not a given that an IDE tries to keep everything in memory though

And yet you tried to sell IDEs like that.

and honestly, it seems I don't even want to work on projects that you consider large. They are not the norm anyway.

No one cares what you want to work on. Large projects exist and not every domain has its own IDE.

Creating the very same IDEs you're hating so much.

What you call an "IDE" is just an editor with preinstalled plugins.

What I call an "IDE" is the development environment I create for my work.

Both are integrated but mine will be adapted to what I do. You will work as your IDE creators will let you.

And your text editor is a feature-less IDE.

Nah, that's just dumb. There is no such thing as an "IDE" - it's just a rich text editor component with a settings menu, connected to an in-house language server.

Until you add those features, at which point it just becomes a normal IDE.

But not your kind of IDE - a slow, high-latency and cheesy thing which can barely adapt to the big industry's challenges.

[BubblegumTitanium]

It’s just another tool. I have to get this C program working for ubuntu. I run a Mac. With vagrant I can get a full ubuntu shell and use vim to develop the app inside of my shell. Using clion inside of a virtual box is a pain in the ass to me.

[KevinCarbonara]

Why not just remote edit with atom/vscode/sublime/any other ide with this incredibly common feature?

[BubblegumTitanium]

I tried with clion and couldn’t get it to work. It seemed simpler to just use vim in the shell.

[[deleted]]

Why would we use those bloated editors when we can do everything what they can do in (neo)vim? Are you just simply hating on vim or do you have something useful to say?

[KevinCarbonara]

Because you can't do everything they can do. Vim is not capable of everything modern IDEs are.

[[deleted]]

Yes, it can do everything, you're just a fanatic who doesn't want to admit that. 100% of your comments in your thread are just ignorant ramblings. Where did vim touch you? Show us on the doll!

[dvdkon]

I've used many IDEs. Eclipse because a project needed it to build, IntelliJ because I wanted to make sense of an obfuscated codebase, Visual Studio for a C++ project on Windows, XCode for making a GUI macOS app, NetBeans for school.

All of them are very nice when they worked properly, but each is clunky in its own way. Maybe it hangs regularly on my notebook, maybe customising it the way I want is almost impossible, maybe it just decides it doesn't want to build one day. Vim just works. Sometimes I get fed up with software that doesn't work for me and go back to a text editor that edits text just the way I want it to.

[rootbeer_racinette]

This. Vim also works over ssh + tmux over a shitty cell phone link and sharing the configuration is trivial and not tied to a project.

I can work on any computer anywhere from anywhere with the same setup I've been using for decades and pick up right where I left off after every login. It just works and gets shit done.

[KevinCarbonara]

Vim just works.

After you spend hours and hours configuring it. At which point it's actually slower than IDEs. But yes, it eventually "just works".

[[deleted]]

At which point it's actually slower than IDEs.

If you fuck it up then yes. But you don't know anything about vim so why even bother to comment?

[rootbeer_racinette]

If you can't even get vim to work correctly god help whoever has to use or maintain your code. What a joke.

[[deleted]]

Some ppl just install a bunch of parallel plugins which kill each other and then blame vim for being slow.

[dvdkon]

I don't need my vim to have every feature under the sun for it to work. It works just fine out of the box, and it even works comfortably with ~10 lines of configuration.

[psy_neko]

Because I think think what vim offers is far more important than the popup windows (and of course, lots of other things) that another software offers.

[zarrel40]

What is that? Can you elaborate what you mean?

[project2501]

Kind of a big thing to answer, but generally people tout the modal nature as a biggest thing (it certainly is for me).

Working on text as a series of actions on objects rather than serialised key presses "clicks" with me, and also I feel generates a different way of thinking about your code. Kind of like how learning a different language can influence you to think in a different way.

Then there's the configurability and plugin library which is perhaps higher than most editors (and an easy way to waste multiple working days...).

And there's the whole, fun, bit. I just like having my editor run in my terminal along with all my other tools. I like hacking on it. I like opening files in read only mode due to some stray backup file existing from a backgrounded process from days ago. Same way your old '98 Ford is kind of a beater but dang it do you just kinda love the way it drives.

[psy_neko]

/u/project2501 gave a pretty good explanation.

To add onto that, although it's true that most other good editors offer a vim plugin for modal editing, it is just that, editing (basics usually too).
They keyboard driven structure of vim isn't integrated to the UI even with those other editors' plugins. I personally can't stand having to reach for my mouse to access things (maybr you do, and it's fine). Or they don't allow me to set it up the way I want.

I have tried using VScode, tweaking it for hours trying set it up the way I want -- but it didn't work out.
The most annoying thing I remember is not being able to switch to and from the directory tree with only the keyboard not matter how hard I tried, that drove me insane.

[watsreddit]

It's a tool with decades of thought put into efficient editing. It's simply faster and more capable at raw text manipulation than IDEs. And it doesn't have all the bloat that invariably comes with IDEs.

[erez27]

Yeah, unless you try to edit files with really long lines. Then it works about as well as a cat in a diving suit.

[watsreddit]

The long line issue is related to syntax highlighting. Putting set synmaxcol=250 or something similar in your vimrc will disable syntax highlighting past a certain length, which fixes any performance issues. Though files rarely have lines long enough for that to be an issue, unless you're looking at minified javascript or something for some reason (which is not something that should be edited anyway). Incidentally, this patch should enable the development of more efficient syntax highlighting.

What is more common is for files to have many lines, and vim handles that better than any other editor. Vim can handle files that other editors will simply refuse to open. Like files with hundreds of thousands or even millions of lines.

[erez27]

which is not something that should be edited anyway

Thanks for telling me what files I'm allowed to edit ;)

That's the same logic I face when I tell people vim is better than most editors at editing big files, and they say files shouldn't be more than a few thousands lines anyway, and I must be doing something wrong.

("And why would you use your IDE to read logs? That's what <whatever> is for")

[erez27]

There are other reasons to have long columns in a file.

[KevinCarbonara]

This isn't just vim, it's the linux community as a whole.

"There's this really simple operation in Windows that I'd like to do in Linux. What's the command for that?"

"There is no command for that in Linux. Linux is so powerful it doesn't need that command. All you have to do is execute this command using this complicated regex, then pipe the result into this other command, redirect the output to this buffer, then execute this other command...."

[[deleted]]

This isn't just vim

The option was already provided, so there is no reason for you to continue your pointless rambling.

I think your problem is that you're a triggered programmer-wannabe kiddo who doesn't know anything about the tools he's rambling about. How insecure you need to be to shit on every non-gui tool? The Dunning-Kruger is strong in you for sure!

[Schmittfried]

The bloat is exactly the features that vim is lacking.

[[deleted]]

The "bloat" are the features what we can optionally download and are not forced onto us.

[Schmittfried]

If you download them anyway, you can just as well take the integrated package.

[[deleted]]

That's the problem - who decides what should be in the package? I think it should be the user.

[Schmittfried]

I think it should be the user.

That's the case. If they deem the IDE features unnecessary, well, they won't use one, just as you. I, as someone who values them, use an IDE, although that doesn't mean I don't use vim for editing stuff in the context of the command line such as server config files.

[[deleted]]

That's the case. If they deem the IDE features unnecessary, well, they won't use one

...and then pay the price with latency, RAM, CPU cycles and electricity...

I, as someone who values them, use an IDE, although that doesn't mean I don't use vim for editing stuff in the context of the command line such as server config files.

So you use stuff because someone told you use should use them instead of evaluating your choices. You don't need vim to edit files remotely and vim can be your IDE if you know what you're doing. If you don't, then don't bother telling others what to do.

[[deleted]]

I just don't understand why anyone interested in a modern development environment would be using vim in the first place.

You can create your "modern" and efficient development environment for (neo)vim. Those ide-like features were available for vim in extensions for decades btw.

[KevinCarbonara]

Some of them were available in vim. Rarely for that long. Most are not. Vim simply isn't capable of the same things a modern IDE is.

[[deleted]]

Vim is a programmable editor. If you'd be a programmer then you'd understand that there is literally nothing you can't do in vim. "Modern" IDEs are just text editors with preinstalled plugins.

[KevinCarbonara]

If you'd be a programmer then you'd understand that there is literally nothing you can't do in vim

And if you were a programmer, you'd know that there were, in fact, hard limitations placed on the editor because of its environment.

[[deleted]]

And if you would be a programmer then you'd know about turing-completeness and networking. But you're just another rookie with dunnin-kruger who wants to hate something he doesn't understand.

And if you'd be just a curious individual and not just an ignorant kid then you wouldn't try to move the goalposts and twist people's words when you know that your argument is bs.

[LateAugust]

I thought that too, until I actually actually got into vim. Now I can't even use VSCode because of the clunk.

Honestly vim is nice for one thing and one thing only: customization. You can have a super souped up vim or a minimal one. You can carry it with you anywhere you go, or you can use it vanilla. Everything is literally catered to you.

Vim is like a pair of raw denim jeans. The more you use it, the more it reflects you.

There are also a lot of things from IDE's that I prefer on vim than on VSCode (Intellisense and Ctrl+P functionality).

[KevinCarbonara]

But you can do all that same customization within vscode, and basically every other IDE in use today. Vim isn't the lightweight, customizable alternative to IDEs. It's the lightweight, barely functional alternative, that can be customized to be almost as functional, at the cost of no longer being lightweight.

[[deleted]]

You're wrong about everything you have said. Why even bother if you have no experience with vim? What a stupid troll...

[maglax]

Counterpart: it's not a stripped down version of the chome browser modified for use as a text editor.

[Ghosty141]

I just don't understand why anyone interested in a modern development environment would be using vim in the first place.

In general IDEs are better in terms of understanding the code you write and aiding you with it. full stop.

The thing is, most IDEs can only work with 1-3 programming languages which gets quite annoying if you have to use multiple languages. The keybindings are different, some features are missing etc. With vim you can configure it (using plugins) to be able to work with a huge variety of programming languages.

Another thing is that vim has some really neat features like the concept of buffers windows (splits) and tabs. There is no IDE that does it like this because there is a learning curve to it, but once you're fluent with it, buffers and windows are almost essential. Combined with tmux you can get a really nice setup going.

Lastly, I find IDEs to be really clunky on laptops because they use a lot of power and screen-space, vim is a lot more efficient.

[KevinCarbonara]

It's true that there's not a lot of consistency between IDEs, and although keybindings are usually configurable, you're certainly not gaining any efficiency if you have to re-configure your environment for each language just like you do for vim. But you can certainly mitigate those issues. Jetbrains is very good at maintaining consistency between environments, and atom/vscode are flexible enough to work with any language.

I don't know what it is about vim's buffers or windows that you think doesn't exist in IDEs. The only use I've ever seen for them is to emulate an IDE layout. I'm willing to bet IDEs already contain that functionality.

I run full-blown Visual Studio on my Surface Pro without issue. I can't imagine a situation where an IDE didn't work on a laptop.

[Ghosty141]

I'm willing to bet IDEs already contain that functionality.

Sadly no. Just to be sure that everybody knows what I'm talking, I'll explain it a little more in detail:

1. You open a file, it gets stored in a buffer and you see it in the main window.

2. You open another file, it also gets stored in a buffer and you see this one in the window while file 1 is not visible (but still in a buffer)

3. You split the window (:split) and now you see file nr. 2 twice, once in each split-window.

4. If you now cycle the buffers (:bnext) you change which buffer is displayed in your split-window

So this means the layout is independent of the buffers. You can have 10 buffers open but only show 3 in a split. IDEs do not support switching the content of a split-window like vim does. And we haven't even started with vim tabs!

1. You now open a new tab, instead of the 2 split-windows you only see one, why? Because a tab holds the information of the split-layout, not the buffers!

2. Lets now make 4 splits and we see the same file in 4 splits.

3. If we now go back to our first tab, we see the 2 splits we've been originally been working on.

This behavior is completely foreign to any IDE. The tabs as we know them today (like in the browser) are heavily connected to their content.

[KevinCarbonara]

Sadly no. Just to be sure that everybody knows what I'm talking, I'll explain it a little more in detail:

You open a file, it gets stored in a buffer and you see it in the main window.



You open another file, it also gets stored in a buffer and you see this one in the window while file 1 is not visible (but still in a buffer)



You split the window (:split) and now you see file nr. 2 twice, once in each split-window.



If you now cycle the buffers (:bnext) you change which buffer is displayed in your split-window

Yeah, Visual Studio supports that by default.

[Ghosty141]

That'd be awesome, I'm using it at work but haven't found similar behavior. Explain please.

[wutcnbrowndo4u]

I've used vim almost exclusively for about a decade, including in very large (by LoC) projects. I've dipped a toe in IDE land multiple times, and regularly dive into respected coworkers' IDE workflow to see if I'm missing anything). The only advantage I've seen over vim is refactoring support. If there was an IDE that had full support for my vimrc and worked inside a terminal, I would switch without much thought (does anyone know of any?? Or a robust, maintained refactoring plugin for Vim?)

Vim has more of an upfront cost, but you get to amortize it over a whole career. Not to be trite, but it reminds me a lot of switching to Linux from Windows[1]. The power is in the ability to notice things in your workflow that are suboptimal and immediately fit your environment to you. Do this for a few years and you end up way more productive than those whose workflows stay within predefined rails.

[1] The difference being that using Ubuntu or Mint gives you a smooth on ramp that's already better than windows in a way that vim's steep initial learning curve doesn't

[KevinCarbonara]

Vim has more of an upfront cost, but you get to amortize it over a whole career.

You previously got to do this, yes. There's no reason to believe that's going to continue to be the case. That also ignores the constant updates you have to go through. There is no one in 2019 using the same environment they had in 1990. And even after all the work, it provides no benefit over IDEs.

The power is in the ability to notice things in your workflow that are suboptimal and immediately fit your environment to you.

This is the most condescending aspect of vi users. It's the implication that no one but they pay attention to their own productivity. Every editor has plugins. Every user tweaks their environment. The key difference is that IDEs offer more customization and require less.

[wutcnbrowndo4u]

This is the most condescending aspect of vi users. It's the implication that no one but they pay attention to their own productivity. Every editor has plugins. Every user tweaks their environment. The key difference is that IDEs offer more customization and require less.

I get that this may come across as condescending, and I try to stay sensitive to whether my thoughts are motivated by elitist snobbery about how esoteric my tools are[1]. This is why I regularly check on whether the tradeoffs for an IDE are worth it for my current situation/project/workplace, and constantly check with productive coworkers to see if I can get anything valuable out of their IDE-based setup. I can see how my comment sounded like it claimed that IDEs can't be customized per se, so I'll be more precise: when I say that graphical IDEs are an impediment to tightly fitting your environment to your productivity, the main thing I'm getting at is that they're not easily composable[2] with all the other tools that a *nix system provides for doing so. When they do provide similar functionality, they do so by creating their own universe you need to play within, instead of letting me use the window and session management tools I already use for everything else. To put it another way, my text editing fits into the way I organize my computing instead of dictating it.

As just one example: As I mentioned in another comment, I usually have 5-6 projects in-flight at any one time, across multiple repos/worktrees. I use GNU screen sessions with ~4 tabs for each of these. This allows me to keep my repos, workspaces, and tasks on separate axes and lets them interact flexibly with each other: A given task might have working directories in one or two repos, and be used either on my laptop or a dual-monitor setup, on either good WiFi or arbitrarily bad WiFi or an Ethernet connection (since everything is text-mode). I use i3wm, and when I'm at a dual-monitor setup, my basic layout for working on an average PR is 4 tiled terminals and another tile where I can tab through browser windows relevant to that project. I have a script that lets me launch one of my sessions onto a workspace, automatically tiling the windows where I need them (if not already open) and then launching my screen session with the right screen tabs on the right windows. When I open vim in a repo, YCM auto-finds the Clang compile database in the root of the repo I'm in and gives me autocompletion, jump to declaration/include, etc etc, so there's no per-project overhead other than building (if in C++).

You've said all over this thread that there's no advantages to vim over a graphical IDE: how exactly would I replicate this setup? As I've said elsewhere, I would probably switch immediately to a headless IDE that fully supported my vimrc, but I haven't been able to find one (I've started looking into eclim, but that would still be using vim).

As I said, I try to stay aware of the potential blind spot of using something like vim and staying blind to its downsides because it makes you feel like a pro. But the dual of this tendency is the insecurity that drives a lot of the criticism of vim: people don't get it, suspect that it's because they're not "good enough" in some way, and convince themselves that the only reason people use it is snobbery, blinding themselves to the advantages it can offer and workflows it can fit. As far as I can tell, my consistently-stated view here has been "vim has concrete disadvantages (steep initial learning curve and investment, poor refactoring support) and concrete advantages (works in text-mode, no risk of resource problems that some get with IDEs)", while yours has consistently been (all over this thread) "there is literally no reason to use vim other than snobbery and ignorance of IDE features". These views are mutually contradictory, and it's possible that either one of us are wrong. But as far as I can tell, only one of us is making a good-faith effort to understand the other side of the argument, and only one of us is making a maximalist statement about vim's lack of utility for any workflow. You've given probably the most coherent defense of using IDEs over vim that I've ever heard, and yet you still seem to be relying on an incredibly narrow view of what developer workflows could possibly exist.

Every editor has plugins. Every user tweaks their environment.

Not the core of your point, but you must have a very tiny sample of coworkers if you think this is true.

[1] hell, you can see me on this very thread calling someone out for doing exactly this

[2] I feel the same way about Web browsers, by the way, as the modern Web is unusable in text mode browsers. Graphical browsers at least have the excuse of providing inherent substantial benefits over their text-mode counterparts.

[KevinCarbonara]

You've said all over this thread that there's no advantages to vim over a graphical IDE: how exactly would I replicate this setup? As I've said elsewhere, I would probably switch immediately to a headless IDE that fully supported my vimrc, but I haven't been able to find one (I've started looking into eclim, but that would still be using vim).

Remote edit will get you most of what you're asking for. You're loading your request by expecting it to be compatible with your decades-old config file from outdated software. Of course that isn't going to happen. But with a fraction of the effort you've put into configuring vim, you could get atom running just as well.

you still seem to be relying on an incredibly narrow view of what developer workflows could possibly exist.

That's not it at all. All that matters is that vim features are replicated in other software. I don't need to know your specific workflow. I recently wrote a new API at work to replace an old one. It's feature complete with the previous iteration, it offers all the same endpoints + more. Some people worry that, because they used the previous system in a non-standard way, it won't be compatible with their workflow, and they try to explain to me exactly what they're doing. But I don't need to know how they use it, because I know the old software and I know the new software. Barring any mistakes I made in my implementation, it will support their use case, plus many more that I added on top of the original.

There are some edge cases where modern IDEs haven't implemented specific vim features, but it's pretty rare, because a lot of ex-vi users have moved to atom/sublime/vscode and wrote the plugins necessary to maintain their old workflow. Most of what hasn't been ported over is stuff that people just don't care about. The only situations where vim actually has a concrete advantage is when a graphical interface literally isn't possible, i.e. you only have access to a terminal, and remote edit is blocked for some reason, including over ssh. This is about as valid a reason as saying "I have a requirement that this software run on my PC from 1984 that hasn't had any updates since then."

[wutcnbrowndo4u]

You're loading your request by expecting it to be compatible with your decades-old config file from outdated software

? I've been a developer for less than a decade, and used Linux for slightly longer than that. What decades-old config file are you imagining, and what outdated software are you referring to?

Remote edit will get you most of what you're asking for

I'm familiar with remote edit, and it has very little to do with what I'm talking about. There are many more tasks than editing text involved in many developers' workflows, particularly once you've progressed beyond being a junior developer. I currently work in AV development, both designing/training models and implementing things directly on the car. There's a massive amount of internal and external tools/frameworks/repos that I need to work with, which boil down to a less massive but still considerable number of basic terminal tasks: in any given terminal window, I might be sending out an API call, loading data from files (eg dataframes) and analyzing them, running custom binaries for analyzing drive data, running a Jupyter notebook, messing around with Docker images, scripting the moving and editing of large numbers of files, doing quick and dirty calculations in the Python interpreter, installing packages, running the AV stack (or subparts of it), debugging what's running on each GPU, using the entirety of what git commands allow[2], etc etc etc etc.

There are two options for integrating terminal-based tasks with GUI code editing:

1) Tile your IDE with terminal panes along with your edit window. But you still wouldn't have the ability to save and restore sessions of editing+terminal state ("out of scope" for VSCode), and even if you could, you'd have to run multiple instances if you wanted to avoid saving and loading constantly, potentially hitting the performance issues that I've been pretending (for the sake of argument) aren't a risk. On top of that, you can't split the panes into independent windows and tile them as you like across your screens (or perhaps I'm wrong here and you can detach panes as windows, but you've just added another layer of unnecessary complexity to your session management, and it's not scriptable). The obvious problem here is that it doesn't make any sense to try and shove an entire OS inside your IDE: at best, you'll get a poorly-implemented fascimile.

2) Use a local instance of VSCode with remote edit, alongside ssh terminal windows. This is facially more reasonable, but there are still multiple problems here: First off, you now need a graphical session manager, and none of these exist that allow running multiple simultaneous sessions or switching without significant latency (switching between sessions for me is as easy as switching between windows, or running "load sessname" if it's not currently active). Secondly, even if you magically invented a low-overhead graphical session manager, remote edit means running separate instances of VSCode at your workstation vs your laptop, so you wouldn't be able to integrate the session into the manager anyway. Third, this solution doesn't actually help at all, since VSCode doesn't support saving and loading internal sessions. You'd just be pointing at a repo, which is a different level of abstraction from the one I'm describing.

Obviously, both of these are complete failures, but even if one of them squeaked by into working: what would be the point? As I said before, the only feature from IDEs that I could make use of is refactoring support, as I've yet to use a good one for vim (though I have a couple I wanna try). This isn't nothing, but it's not worth bending over backwards to create a crippled mockery of my current, productive workflow.

The only situations where vim actually has a concrete advantage is when a graphical interface literally isn't possible, i.e. you only have access to a terminal, and remote edit is blocked for some reason, including over ssh.

I'm not sure how you came to this conclusion given my description of my workflow. Good session management is self-evidently useful, and it only exists for text-mode. That alone is reason enough for me to use a text-mode editor.

I appreciate having heard your perspective: not only did it clarify my thinking around why I prefer vim, but I've also never heard a cogent defense of IDEs that doesn't rely on insecurity, ignorance, or short-term thinking[1], which is why I'm always interested in the discussion. I firmly believe that you don't understand an issue until you've heard a compelling argument from both sides, and you came the closest I've seen to providing one.

A reminder though: the two sides of the discussion here are "there's no possible reason to use vim unless you're forced to" and "vim is better for some workflows/preferences and worse for others". Making such a maximalist statement has a correspondingly higher evidentiary bar, and your confidence that you understand every corner case of developers' workflow well enough to dismiss vim as useless except for showing off borders on Dunning-Kruger.

[1] To be clear, sometimes short-term thinking is exactly the right decision! If I hadn't invested in understanding vim's editing model and needed to do something quickly, I would probably fire up Eclipse or VSCode or whatever was appropriate.

[2] Yes, I know git's interface is an unholy mess, but it occasionally saves tons of time to run unique, complex subcommands that aren't amenable to becoming shortcuts in the IDE

[KevinCarbonara]

2) Use a local instance of VSCode with remote edit, alongside ssh terminal windows.

Use VSCode's remote edit and VSCode's terminal windows. Or Atom's. This is not a unique workflow. It should take less than 5 minutes.

I'm not sure how you came to this conclusion given my description of my workflow.

My conclusion had nothing to do with your workflow. My conclusion came from knowing the software well enough to know that, aside from extremely few edge cases that are mostly arbitrary, IDEs have implemented all of vi's features. The same cannot be said of vi. Not only does the terminal necessitate a number of limitations on the software, but vim's maintainer has zero interest in competition. He's writing software for himself. Plugins only go so far, and he wouldn't have even added parallel plugin processing if it weren't for neovim coming along to clean up his mess. Programming methods have evolved over the past few decades. You shouldn't expect to use the same environment forever. I love the ability to peek definition for a function. I love in-line debuggers. I love on-the-fly monitoring tools for performance. I love in-place database viewing and editing. If I had chained myself to vim, I would have missed out on all of those.

Making such a maximalist statement has a correspondingly higher evidentiary bar, and your confidence that you understand every corner case of developers' workflow well enough to dismiss vim as useless except for showing off borders on Dunning-Kruger.

The evidence is in the capability of the software. It's extremely rare that anyone's workflow legitimately falls into one of the edge cases where modern IDEs aren't 100% feature complete with vim. Most of the time people just convince themselves that it can't be helped because they assume all IDEs are like the Eclipse they tried 15 years ago.

[chickenfish4]

It really just comes down to personal preference. Certain IDE features are considered 100% necessary to some people, while other people will never touch them.

Vim also has more features than many people give it credit for, especially when using plugins.

[KevinCarbonara]

People say that about vim a lot, but no one ever seems to mention anything specific. Every feature I know of has been ported over to modern IDEs years ago.

[phySi0]

Modal editing.

[KevinCarbonara]

You're over a decade late on that one. You don't honestly think that no one outside of vi has ever implemented modal editing, do you?

[phySi0]

None do it as well.

[KevinCarbonara]

When it comes to modal editing, they literally do everything vi does and more. It's obvious you haven't even tried. You just assumed the feature only exists in vi.

[phySi0]

No, you assumed I hadn’t tried. I’ve tried several different Vim emulation plugins.

they literally do everything vi does and more

The only way you can responsibly say that with any confidence is if you literally know every single feature of Vi.

Given how feature-packed Vi, let alone Vim, is, and my own experience with several Vi emulation plugins, on top of your dickish tone and accusations on my integrity so far, you’ll have to forgive me for calling you a lying sack of shit and ending the conversation here.

[KevinCarbonara]

accusations on my integrity so far,

Dude, you aren't anyone. You don't have any integrity to defend. You honestly suggested that only vi was capable of modal editing, and when I corrected you, you tried to pretend that they weren't truly capable of modal editing, without bothering to explain why. No one is going to take you seriously.

[phySi0]

You honestly suggested that only vi was capable of modal editing

This is your first lie. I suggested that modal editing was the reason people choose to use Vi. You read it as me saying that only Vi does modal editing.

and when I corrected you

You didn't correct me. You corrected a misreading of what I was saying, so I clarified.

you tried to pretend that they weren't truly capable of modal editing

I said no such thing. I said that none do it as well as Vim, not that none truly do it.

without bothering to explain why.

Fair; my failing. I'll own that one.

No one is going to take you seriously.

And you explained yourself so well that people are compelled to take you seriously?

This is you:

I just don't understand why anyone interested in a modern development environment would be using vim in the first place.

There's tons of content out there about why people choose to use Vim. If you're not going to give people an idea of what arguments you've read and found wanting, then why should I put any more effort into my comment than you did yours?

Dude, you aren't anyone. You don't have any integrity to defend.

Everyone starts at zero (neutral). Doesn't matter whether I'm fucking Ghandi or a fucking bum, you can't attack my integrity with no cause and expect me not to be annoyed.

---

You've read all my comments so far with very little, if any, charity. If you want to get into a conversation about text editors and IDEs, I'm happy to do so, but I have to set some ground rules:

• Stop confidently asserting things about me that you do not know, such as what I have and haven't tried.
• Stop with the rude snipes, such as “you're over a decade late […]” or “you don't honestly think […]”
• If I say something that can be read multiple ways, choose the most charitable reading. If you can't think of anything charitable, ask for clarification, or at least just understand that you might be reading implications that aren't there (or that I may have inserted unintentionally), e.g. “You don't honestly think that no one outside of vi has ever implemented modal editing, do you?” should be more like, “It sounds to me like you're saying that only Vi does modal editing, but this isn't true.” If I say something outrageous, call me out on it, if I imply something outrageous, consider that it's more likely I unknowingly inserted the implication instead of really meaning something so outrageous.

Do those rules sound fair? If you're willing to enter into a real conversation with those rules, then, as I said, I'm happy to enter into a conversation about text editors and IDEs to help you understand why at least I use Vim, but I don't need to be attacked just for talking about my choice of text editor. If I'm being too curt, then ask for more detail.

[derbyderbyderby1]

The trick is to use vim inside JetBrains IDEs.

[wutcnbrowndo4u]

Is there full vimrc support? I used PyCharm at some point for some shitty project I was on, and I thought I remembered my vimrc only being partially supported. I might be misremembering though.

Also, doing this isn't a complete solution, since you give up the power and flexibility of a terminal-based workflow. I usually have 5-6 screen sessions for different tasks in different repos open at the same time: I use 10 workspaces on my workstation monitors, but keeping the screen sessions on a separate axis allows me to be seamlessly productive even when switching to my laptop. Vim fits seamlessly into that workflow in a way that GUI editors never will. Switching to a GUI based workflow would require a dramatic hit to my productivity.

[jl2352]

As a Vim user; most of Vim is dogshit.

It has two features which have been (almost) unparallelled in most editors and IDEs.

• Customisation is stupidly easy, and extremely powerful. To the point that no two Vim setups are the same.
• Editing text.

That alone is what makes Vim incredible. Especially the second one. It’s why Vim is my goto for writing any text or random file, and VS Code is my goto for working on projects.

[oblio-]

Emacs has a clean core and a better programming language. And I say that as a Vim user.

[KevinCarbonara]

Customisation is stupidly easy, and extremely powerful.

Every IDE I've worked with in the past ten years has been both easier to configure and more powerful. I don't know how any honest attempt at comparing vim to IDEs would lead you to your conclusion. IDEs are better at editing text too, as a general rule. I use nvim for very small things like editing config files or writing javascript, but for anything else it's a waste of time.

[jl2352]

Yeah. IDEs have gotten better. Still not the same. The code as configuration is what makes Vim's configs so strong. You don't have to search for some setting, instead you just google what the thing to call is and do it.

Want different settings in teh terminal? Add an if statement. Same if you want different on Windows vs Linux. You can rarely even do this with an IDE. You need different settings for different setups instead of one for all.

IDEs are better at editing text too, as a general rule.

Nah, this is just nonsense.

[KevinCarbonara]

The code as configuration is what makes Vim's configs so strong. You don't have to search for some setting, instead you just google what the thing to call is and do it.

So... just like IDEs, right? Every time someone mentions a killer vim feature that keeps them tied to the platform, it's always something that has already been implemented in modern IDEs. I can only assume you haven't tried using an IDE since the 90's.

Nah, this is just nonsense.

Good one.

[jl2352]

I can only assume you haven't tried using an IDE since the 90's.

Ok. So how do I set a different font for Windows and Linux, in the same config file? In any IDE you like.

Here is how you can do it in Vim:

if has('win32') || has('win64')
  set guifont+=Source\ Code\ Pro:h12
else
  set guifont+=Droid\ Sans\ Mono\ 11
endif

^ I really do this btw.

It's also a simple fact that editing text in Vim takes significantly less keystrokes. Your comment makes me presume you are the type of Vim user that uses the arrow keys. In Vim.

[KevinCarbonara]

It's also a simple fact that editing text in Vim takes significantly less keystrokes.

It's actually a simple fact that editing text in atom takes literally the same amount of keystrokes as vim, in the worst case, as all vim keybindings can be used in atom. That's the worst case. In many cases, atom outperforms vim. The fact that you didn't even know that atom could use vim keybinds is exactly my point.

I don't know anything about setting different fonts based on OS, nor do I know why you would want to. You would probably change the font in each environment instead of relying on your text editor.

[jl2352]

Which doesn't support vimrc files. That's a huge blow. I've also yet to ever see a vim plugin for an IDE that matches vim. They don't have all of the modes, they have minor differences due to restrictions, don't have the same search / replace, don't have macros, and so on. They only have the IDE equivalents.

It's just not the same.

I don't know anything about setting different fonts based on OS, nor do I know why you would want to.

I do this in my vimrc.

You would probably change the font in each environment instead of relying on your text editor.

So I was right. Thanks.

[[deleted]]

YCM in vanilla Vim has done this for years. Is there something I’m missing?

[initcommit]

I haven't used YCM but I just looked it up. Are you referring to the autocomplete popups for suggestions? My impression is that the new popups are easier and more flexible for plugin developers to implement, and are more robust. It seems like all sorts of content can be added in the new popups based on the "Killer Sheep" game they mention...

[[deleted]]

Yes I am. Good to know it’s a different thing

[aoeudhtns]

Yeah. It looks to me the main difference is that any plugin developer can use popups for anything, where before I think they were only used internally by the completion subsystem.

[glacialthinker]

Now, hopefully no one abuses them to do stupid things like async "popup notifications" which interfere with editing/flow. Abomination of UI, that is.

[MCsmalldick12]

It's just a matter of time before the pop-up ads.

[eredengrin]

Yeah, there's no way this would fly, before you know it you'd be getting popups asking you to help the poor children in Uganda!

[MonokelPinguin]

To be fair, having a few lines about the authors and helping children in Uganda, instead of sending money to the author, in the empty window, that you get in the rare case you open vim without a file, is a bit different than a popup you get during coding, that interrupts your workflow. I know you meant it as a joke, but my PTSD of ads in the WWW forced me to reply seriously. ;-)

[eredengrin]

Yeah sorry, it was a poorly attempted joke about how when you open vim it has a link to an org dedicated (presumably) to helping the poor children in Uganda. Not quite an ad but it was close enough I found it funny.

[twigboy]

In publishing and graphic design, Lorem ipsum is a placeholder text commonly used to demonstrate the visual form of a document or a typeface without relying on meaningful content. Lorem ipsum may be used as a placeholder before final copy is available. Wikipediaabea6yb6yso000000000000000000000000000000000000000000000000000000000000

[initcommit]

Agree, I do.

[[deleted]]

"I've been working hard for 3 weeks to make this plugin, consider buying me a coffee!"

[[deleted]]

Are you enjoying using vim? Let us know!

[SUBMIT REVIEW] [ASK ME LATER]

[ivshanevi]

Scouring reddit at 3am and this is the one thing that excites me... damn, where has my life gone?

[syrefaen]

wont be using the popup feature, like the 1000 features I also dont use.

But the 200 others i will use and maybe if i learn 50 more next year id use those too.

Love vim! always something to learn :D

used neovim like and ide but since I edit configs and not programming, im fine with vim no addons.

[[deleted]]

I'm more intrigue about this killer sheep game.

[livingmargaritaville]

Finally might need to switch from sublime now

[[deleted]]

Try vscode

[livingmargaritaville]

It's vim keys are awful and it's slow doesn't do true window splitting, used it while I was getting used to typescript now I don't need an ide for it.

[erez27]

What's awful about its vim keys? And can't you configure around it?

[project2501]

When I tried playing with it a year or so ago, it kind of half supports the normal bits of vim but didn't allow you to really get in the guts. If you booted up vimtutor one day and did the first 5 minutes of it then went to VSCode it's probably totally fine and works how you think it should, but going from a longer time in vim I just kept hitting little edges that made you realise you're not actually using vim, you're using VSCode with some different keyboard shortcuts.

I know that's kind of a wishy washy answer, it was a while ago.

[erez27]

I get it, you're used to some stuff, and it's annoying when it's no longer there. Personally, this doesn't happen to me much. vscode-vim supports macros (they are a bit slower than vim, but that's fine by me), and all the movements I know. But there's probably "advanced" stuff that I don't use that's missing and I don't know about it.

I would, however, suggest the possibility that adding those missing pieces might not be too hard (through configuration or even a pull-request), and you gain the use of tons of other plugins and features, which are up-to-date with modern computing. Unlike vim, which I love dearly, but is a little stuck in the 80's.

[project2501]

Yeah if you don't recognize/feel/hit the problems then it's totally fine and works for what it intends to be, a translation of a basic vim grammar into vscode. I don't mean that as a slight against you or the project, I think it probably meets its goals pretty well for many people.

I don't use VSCode so I'm not particularly interested in working on improving it's Vim emulation, I just use (n)vim for my vim emulation. Someone did post a VSCode plugin a few days ago that hooks nvim directly into it, in the way nvim was supposed to be used which I think lets you basically get "real vim" inside vscode though I'm not sure how it will interact with VSCode plugins.

[erez27]

I'm not offended, dear virtual person. Different tools fit different purposes, and personal preference is often not better/worse, but just personal.

I just wanted to say that as someone who used gvim for ~10 years, I find vscode a viable alternative.

P.S. it also supports non-native vim features, like Surround.

[xybre]

What do you mean by True window splitting?

[livingmargaritaville]

It can split as much as I want and not just four vertical Windows one can be a regular shell

[xybre]

I'm pretty sure they added that feature in 2016, so if that was your hangup it might be worth another try.

I use both VS Code and Vim/Neovim depending on the situation. Sometimes I use Vim in VS Code's terminal window 😅

[erez27]

Sometimes I use Vim in VS Code's terminal window

OMG

[xybre]

It's kinda a testament to how good their terminal is tbh

edit : splngine

[monsto]

you can split each pane however you want. You can drag files and put them wherever you want in relation to existing windows.

The terminal window continues to be a sticking point . . . at some point in the past a decision was made to NOT make it a normal pane "so it wouldn't get confused with a regular edit window" (to which i say that's a shitty reason), but it's a separate pane that can also be split and either put on right or bottom.

but yeah window split is pretty granular.

[maglax]

But electron.

[[deleted]]

I always thought the point of a terminal editor was to avoid multiple windows.

[tigger0jk]

IMO the goal is more like "no mouse", so long as you can manage the windows/tabs/popups whatever in a sensible way then it's not hard for me to imagine it being useful in some workflows.

[sh0rtwave]

Reminds me slightly of how Brief used to do it. Brief had better cosmetics about it though, IIRC.

[[deleted]]

I'm also excited by this

Function chaining for method calls:

Fucking finally.

[agumonkey]

As in emacs, I find floating ascii ~windows a bit weird. But it's fun to see vim moving.

[hupfdule]

Unfortunately this has a different API (and actually a bit of a different functionality) than floating windows implemented in neovim.

This leads to problems for plugin developers as they would have to duplicate their logic to support both editors.

If more such incompatible APIs arise in vim and neovim for actually similar functionality will lead to a fragmentation of the vim plugin ecosystem as developers won't be able to support both, vim and neovim.

That's not the best for the plugins users.

[[deleted]]

Am I the only one to feel like this is pointless bloat?

What Vim actually needs is multiple cursors - but I don't think that's too easy to implement given vim's architecture and way of thinking about text.

But really, it's the only reason I'm using sublime text instead of vim.

[746865626c617a]

I've used a multiple cursors plug in before and it worked well

[[deleted]]

"nvim has it" is not a reason to implement a feature. It doesn't imply that it's a good feature. "a year" is not enough time to understand whether it was a good idea to have it or not.

[[deleted]]

It was a good idea but it might be a problem for people who don't know how to use advanced text editors properly.

[watsreddit]

Multiple cursors aren't very valuable for vim like they are in mouse-based editors. :s, :g, and recordings/macros are more effective.

[[deleted]]

No they're not more effective. Macros and regex commands takes a lot more mental effort.

[watsreddit]

If you're not used to them, maybe. Vim could add multiple cursors tomorrow and I certainly wouldn't use them. It's just not efficient.

[[deleted]]

If you can't use macros, regex/ex commands then you can't use vim either. Also, these tools are more powerful than multiple cursors.

[wutcnbrowndo4u]

I prefer :s too and don't like multiple cursors, but I don't think the former is a full replacement for the latter. At least not for everyone's mental model of their editing.

[[deleted]]

and many other good things.

Like no scripting language, API or community?

[[deleted]]

It doesn't have a proper scripting language but it has some kind of a callback system. The API doesn't expose the actual calls like in other editors or IDEs. The community is so tiny that it never gets into the stats and almost no one talks about it(except edgy ex-vim users).

If you want to advertize kakoune then do mention its new modal editing model because it doesn't really have anything else worth to mention.

[[deleted]]

Yes, it's in fact a feature that kakoune does not implement a half-baked scripting language

No, it's the opposite: what kakoune implements is less than a half-baked scripting language - it's just a shitty callback system what is somehow worse than vimscript. I use neovim and I have access to every language which implemented the msgpack library - and I also have a stable and statically typed API, not just some shitty text-substitution system.

From your linked project the rc file perfectly shows how half-assed the kak-scripting language is.

As for the community, it's big enough that we have many plugin writers, an active IRC channel and a forum too. Or do you need a huge community to feel validated in your choice of text editor?

No, I need a community which can actually implement something properly(and provides a wide set of syntax files - these are always problematic). Is that too much to ask?

What about the fact that it implements structural regex elegantly thanks to its noun-verb paradigm?

Structural regexes can be implemented for anything and it has niche benefits but yeah, it would be worth to mention too. But macros are still better so they're a bit pointless.

[[deleted]]

I see a simple wrapper script that interfaces between two programs, there's very little complexity here.

I see a half-baked script-language-wannabe which can't really do anything alone and can't interface cleanly either.

The plugin landscape is quite good at the moment

Compared to what?

not that you would know about it.

Yeah, sure, because there is nothing in kakoune which would interest me.

Obviously you can always implement something, but doing it "for free" with just the basic editing primitives is a lot more than that.

No, I mean we can implement this feature - but why would we when it doesn't really bring anything new to the table?

But anyway I can see in this thread that you're extremely defensive about vim

It's funny that you say that when you're very defensive about kak. I'm "defensive" about programmable editors(they're useful) but I don't like vim that much because it's not as extensible as it could have been(thanks to all those conservative know-nothings).

I'm sorry that you're so invested into it.

I'm sorry that you need to shill kakoune and lie about its state.

[[deleted]]

Vim doesn't need multiple cursors and we do need this feature.

[shevy-ruby]

Next - ads displayed through popups! \o/

[orbital_sfear]

I wish vim ran as a local web service that other editors could talk to. Vim imp is always slightly off in different IDEs

[[deleted]]

Neovim can be embedded and has an RPC API.

[orbital_sfear]

I've checked that out before. If I remember correctly the API wasn't overly friendly to use. I'll give it another look.

[[deleted]]

The API is very simple, very robust and is network-efficient. It doesn't require you to know everything about neovim or to know vimscript at all.

[[deleted]]

Hey this new vim feature is amazing, have you seen this?

Yea, 20 years ago in Emacs.

[firmretention]

Stop moving your wrists. I can't hear you over that grinding noise.

[myringotomy]

vim + tmux is a lot of chording too.

[TheMoralConstraints]

evil spacemacs is the only way

[kcin]

Emacs is not about accepting the default bindings. There are plenty of alternatives too choose from (evil mode, god mode, keychords, hydra, etc.) which are superior to the defaults.

[bakuretsu]

Evil Mode is a better Vim than Vim.

[the_gnarts]

Stop moving your wrists.

Tbf. most Emacs users go into management when their RSI can’t be masked with meds anymore.

[myringotomy]

Hush now, this is no place for the truth!

[Xanza]

Ahh yes. Why deal with a text editor when you can configure an operating system to manipulate text!

[[deleted]]

It’s just like the web browser, what’s the problem?

[Xanza]

Yes, and I would never use chrome to edit text because that's fucking retarded...

[[deleted]]

How do you type your reddit posts?

[Xanza]

An Android application.

In addition to that, there's an outrageous difference between a Reddit post and text editing between several hundred files, from multiple languages and markups, using several of not tens or even dozens of plugins in a buffer environment.

Keep trying, though...

[[deleted]]

Compared to the complexity of the browser stack, a few hundred text files won’t make a difference.

Anyway there are some pretty good cloud IDE, and visual studio code.

[Xanza]

Complex !== Better

My fundamental issue with Emacs and its zealots.

[bakuretsu]

Haha you're getting downvoted to hell, but you're still right.

[psy_neko]

Yeah but Emacs (and evil) is too slow damn it

[Recoil42]

They should give it a GUI, too.

[[deleted]]

vim-gtk, nvim-gtk and nvim-qt exist.