Does anybody know what native feature is missing in Vim that makes Ctrl-P (with all optimizations) slower than Emacs ido-mode?
Vim 8.0 is coming
241–250 of 420 posts
Re: Vim 8.0 is coming
#242Earlier quoted context omitted.
I became an heavy Emacs user as I could not find the comfort of Borland IDEs in UNIX, as I started to use it. Since I moved away from C++ into Java and .NET land, never felt the need to use them any longer. And nowadays, with Qt Creator, Clion, xCode, AppCode and VS, I also don't feel the need of them when I need to go back to C++. It is very good to know the basics from plain Vi, because there are still commercial U…
> So for me the question is why there are still people that enjoy working as if their computers are using a 25 year old developer experience. Because for a lot of tasks using the mouse is garbage compared to the speed you can get using the keyboard.
It's not like you can't use keyboard shortcuts in a modern IDE. And for some tasks using the mouse actually is faster. I think there's some research by Apple (?) that shows this.
Re: Vim 8.0 is coming
#243I have vim, neovim and emacs (and spacemacs) installed. Right now I'm trying to get into emacs a bit more. What's interesting to me, and the reason I try to keep up to date with the latest changes for all four editors, is that it's been now, what, 25 years (?) since emacs and vim started "competing" and they still are. I guess we could be saying the same in 10 years about firefox and chrome, but it still is amazing i…
>I guess we could be saying the same in 10 years about firefox and chrome That's pretty optimistic considering Firefox's current marketshare. Based on its momentum I'd say in 10 years, at best, I expect it to be where Opera was before it became a Chromium fork. For now Firefox does things better than Chrome but I don't expect them to keep up when it becomes a community project. It'll be like using Opera used to be.
I imagine Firefox's marketshare dwarfs both vim and emacs
Re: Vim 8.0 is coming
#244Earlier quoted context omitted.
> So for me the question is why there are still people that enjoy working as if their computers are using a 25 year old developer experience. Because for a lot of tasks using the mouse is garbage compared to the speed you can get using the keyboard.
It's not like you can't use keyboard shortcuts in a modern IDE. And for some tasks using the mouse actually is faster. I think there's some research by Apple (?) that shows this.
I definitely don't think it's black or white. If you could have the power of vim (all vim, not just the basics) within an IDE, I'm sure a lot of people would be significantly more productive than only using vim or emacs. I think part of what neovim attemps to do is bringing all vim inside IDEs. That said, I have a feeling that people believe that all vim users use the editor with no plugins or config whatsoever. There are a lot of plugins out there that, while not bringing all an IDE has to offer, provide a lot of what someone would expect from an IDE, and if that is enough, I don't see why someone couldn't be more productive in it than in an IDE.
Re: Vim 8.0 is coming
#245Earlier quoted context omitted.
I became an heavy Emacs user as I could not find the comfort of Borland IDEs in UNIX, as I started to use it. Since I moved away from C++ into Java and .NET land, never felt the need to use them any longer. And nowadays, with Qt Creator, Clion, xCode, AppCode and VS, I also don't feel the need of them when I need to go back to C++. It is very good to know the basics from plain Vi, because there are still commercial U…
Because the experience is so much better. The power of command line is intoxicating, and going to GUI tools files like programming with hands tied behind your back and being blindfolded.
I apologise in advance if this sounds dismissive, but: I've tried to use both Vim and Emacs and Neovim and Spacemacs, and every time my pain point is that they're designed for use on the command line rather than as an environment I can switch in and out of. I know this isn't strictly true as both editors can be run as separate applications that you don't quit for weeks, but their roots have persisted into how they're expected to be used.
Take my first foray into vi, at its most basic level. I'm at a shell prompt, where I can use vi to edit multiple files, saving each one when I'm done with it and occasionally switching to another window to run something else, coming back when I need to edit more. But there's nothing storing my list of open files or buffers and where they are on my screen, my position in each file isn't saved; it's like vi expected me to spawn a new instance every five minutes.
When I tried emacs, which allows much more functionality inside the editor -- connecting to servers, databases, or hosting shells or debuggers -- it just made the problem worse. If I started a shell inside emacs before stopping the emacs process entirely, that shell won't be there when I get back and my files won't either. If I want to have a specific file on the right-hand side of my screen, emacs will forget where I put it. If I open a file in a new window, that file will be gone. If I want to have a file stand out by changing its background colour to a subtly-different hue, that will have changed back by the time I need to re-open my editor.
I don't like this idea; I don't want my editing environment to be some ephemeral process that's created when I start and gets destroyed when I'm finished. And while Vim has sessions and Emacs probably has three forms of saved states, they don't quite work: no saved window positions and sizes, no working with files you haven't given a name. I imagine that it's the same feeling you get when you read that something allows Emacs-like functionality: on a checklist, they might both have tick marks on each row, but when you try to use it, it doesn't work how you expect. I think that Emacs and Vim's command-line history have made its users used to this behaviour, spawning all sorts of tools to make configuring your environment easier instead of just trying to save the changes as they happen. I've seen plugins like CtrlP or projectile that enforce the idea that your environment shouldn't last, you can just set it up again each time. And that means you don't bother personalising your environment and putting things where you want them to be, because it's all going to be irretrievably gone if your computer crashes, so don't get attached. Alright, rant over.
Re: Vim 8.0 is coming
#246For Xcode users out there, XVim has been a game changer for me https://github.com/XVimProject/XVim
Re: Vim 8.0 is coming
#247For Xcode users XVim out there, This has been a game changer for me https://github.com/XVimProject/XVim
Re: Vim 8.0 is coming
#248Earlier quoted context omitted.
In Visual Studio, creating a custom keybinding appears to involve three dropdown menus, a dialog box, and at least two UI controls. In Emacs or Vim, it's a single line of code you add to your initialization file. I think there may be different definitions of "easy" in play here. I'll concede that Visual Studio makes custom keybindings possible , but so does any text editor worthy of even momentary consideration as a…
> "And I'll take your challenge. Here's something I can do in Emacs: I can take a spreadsheet received from a client, full of intended configuration settings for a custom internal application. I can export it as CSV, load it in Emacs as such, and extract the relevant sections of the content into tables in a plaintext Org-mode document. I can then add a function to that document, in whatever language I choose, which w…
Nope. This isn't a migration; it's one-off data population. Fluent Migrator can do that, from its documentation, but it wouldn't be required, and since this isn't a migration, Fluent Migrator doesn't really bring anything to the table that I can see. So you're building a custom software project in your language of choice, with all the overhead that implies. In the workflow I described, you create a file and activate Org-mode. (Or just create a file whose name ends with ".org".)
There's also the documentation task, which has to include the source data and resulting SQL script, as well as the transformation code. I'm not seeing anything here that would simplify that in the slightest; you'd have to either write the HTML document by hand, or write code to generate HTML. In the workflow I described, all that code is already written, and you can invoke it with a single keystroke.
And beyond that, there's the matter of data ingestion. You're starting from CSVs, so you have to read those and parse them just to have the data you need to work with in a form which you can use. Any serious language has a CSV parsing library, of course, so that's not a difficult task in its own right, but it's still more code you have to write, and more effort you have to put in - selecting a CSV parser, adding it to the project, learning its API, et cetera. In the workflow I described, it's a copy-paste operation.
Don't get me wrong - I didn't say, or assume, that anything I described couldn't be done in Visual Studio. But at this point we're talking about, what, a few hours at least? And you're spending a fair chunk of that time on overhead, especially in document generation. You have to find, vet, and install libraries, write or modify a bunch of code, and so forth. By the time you're done, you've probably had to spend the better part of a day on this one task.
In the workflow I described, the only code I needed to write was that in which I expressed the actual transformation from tabular data to SQL statements. Everything else, Emacs and Org-mode took care of for me; all I needed to know was how to invoke capabilities already present. And I had the job done and dusted in less than an hour, with plenty of time left in my day for other work.
That's what I mean when I say Emacs and Vim give you superpowers - not that there's anything you can do in one of those editors that (with enough effort) you can't do in another environment, but that those editors are better than anything else (at least anything else I or anyone I know has ever encountered) at helping you get more done, faster, without having to spend time on ancillaries that distract you from the meat of the task at hand.
Re: Vim 8.0 is coming
#249Earlier quoted context omitted.
Looking forward to drop shadows and brushed-metal in tmux, which you shall promptly post. Also fullscreen exposé-like dashboard with previews would be nice.
Like we don't have better things to use our processor cycles on :P. Also, I thought skeuomorphism was dead now?
It doesn't necessarily have to be skeuomorphic, but I like to burn some processor cycles making different things look different, not necessarily brushed-metal attractive. So my todo-list files don't look like my source code files which don't look my terminal windows, which helps me tell what's what.
(And it's beside the point, but brushed metal has been dead for years by now!)
Re: Vim 8.0 is coming
#250Earlier quoted context omitted.
> For me it's the question, why it's so hard to understand that people have different likings without to downgrade them? Because while everyone can have this or that preferences, personal taste is not the be all end all argument, except in the "it's a free country" way. Whenever we want to assess the state of our tools, and what we need to make them better etc, we need to reach an agreement beyond "works for me" and…
Who's "we"? If someone reaches a maximum of productivity using an editor made in the 70's, who is anyone else to tell them otherwise? Preferred tooling for reaching maximum productivity is an inherently personal thing - you may do your best in emacs, the other guy in vi, yet someone else in Sublime3 on Windows. Nobody is qualified to make broad sweeping judgments as to what works best for everyone. A few try, and som…
People usually claim that one thing is more productive than the other without any real evidence. I think it's mostly just so we can stick with something out of familiarity. Or sometimes it's so we can switch to something else because we're bored. The "it feels right to me" argument just seems unbeatable (you can't argue with it without seeming like a jerk).
For example, I might say that I'm super productive in IDE X, but I don't know for sure that I couldn't be more productive in IDE Y or Editor Z with various plugins. I haven't consulted any research in making my decision nor have I conducted any real research of my own.
I guess maybe it doesn't matter. If everyone is "happy", maybe that's good enough. But I see people struggling to do certain things in their environment of choice and that ends up having an effect on not just them but potentially their coworkers.