121–130 of 420 posts
Earlier quoted context omitted.
According to Wikipedia ( https://en.wikipedia.org/wiki/Vi and https://en.wikipedia.org/wiki/Emacs ) both vi and Emacs are from 1976. 40 years this year!
To be fair, vim is not strictly vi although they were related. Amazing, I was 1 year old when both were started. How many other software package has such longevity? Unix and its various guises?
Earlier quoted context omitted.
According to Wikipedia ( https://en.wikipedia.org/wiki/Vi and https://en.wikipedia.org/wiki/Emacs ) both vi and Emacs are from 1976. 40 years this year!
To be fair, vim is not strictly vi although they were related. Amazing, I was 1 year old when both were started. How many other software package has such longevity? Unix and its various guises?
Earlier quoted context omitted.
I used to think like this, but I don't any more. Both command line development tools and IDEs require work to get the most out of them. I used to think command line tools were better because I was more in control, then I realised if I just spent the time learning what IDEs were doing on my behalf I would still have more or less the same amount of control, especially if the IDE is customisable (which the best ones are…
That's decidedly not true. Nor is this about customization of workflows. I am talking about actual unadulterated power to do things you cannot do in an IDE. All IDEs optimize for the average use case. If they do expose a set of advanced commands or transformations, they are hidden deep in the menus and what you can do with them is extremely rigid and limited. At most you have a few dozen commands (you would call them…
Something tells me instead of telling you what you can customise in good IDEs I should show you. With that in mind, tell me something I shouldn't be able to customise in Visual Studio and I'll show you how its done. To start this off, here's how to create custom keyboard shortcuts, as you can see it's very easy to do:
https://visualstudiomagazine.com/blogs/tool-tracker/2012/07/...
Earlier quoted context omitted.
> Is there a way how I can copy blocks of code outside the vim window to another application without also copying the line numbers? If you're running vim in a terminal, there is an option to add native clipboard support to your yank registers. If you use vim under OS X and have installed it with brew, it will be added automatically. To check whether your current vim installation has clipboard support, try running `vi…
a good example for a stupid limitation and the enprmous waste of brian power just for a very simple thing. Have to start studying and doing real research for the most simple features. Waste!
Furthermore, Vim needs to be setup and is configurable because it existed before many computer usage patterns had been standardized that we take for granted now (e.g., Vim's cut and paste system is different than any current big name operating systems).
But the very fact that Vim pre-dates these paradigms, and continues to be used despite the extra work it requires to get past that, this very fact is what makes it more likely that you'll be able to continue using it indefinitely. I.e., Vim will survive the next paradigm shift, because it survived the last one.
If you really want to be careful about investing in learning a tool, the ones you should be careful about are the ones that have not survived a paradigm shift yet.
(Photoshop is great example of a dangerous skill investment in my opinion, Photoshop takes an extraordinary amount of muscle memory to use effectively and it hasn't yet survived a paradigm shift. Those skills look poised to become completely obselete by touch-based design tools soon, 5-10 years from now. Not saying I have an better idea, because Photoshop is still probably the best tool for doing that type of work, but just plan on throwing everything you learn away.)
Earlier quoted context omitted.
From what this initial view of Vim 8.0 looks, it actually went in the direction of Neovim, the asynchronous inner works were what made me try Neovim in the 1st place. Now, from what I can understand, Neovim only has two advantages, a cleaner code trough re-writing (it's debatable if that's really an advantage) and the ability of using other languages for plugins (which seems clearly and advantage due to the lacking f…
Don't forget true color support for those sweet colorschemes!
It's a very overlooked feature that has a great positive impact in usability. Been talking in a bug thread spacemacs about this same problem for months and there is still no solution to be seen.
Earlier quoted context omitted.
From what this initial view of Vim 8.0 looks, it actually went in the direction of Neovim, the asynchronous inner works were what made me try Neovim in the 1st place. Now, from what I can understand, Neovim only has two advantages, a cleaner code trough re-writing (it's debatable if that's really an advantage) and the ability of using other languages for plugins (which seems clearly and advantage due to the lacking f…
Neovim also has the terminal buffers, which Vim has explicitly stated to never add. (Source: Somewhere in :help, but unfortunately I can't find it right now.)
I can do that in Vim nicely after hacking the console colors, and Neovim without having to care about the colors and in Emacs it remains impossible.
Earlier quoted context omitted.
To be fair, vim is not strictly vi although they were related. Amazing, I was 1 year old when both were started. How many other software package has such longevity? Unix and its various guises?
Not quite as old (circa 1978) but TeX is still alive and well: https://en.wikipedia.org/wiki/TeX
Earlier quoted context omitted.
vi is not Vim.
Vim stands for vi improved and started on the Amega in 1991 so almost 25 years old. Certain people still use vi which was an improvement over ed August 1969 (Though I have been known to use ed in scripts from time to time).
I 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 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…
Existing responses already covered a lot of things, but the simple answer is: most of us don't.
The state of these editors and tools 25 years ago, while largely the same, is still very different: there are still major improvements, many new packages, etc.
Could I work on a 25-year-old system? Sure, and it'd be largely the same, but it'd be pretty uncomfortable; those subtleties matter a great deal. ;) Especially in my editors (both Emacs and Vim), and on the command line (both tools and even readline).
I 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 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…
I use MacVim and my .vimrc file follows me around wherever I go. My experience is great in my editor because the few minutes I invested here and there have huge payoffs over time whereas most IDEs plateau.