Great job tarruda, I sent $100 to the bounty.
Since you created this thread, I'll respond to your comment here:
> Neovim is an attempt to aggressively refactor vim source code in order to make it simpler to maintain and implement new features
I think this is a much better idea than rewriting in some other language, as proposed by Marc Weber and others. Those kinds of projects are usually doomed from the start.
> Remove tons of legacy-supporting code
It depends on what legacy systems you are talking about--one of Vim's strengths is backwards compatibility. But I do think minimum requirements should be established. For example, I do not think it is a good idea to support OSes that have not been updated in more than 10 years, such as Amiga and Windows 95.
> Remove all GUI-specific code from vim
Seems like a good idea, but I don't really know.
> Implement a generic 'UI' that speaks a common protocol such as json/msgpack RPC
Is this efficient? Will C bindings also be supported? (Possibly a stupid question)
edit:
Will neovim support terminal (non-GUI) mode?
Here's me doing it with the following macro:
A,^Mdesc: ''^[^Wwjy$^Wwhpjjj
The beauty of macros is that they scale; running them ten or ten thousand times is simply a matter of changing the count before typing @@
. Watching you mash your arrow keys like some sort of Neanderthal made me mildly furious.
In hindsight, hpjjj
should just be P3j
.
You sound like you are using the wrong distro.
What about a virtual machine with a boring Debian "Stable" or "Testing"? Or some kind of Linux Container?
I mainly use vimwiki which is great so far. You can navigate through your wiki ctags like. you can export your wiki to html and host it somewhere to access it from anywhere. It also supports mathjax which allows you to write latex like formulas in the wiki, which will be rendered correctly with the mathematical symbols in html. Those are my main points, why I'm using vimwiki, but there's a lot more wich I didn't discover yet.
This is a good idea, but you can take it further...
Download Karabiner Elements https://karabiner-elements.pqrs.org (it's freeware, though you can sponsor it). Then:
remap Caps Lock to Escape when you tap it, and Control when you hold it down.
remap Return to Return when tapped, Control when held down.
This makes using Vim (and even more, Emacs) so much easier as you never have to use the Control key on the RSI-Prime bottom left position ever again...
Karabiner can do an awful lot more, but it's worth it for the first two changes alone. It's the one of the first programs I put on any Mac -- they feel really relimited without it. It's really very well worth checking out.
HTH.
The site should be improved because it's often the first destination people go to in order to learn more about Vim. The current design can give a bad (definitely out-dated) impression. If the site were more clear and less abrasive, it would likely persuade more people to use Vim than it does currently.
I know that I thought somewhat less of Vim purely based on the site when I first saw it. Look at the beautiful official page for Emacs (I believe it was updated a couple years ago now), by comparison.
https://stackoverflow.com/research/developer-survey-2016#technology-development-environments
Vim is still very popular, especially for it's age (it's stood the test of time).
The top two (notepad++ and Visual Studio) are likely boosted by the fact that so many amateurs use them. Not to say that many professionals don't also use them too (especially VS), but most programmers I know start out with notepad++ or some IDE and then move to a good text editor. It's also worth noting that the vim community has become slightly fragmented recently with the rise of neovim.
Another thing that's telling is that Visual Studio Code only accounts for about 7% here, but Microsoft pays shills to post it all over tech forums, making the numbers look bigger than they really are. If even just 10% of VS and/or Notepad++ users are amateurs (and this is completely within the realm of possibility) then it's pretty much on par with vim as far as usage statistics among professional developers.
It's unlikely amateur programmers would use vim because of the steep learning curve compared to Notepad++ and VS.
edit: just to clarify, by "professional" I basically just mean well educated about programming.
i've been on both sides of the fence. i've also written popular plugins and packages for both.
is emacs lisp a better programming language than vimscript? yes, it's not even close. but that doesn't stop people from writing amazing vim plugins -- vimscript is also turing complete after all.
culture is the biggest difference between the two. emacs users want to live inside emacs and will reinvent the wheel to do so. vim is very UNIX-philosophy and will defer to other tools like tmux and zsh to complete the experience. both are valid approaches.
if you want to try emacs/evil there hasn't been a better time. i generally do not recommend using distributions, but spacemacs is slowly changing my opinion. yes, it does a lot of black magic. yes, it'll install hundreds of packages. but it's also had hundreds of people working together to make it work for vim converts. the benefits cannot be easily overlooked.
Judging from your history with text editors, you should try out Oni.
It's a modern editor with neovim under the hood.
Basically it brings modern features to the table without ever sacrificing efficiency.
It's still early in developpement but new features get added very regularly.
I use it as my main editor since 2 or 3 months and it's been great!
> What's the best way to install vim on Ubuntu?
You know you already have it, right? Granted, that's not a very interesting build but that's more than enough for learning.
> I can just do "apt-get install vim"
Better do $ sudo apt-get install vim-gtk
, if only because it gives you clipboard support.
> Use a bundle, for example spf13-vim, but I also saw others
No! No! No! Don't install that thing!
> Build from sources
Well that's OK I guess. Not really funny or quick or practical… but OK.
> ?
You could also install Vim from a reputable PPA. That specific one never failed me back in my Ubuntu days.
I am so surprised that vimwiki has not been listed yet.
https://github.com/vimwiki/vimwiki/blob/master/README.md
<leader>ww and it opens up. Press <return> on a word or selected set of words and it becomes a link and opens a new buffer for that link's wiki entry. <backspace> takes you to the previous entry. A great way to build up notes. I also use it for work project notes, or other random things.
I like to save the wiki in my Dropbox. It's just a bunch of html files.
let g:vimwiki_list = [{'path': '~/Dropbox/Public/briefcase/vimwiki'}]
You can also :Vimwiki2HTMLBrowse to view in your browser.
Also I'll just say that it can do a lot more than your first glance might have you believe, but at its simplest it is easy to use and the basic functionality might be all you ever need/use.
I think that you are pretty far off base claiming that the "NeoVim people" (whatever that even means) claim that Vim is "horrible and unusable", given that the entire premise of the project is to maintain parity with Vim. And as for your other claims, just a quick browse through this sub indicates that people are hardly "coming out of the woodwork to yell" about things. As for the business with Bram, while I can't speak to the technical side of things, I suspect that you are in the extreme minority if you don't think that his management style is lousy.
I am sorry, but this is not why vim is awesome. Or why it is more awesome than other editors. You can achive all those examples with emacs, sublime, notepad++ and what not easily.
What makes vim special is its inherent grammar. You have a certain (and fairly small) set of operators you act with on your text. Operators take a count in how often you want to apply the operator. And operators take a motion for what is affected by the operator. It's that simple. Want to delete five words? 5dw. Want to copy the entire buffer? ggyG.
Why is this different to other editors? Because it scales. Instead of having to learn a certain command for a special use case, you can combine the various elements in a logical way. So each time you learn a new operator, or movement, or text-object, you immediately learn a ton of possibilities to edit your text efficiently just for free.
This is what I find invaluable in vim over any other editor without this input feature. I don't want to remember a brazilien different mode commands like in emacs. I don't want to remember that in atom, shift + ⌘ + d, is what I have to press to duplicate the current line. It is just yyp, because I have learned that repeating a operator makes it act on the current line and I know paste.
There is a really good blog post out there explaining this in more detail, I can't find it quite yet. But you can search for "vim grammar" and get a bit of information.
e: https://medium.com/@mkozlows/why-atom-cant-replace-vim-433852f4b4d1 This one I meant.
I use fzf plugin to open files really fast:
call plug#begin(stdpath('data') . '/plugged')
Plug 'junegunn/fzf'
Plug 'junegunn/fzf.vim'
call plug#end()
map <leader>b <cmd>Buffers<CR>
map <leader>f <cmd>GFiles<CR>
map <leader>F <cmd>Files<CR>
map <leader>l <cmd>Files %:h<CR>
As the maintainer of fzf, I find this feature very intriguing. fzf is an ncurses program that takes up the whole screen, so I'm using some hacks involving tmux splits or external terminal emulators when launching fzf from inside vim or gvim. With this, I might be able to integrate fzf into native vim splits and it would be great, especially so for gvim.
I think the best experience you're gonna get is Vim and Rails inside of a Linux VM. It's very common to run a Linux virtual machine in Windows using something like VirtualBox. Not saying it can't be done, but you're very likely to have a harder time learning vim inside of Windows and it will probably discourage you. If you're new to Linux, I'd suggest installing Xubuntu in your virtual machine. Most vim tutorials you will find online will revolve around some type of Unix environment like OSX or Linux.
You might try the plugins fzf or ctrl-p.
From the fzf github:
grep --line-buffered --color=never -r "" * | fzf
ag --nobreak --nonumbers --noheading . | fzf
So yeah, give those a try. I don't know about ctrl-p from experience, but I seem to remember seeing some people do something similar.
Also check out pentadactyl which is a fork of vimperator. It seems to be a more active project these days. It gives you a nearly mouseless browsing experience.
> wait, why doesn't every project require real name then?
Because they either don't realize or simply don't care. Bigger projects and companies face bigger possible copyright issues. The random project by user1234 on github doesn't have nearly the same considerations to make. And realistically speaking, they wouldn't be looking to fight a copyright battle anyway if one started.
> PS: If I have a project, could I put into license that by contributing into this project you give me full right the the contributed piece of code? Would that work?
Not in the way you intend, no. The license you choose applies to your code, and your code only. If user1234 submits code to your project, that code is under whatever license user1234 chooses. You can require them to use a compatible license, but that takes us back to the original problem of confirming they are actually the copyright holder for that particular piece of code. And essentially, if you're accepting random code from anonymous users into your codebase without checking who wrote it, you do so at your own peril.
That said, some projects do this, for example places like Google and Ubuntu has their 'license agreement' which essentially transfers copyright from the owning party to Google/Canonical/etc.. But you have the exact same problem that this requires an actually agreement, for which you would have to personally agree too, which requires your real name. This makes sense if you view it as a legal document - you obviously wouldn't be able to sign a legal document with an obviously fake name.
This all goes back to copyright being the default - you have to give permission for anybody to be able to legally use your code, and that permission can only be given by the actual person who writes the code. Of course, it is still possible to use the code, it functions like any other code, but the project using the code is taking a risk by doing so.
What's up /r/vim? Last time I posted this, I got a lot of feedback. I've been working like crazy to add all of the features you guys have suggested, and will continue to do so. Want a feature? Just post an issue to cVim's GitHub page, and I'll be happy to look into it.
neovim's terminal emulation is amazingly good. That's a solid option.
I use my window manager i3 to handle splitting non-vim windows, though.
For tmux / screen users: imagine tmux but for anything - browsers, terminals, vlc. That's i3wm.
This is going to be a Neovim tip.
Neovim has some saner defaults than Vim. If you migrated your Vim .vimrc to a Neovim init.vim you might have redundant settings lingering.
From the Neovim documentation:
- 'autoindent' is set by default - 'autoread' is set by default - 'backspace' defaults to "indent,eol,start" - 'complete' doesn't include "i" - 'display' defaults to "lastline" - 'encoding' defaults to "utf-8" - 'formatoptions' defaults to "tcqj" - 'history' defaults to 10000 (the maximum) - 'hlsearch' is set by default - 'incsearch' is set by default - 'langnoremap' is set by default - 'laststatus' defaults to 2 (statusline is always shown) - 'listchars' defaults to "tab:> ,trail:-,nbsp:+" - 'mouse' defaults to "a" - 'nocompatible' is always set - 'nrformats' defaults to "bin,hex" - 'sessionoptions' doesn't include "options" - 'smarttab' is set by default - 'tabpagemax' defaults to 50 - 'tags' defaults to "./tags;,tags" - 'ttyfast' is always set - 'viminfo' includes "!" - 'wildmenu' is set by default
I often see a bunch of these redundant settings in people's init.vim when browsing dotfiles on GitHub.
:help 'number
:help tabpage
. No plugin needed. Read :help buffers
first, too. You might not need tabs.
:help statusline
first. Are you really sure you want to install plugins right now? You haven't gotten down the basics yet. If you want to learn how, :help plugin
for starters.
:help tabstop
:help softtabstop
:help expandtab
:help :list
:help listchars
Todo.txt format. No plugin needed. It's not specific to Vim, all you need is a text editor. If you want a bit of convenience, there is a todo.txt plugin, but you'll have to understand how to use the Todo.txt format first (it's easy!).
vim .
to open whole directory
:help :edit_f
:help :find
As you will soon see, :help
has everything! It can explain anything Vim-related better than anyone else ever will. Go through it, it's one of the best pieces of documentation for any program ever written. Start with :help
, the topics will be laid out one by one.
The MacVim author has long been opposed to any icon redesign that differs too much from the official one.
This looks like a clear improvement without straying too far from the original. I hope it gets accepted [fingers crossed]. Good luck!
Eternal liberation from the point-and-click mindset enforced during the last 20+ years of WYSIWYG Desktop Metaphor Computing.
You can be completely functional editing files remotely (if that's your bag) over seriously bandwidth-constrained links (satellite, IrDA, dialup).
No GUI is required (or really offers that much over the console, tbh)
Composability and the opportunity to define and repeat common operations in a way no graphical text editor for the desktop built using web technologies can approach.
Vim doesn't cost anything.
Check this out: https://www.slant.co/versus/42/40/~vim_vs_sublime-text
As always I would recommend trying the built-in features first and add plugins where you find the built-in solutions don't work for you:
Completion: Vim has advanced built-in solutions for inserting and completing text. See :h completion
or :h usr_24.txt
.
Code navigation/tag completion: ctags has built-in support for jump-to-definition and tag completion. See :h tagsrch.txt
.
Debugging/syntax checking: I would first try debugging with the built-in quickfix window as described here. For more info :h makeprg
, :h quickfix
and :h errorformat
.
The keywordprg option might also be interesting for you, it basically enables you to open documentation to any keyword from within vim. See :h keywordprg
.
If you like this you will love ag, the silver searcher. There is also a vim plugin. I bind <leader>t
to :Ag \(todo\|TODO\)
EDIT : the correct config in vimrc is nnoremap <leader>t :Ag '(todo\|TODO)'<CR>
, the line above is misleading.
See this talk by u/justinmk here. It explains why they're not deprecating anything just yet.
To summarize, old code isn't bad code. It's code that worked at one point, and is therefore valuable. Granted, old code isn't necessarily designed the best way possible, so we need to move away from it in some cases, but you should generally try to modernize what already exists instead of reinventing the wheel.
That's what Neovim did; it claims to have the most advanced VimScript engine in the world, featuring an AST-producing parser.
Neovim's goal isn't to deprecate old interfaces, which necessitates a trade-off between forward-progress and backward-compatibility. The goal is to modernize the existing codebase, i.e. with libraries like libuv, and make it possible to have more features.
Actually, thank you sir, this is that exact type of feedback I was looking for! Thanks for really reading carefully and walking through the book.
As for to the critic, it's quite straightforward, but I don't see any rudeness.
Clearly the book is more like a pure idea now, there is a long way to go (and I'm clearly settled to walk the walk). I always keep in mind the Pixar movies that are absolute crap at the beginning (according to https://www.amazon.com/Creativity-Inc-Overcoming-Unseen-Inspiration/dp/0812993012) and have to walk through multiple sometimes painful transformations until they finally become the masterpieces they are.
I also have to say, that I need to keep my audience in mind. If I wanted to be pedantic I could just as well print out the :help manual. What I want instead is to create something pragmatic and practical, lite and simple, something people outside of the Vim community could grasp and be productive.
The idea is get more people familiar with Vim, so that they can then go deeper after that, maybe join the /r/vim/ and learn from people like you ;)
Anyway, thanks again for the fantastic feedback!
I actually got to know Vim only after, and due to learning touch typing. The road of looking for ways to improve my productivity led me there. Thinking of it now, Vim seems awfully hard without touch typing.
Try out keybr, it's quit helpful (got me to 80 WPM over time).
I haven‘t had any luck getting a smooth performance (especially scrolling) with this combination. Using Neovim made it feel a bit better, but what really made a difference was switching to Alacritty.
> then you just add a line saying: > > Signed-off-by: Random J Developer <>
> using your real name (sorry, no pseudonyms or anonymous contributions.)
> So. I go to high school and people still think it's a good idea to teach people Pascal even though there's stuff like python, or, anything.
Pascal is one of the best languages to learn structured programming, FWIW.
Also, try http://freepascal.org/ -- there might be a portable version.
EDIT: Someone else already mentioned Lazarus, which can be installed on a USB drive according to the docs at http://wiki.freepascal.org/Installing_Lazarus#Installing_Lazarus_under_Windows.
If you're wondering "why github", read the Google Code shuts down thread. I think someone is also maintaining a bitbucket mirror.
Vim just came in as the 4th most used editor in the Stackoverflow developer survey, so it's definitely widely used in the industry.
I spend my entire day with MacOS, iTerm full screened with tmux + vim. I wouldn't have it any other way.
A few time in my career as a software/web developer management have tried to enforce developer setups such as netbeans or Sublime. In theory it makes sense to have everyone on the same tool for paired programming, but I personally cannot live without vim.
Now I'm in management I make sure everyone's using tool's they're comfortable with so they're as productive as possible.
Yes, and fzf works beautifully inside it. That means Neovim can have extremely performant fuzzy-search across very large file trees.
For comparison, try fzf in emacs ansi-term (don't bother with eshell).
I would go with http://todotxt.com/
It is just plaintext. You can write a vim syntaxfile for it and bind some keys to mark tasks as done or add/change the priority of a task.
There is a simple shellscript for it, that allows to filter your tasks by project, priority etc. and there are apps for various platforms (ios, android, win...).
Edit: There are syntax files for vim and even some keybindings for the todotxt format already available here https://github.com/freitass/todo.txt-vim
I recently converted from Pathogen to Vundle as a plugin/package manager as Vundle also includes the ability to update and install plugins. You can also do this by combining Pathogen and git submodules, but I found adding/removing plugins to be easier with Vundle than with manually managing submodules.
Vundle also uses this repository by default when you don't specify a specific github user's repo, so if you're going to use it, you might as well try out Vundle.
It turns out that xterm
is pretty complicated. The guys who wrote <code>st</code> were inspired to do so because of this. They say:
> [xterm] has over 65K lines of code and emulates obscure and obsolete terminals you will never need. The popular alternative, rxvt has only 32K lines of code. This is just too much for something as simple as a terminal emulator; it’s yet another example of code complexity.
In contrast, st
is about 5000 lines of code.
If you’re familiar with markdown and RST give pandoc a try. It is a nifty many-to-many document coverter that abstracts away a lot of the clumsy markup in LaTeX, but it’s still fully featured and e.g. extends markdown to allow including floated figures, tables, etc.
we cover this a little bit in our FAQ: "Nyxt differs fundamentally in its philosophy- rather than exposing a set of parameters for customization, Nyxt allows you to customize all functionality. Every single class, method, and function is overwritable and reconfigurable. You'll find that you are able to engineer Nyxt's behavior to suit almost any workflow."
please see more here: https://nyxt.atlas.engineer/faq
I am not sure that means the items at the top will be implemented any time soon...see the list as of 2009 for instance:
https://web.archive.org/web/20090706103200/http://www.vim.org/sponsor/vote_results.php
I don't understand why someone would switch from zsh to fish unless they found zsh too confusing. Fish lives up to it's name.. it's a friendly shell. Fairly simple and has a few nice features (syntax highlighting, history substring search, auto-suggestions, etc. all of which zsh has plugins for). It's not POSIX compliant and doesn't like having configuration options.
See this ("Configurability is the root of all evil"). One of the most ridiculous things I've read lately.
"Every configuration option in a program is a place where the program is too stupid to figure out for itself what the user really wants, and should be considered a failiure of both the program and the programmer who implemented it." Vim (well, essentially most all software according to this guy) is basically a terrible program for not presuming to know what the user wants. Not being able to set your history size is a feature!
That's true but doesn't really change what I said. Most extensions to those sites/tools, if they exist, have a dark mode for people who experience eye strain. There's also programs like f.lux to change the overall color tone of the screen.
The statusline requires a custom font to work (lokaltog-12* in https://github.com/Lokaltog/sync/tree/master/fonts/bdf). It will probably also trigger a couple of errors if you don't have Fugitive, Syntastic and current-func-info installed. Try to comment out line 134, 137 and 143 and make sure that you have the font installed.
I think fzf is pretty good for the job.
You can do git status | fzf
and fuzzy search what you are looking for. But if this is a common use case you can do git ls-files -m | fzf
to eliminate the noise in git status.
It doesn't need an installation. Just download and install it to another dir in your path. It should be fine since you are not "installing" it. Especially since you are on windows, you can just download a portable exe of the software you wish to use.
EDIT: It is possible that your Cyber team may have not even considered vim. Try and ask if they can take a look. It is not on the "approved list" doesn't mean it can't get on it, right?
The :find
command is pretty great for file navigation too, and I feel like it's very underrated.
You can bind something to :find *
and then type a letter or two of the file name you want, and hit Tab. Vim will expand and select the file name, and you can open it with the Enter key.
Here's a demo: https://asciinema.org/a/80ny37t1e9yfgsddp1d904bzf
You don't really need a fuzzy finder if you master :find
, although I can understand why people use fuzzy finders. I'm a fan of both :find
and ctrlp, but I've been leaning towards :find
these past couple of months and I like it better so far. Heck, I've been using it for work, and :find
has performed better for me under a 1GB repository, certainly more faster than ctrlp, but more importantly, it's more accurate on the first match.
Indeed, most of the time, :find
is even faster than fuzzy finders because the fuzzy matching algorithms they use (ctrlp's algorithm is especially poor) are just not that accurate.
EDIT: You're right, sourceforge has some bad habits. Here is the newly created repository for JSVim : https://github.com/smigniot/jsvim
Original comment
I did not ask for help for a long time. Would sourceforge suit you ? JSVim was FOSS long before github even existed.
I do not care about ownership and welcome people willing to "start helping". Why do you claim the "custom HTML files for a roadmap" is "zero roadmaps" ?
You're right, that does seem like a bug. It turns out it's a vi-compatible exception: https://groups.google.com/forum/#!topic/vim_use/iLZJm7ywh40
But that's annoying because it would be useful to have both behaviors available instead of two different ways to do the same thing.
caw
is a workaround, but obviously not the same if you are in the middle of a word.
It's a known bug. I bet the theme has cterm=234 or something near that value?
https://groups.google.com/d/msg/vim_dev/afPqwAFNdrU/nqh6tOM87QUJ
I discovered it the hard way myself, and sent this workaround to molokai:
https://github.com/tomasr/molokai/pull/26
But the maintainer is too busy to give a shit.
Still early days [for me! not the plugins], but i use pandoc with:
NeoBundle 'vim-pandoc/vim-pandoc' NeoBundle 'vim-pandoc/vim-pandoc-syntax' NeoBundle 'vim-pandoc/vim-pandoc-after'
Pandoc uses an extended markdown format which goes very well with LaTeX or HTML:
http://johnmacfarlane.net/pandoc/demo/example9/pandocs-markdown.html
You don't need the Ag plugin.
In your vimrc, set this option let &grepprg = 'ag --nogroup --nocolor'
to use https://github.com/ggreer/the_silver_searcher#installing for grepping. Then you can do :grep 'your string'
and then :copen
to see the results list.
It's the difference between supporting VI-keys and supporting vim-script (EVERYTHING that vim supports, and keystroke compatible with how vim behaves).
For a simple example, vim supports :syntax on
, whereas your standard HTML text-area that might not be appropriate. That might be awesome, but it might not be appropriate.
As another example, bash supports "set -o vi", but doesn't support :nmap
or vimscript within your command line.
A "lib-vim" or vim-style drop-in component for textareas (like this: http://www.gtk.org/tutorial1.2/gtk_tut-14.html ) that supported vi-key editing would be a very worthy thing to have. But that is not VIM
--Robert
Remapping keys is normal, but you really can't configure the modes out of vim. If you want to do things like select and copy text from insert mode, then you want a different editor. It is theoretically possible to force vim to do things in ways it really isn't supposed to do them, but if that is your plan then there is no reason to use vim. I recommend instead something like micro which is a decent command line editor which is probably much closer to what you are used to.
Vim is much more powerful than micro, but in order to access that power you have to be willing to learn it.
check out the tagbar plugin which has extensions for various statusbar plugins
also https://www.vim.org/scripts/script.php?script_id=610
https://www.reddit.com/r/vim/comments/d8z7r/a_way_to_display_the_current_function_in_the/
VimOutliner is by far the best note taking and organizing solution I've ever come across --- and I've spent some time looking. I use it for real-time note taking, general note keeping, collecting of research notes, outlining papers, etc.
See https://github.com/vimoutliner/vimoutliner. (The main website is currently out of order, so get it from github. Also, the mailing list is very responsive.)
One thing that satisfies a small part of your 'problem': I have a Firefox plugin called It's All Text that allows you to open up some input boxes in the text editor of your choice! Eligible text boxes are marked with a little "edit" tab. Clicking on the tab, or pressing a user defined keyboard shortcut will open up a blank buffer. Saving and closing the editor will write the contents to the text box.
I don't think there's a Chrome equivalent (relevant stack exchange post), but feel free to correct me. Also, I know this only kind of addresses the topic of the post, but boy is it useful!
Those settings have nothing to do with how Vim does filtering through an external program. See :h tempfile and :h 'shelltemp'. You can also run vim with that plugin under strace and see exactly what happens.
That said, it's questionable how concerned a user should really be about this. Some systems have /tmp on a RAM disk, which probably makes any type of off-line recovery of the data impractical. Honestly, the thousands of additional lines of plugin code that Vim is probably executing every time it runs may be a bigger concern. Would you know if one of your other plugins cached the plaintext data somewhere?
I wrote a somewhat simpler (and less featureful) gpg plugin to try to address these two concerns. It uses noshelltemp and checks for the filterpipe feature that allows using pipes instead of temp files. It also comes with a vimrc file that prevents loading plugins, but can be customized to selectively load plugins the user feels are safe.
fzf dominates this use case, in my opinion. Nice to see more options out there, though a python dependency is just as annoying as a ruby dependency.
Still looking for something more cross-platform like the_platinum_searcher.
It is free software according to the FSF: https://directory.fsf.org/wiki/Vim
This page is an official statement from the FSF saying vim is indeed free-software.
It is also free-software according to debian:
https://packages.debian.org/jessie/vim
These are the two good sources on what's free or not, and if they agree, there's no doubt about it.
I was using wmii before I switched to a mac. I thought it could improve but it was much more decent than mac osx. Now I can't go back because I like using the touchpad of my macbook, although it gives me arm pains. Overall, it was a big mistake to switch to a mac...
I try not to. The servers I need to SSH into usually have a tmux session running or if not, I want one to be immediately started, so that I could pick up my work where I left off (join back to watch some lengthy process, manage my torrents, etc.).
If I were to use a host tmux split and SSH into my server in a split then I would end up <C-b><C-b>
ing constantly and also would lose track of where I am logged in to which servers.
Instead of that, I use a tiled window manager (bspwm) and instead of a new host tmux split I create a new split on my desktop to spawn another terminal, and have the remote tmux running there.
Ew sounds clumsy, huh? No.
Let's say I use a server to run my irc client (which I did).
.bashrc
: alias irc="ssh irc.kmarc.me -t 'tmux attach -t kmarc || tmux new -s kmarc'"
- with this alias, I just need to type in irc
and I'll be brought to my session automaticallysuper + space; i
urxvtcd -ls -e bash -ci 'irc'
- with this hotkey combo, I need press Win button and space (like in MacOS's spotlight) and then immediately key i
and a new window will be created.If I need to ssh ad hoc, I'll press Win+Enter to spawn a new terminal.
I have my dotfiles on github, probably I should polish them and have a blogspot about how to configure this kind of tiled-window tiled-terminal workflow :-)
Just a correction, as u/grumpycrash pointed out, this is actually a kitty feature:
https://sw.kovidgoyal.net/kitty/kittens/unicode-input.html
My bad. I just switched to Linux recently, and all these terminal goodness is so new to me 🙇♂️️
It depends on your OS, and your terminal configuration. E.g. in iTerm2 you need to set "meta sends ESC". https://www.iterm2.com/faq.html
alt (AKA meta) mappings are a complete non-issue in Nvim, they work by default and require no extra configuration in your vimrc. Just use <A-
prefix in your mappings.
nnoremap <A-f> :echom "pressed alt-f"<CR>
Why don't you use a BibTeX manager, like JabRef, instead of coding your bib file by hand? In addition to not having to worry about missing commas, etc., JabRef takes care of telling you which fields are required, optional, etc.
Also, for your \emph
command, I'd suggest this instead:
nnoremap <leader>em ciw\emph{^R^O"} vnoremap <leader>em c\emph{^R^O"}
where ^R
and ^O
are literals, which you can insert by typing <C-v><C-r>
and <C-v><C-o>
, respectively. See :h i_CTRL-V
and :h i_CTRL-R_CTRL-O
.
Also, you could use cw
(or caw
) instead of ciw
, that way your macro can take a count number, e.g. 3<leader>em
. And you might want to have another version <leader>EM
(or whatever) that uses W
instead of w
, to deal with words like don't.
Ah, Ag is significantly faster, that's probably why I'm not experiencing it.. I don't even have caching enabled when using it:
https://github.com/ggreer/the_silver_searcher
and then:
let g:ctrlp_user_command = 'ag %s -l --nocolor -g ""'
If you're using git or mercurial it will automatically exclude items included in your ignore lists.
There's just so much in vim that isn't in vi. Have you ever actually tried the original vi, not just vim in 'compatible'? You can grab the source here and give it a go: http://ex-vi.sourceforge.net/. I had to change the Makefile and point the TERMLIB to ncurses to make it work in Ubuntu.
Just the top of my list of things that are missing that I couldn't live without:
If you liked the extensive bullshit on the solarized page you will love this post by the author on metafilter.
Did you try Apprentice?
I have one long-lived instance per project and many short-lived instances for quick edits.
Of note:
What you're doing is a very uncommon method of indentation. To achieve this, you'll need to write your own 'indentexpr'. I don't recommend that.
Instead, you could keep the comment leaders aligned and indent your comment text instead:
/////////////// // Section A // /////////////// // blah blah blah // blah blah blah
Then you can write a 'foldexpr' that will recognize this comment indentation and fold based on it.
Here are some examples: http://superuser.com/questions/560167/how-can-i-write-a-vim-foldexpr-which-is-equivalent-to-foldmethod-indent
https://github.com/idbrii/vim-ficklefold/blob/master/autoload/ficklefold.vim#L25-L29
There's probably useful tips for writing foldexpr somewhere...
Yes - your .vim directory can be versioned, but you could just create bundles repository in that dir, and add submodules there - I haven't tried that but it should work.
Here's my .vim dir - you can see submodules in bundle
subdir.
However I've added Snipmate's snippets dir in the root of .vim (that's how Snipmate detects them by default).
Example flow would be:
cd .vim git submodule add https://github.com/vim-ruby/vim-ruby.git bundle/vim-ruby git submodule init git submodule update git submodule foreach git pull origin master
Once that's done, you only repeat last two commands to update your plugins etc.
Without more specific details about what you changed and exactly what git commands you've run, it's impossible to say.
Generally speaking, though, git "history" is just commits. If you didn't run git commit
git won't "save" changes to anything. It sounds like you might be expecting git to track changes as you modify the file, but that's pure speculation.
Furthermore:
> Git's reset, checkout and I assume other commands removes the files` history
Not really, no. History is more or less indelible. If you've committed a change, it's in the history permanently. These commands can move the current state ( contents, roughly ) of your git repository to a previously committed state.
The core idea of git is that all committed changes from the beginning of time are available, if needed or desired. You have to go out of your way to modify the commit history. This is a very good resource for learning git's internals and the mental model you need in order to understand it.
They didn't advise against Linux in favor of Windows. They advised against using this particular distribution (Should I Use Kali Linux?).
I end up using 8-space tabs quite a bit to match the Linux Kernel coding style guide (which is used by a couple of the codebases I work with), and I'm quite swayed by its reasoning:
> The whole idea behind indentation is to clearly define where a block of control starts and ends. [...] > > Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you’re screwed anyway, and should fix your program. > > In short, 8-char indents make things easier to read, and have the added benefit of warning you when you’re nesting your functions too deep. Heed that warning.
(Edit: though given the choice I normally go for 4-space tabs, as I'm not always that on top of my indent levels :-))
It can, but Java heavily relies on IDE support. You can write in Java in vim, but that would involve a lot of re-implementing of the things that are already implemented in IDEs.
You just won't be more productive with Java in Vim than in an IDE with vim mode plugin.
If you want to do it anyway, you can read this, for example: https://stackoverflow.com/questions/253170/tips-for-using-vim-as-a-java-ide
I guess an alternative is to use fzf instead of Tab for completion -- it will pick an actual file. That would fix the root problem of tab completion not working how you want.
A low-tech solution is to use *
: vim mo*
would open all the name matches and you could :n
to switch between them.
The .gitignore file in the project folder is supposed to be common and public. Your own patterns are to go in .git/info/exclude. The public .gitignore normally contains patterns to exclude build results (executables, object files, etc.), which are useful for everyone.
More info here:
https://git-scm.com/docs/gitignore
Edit: I just realized that you're probably advocating exactly what I've described, and you're wondering how to get others to respect that. That I can't really help you with. The only suggestion I have is to delete personal stuff from .gitignore and personally tell them to put in .git/info/exclude. Also to google private project config for other stuff.
I'm sorry, Your Highness. I will be better.
Here is the solution to your replacement question, without a single reference to the help which you could have used to discover a solution all by Thine Self.
Useful article. However, a few suggestions:
* There are some typos
* serie
-> series
* Vim macros an often,
-> Vim macros, an often
* answer to the later
-> answer to the latter
* with few keystroke
-> with few keystrokes
* but I you might yet disagree on it
-> but you and I may disagree on it
* many use
-> many uses
* markdeown link list
-> markdown link list
* Code blocks & inline code is highly recommended for posts with keyboard commands. Check out Format text article my medium and look for "Code blocks & inline code". Just to illustrate: There's a difference between saying " press ‘q’ " and " press q
". You would want your readers to type in just the letter q
and not with single quotes.
* Could be just me but the font size in your GIF is small. It's hard to see the text and the operations. I would suggest increasing the font size and recording the GIF or using something like asciinema
Good job with the intro article. I'm sure it may help a lot of vim users with usage of macros.
Starting from a list of the days, ^<C-v>GI0 => "<Esc>
to insert the leading part, <C-v>G$A",
to insert the trailing part, ^<C-v>Gg<C-a>
to increment the numbers.
Add in the first and last lines, then finally >i)
to indent.
I use KeePassX, which provides a keybound function that types out your username + <Tab> + password + <Enter> (or whatever template you specify). It works seamlessly with qutebrowser (any program, really). Example: I go to www.reddit.com, focus the username field, press <Ctrl-k>, and boom - done. It works by checking the title string of the window.
I really like the separation of password management from browser, given that I enter passwords in places other than my browser all the time (ssh logins, mutt encryption/decryption, chat clients, and so on).
Also, there are several mobile apps available. I use KeePassDroid.
VimFx deserves more love: https://addons.mozilla.org/en-US/firefox/addon/vimfx/ I went from Pentadactyl to VimFx and have never considered switching back. VimFx is lightweight, doesn't change the UI and provides enough functionality.
Now that I'm on a computer: looks like there's Text Editor Anywhere if you're on Windows that does it for Chrome and pretty much anything else, which is pretty neat. For other OSes, TextAid will do it in Chrome. Because of the security setup in Chrome, you have to run a small webserver for it to communicate through, but I've used it or a similar thing in the past, and it's pretty slick.
> Vi is not open source
As for vi
being a symlink to vim
, that's not always true. On my Arch Linux laptop, :ver
gives:
> Version 4.0 (gritter) 3/25/05
And you don't need to install gvim if you're just going to be using it in the terminal.
No, <code>get()</code> and <code>sendfile()</code> are not "nodejs functions"; they are only methods provided by the Express framework.
Therefore, there's no reason whatsoever to expect them to be treated like Built-in Nodejs functions.
Nope. Never heard of it until now. And I went back and looked at my copy of vimtutor to see if it was there, and I didn't see it. That is good to know about.
Honestly, though, at this point, I'm trying to make it a habit of simply doing "h:{{WhatDDGShowedMe}}" inside of Vim. Dash on macOS also has a copy of the Vim docs and I have been searching in there more often. It feels more natural (for lack of a better term) to me than :h. I know I need to get better at using :h, and I think these steps are helping.
The main differences between vim and neovim can be found here.
With the plugins I use, there's really no reason I couldn't just use vim now that nvim-completion-manager and ale both work on vim8.
That being said, neovim has the inccommand
option which is simply awesome. It will show you substitutions in real time in the buffer as you're typing out your regex. I only learned about this feature the other day, but it's incredibly useful.
I recommend running Emacs as a server / Daemon. Basically then you keep emacs initialized and ready to go in the background, so when you call
emacsclient
or something similar, it'll 'start' very fast. The biggest reason emacssen tend to start slow is because they're usually parsing an extensive init.el (as you get further into emacs, it'll just keep growing and growing). Running it as a deamon / server will ensure you're not reinitializing emacs every time, and thus skip that delay.
It also has the advantage of sharing command history between buffers. See here for more information.
Alternatively, and less recommended, you can compile your .el files. This can result in errors and make debugging them more difficult, but it can also speed up your emacs instance.
There is tetris.vim which is written in pure vimscript.
There is also vim-golf. That is not exactly a game in vim, but it is pretty close.
Honestly, I gave up on "smart" plugin systems and just use pathogen now: https://www.vim.org/scripts/script.php?script_id=2332
aka, "do what you need to do to get something in ~/.vim/bundle" -- usually git clone
.
You could probably take inspiration from https://www.vim.org/scripts/script.php?script_id=302 for interpreting escape sequences.
Or you could write a couple of syntax patterns like this.
(edit: added a quick example)
How about a slightly improved version that doesn't use a temporary file and makes the buffer a scratch buffer?
function! Tree() 35vnew setlocal nobuflisted buftype=nofile bufhidden=wipe noswapfile call setline(1, split(system('tree -Fa -I ".git"'), "\n")) endfunction
(edit: added an alternative version)
I've never understood why people insist on writing their own dot-file installation scripts when the venerable and powerful GNU Stow exists.
Edit: Also, I'd avoid having a full, generic .gitconfig in your repo. 1) There's security considerations, 2) The more systems you work on, the more you'll realize you need different settings for each boxen. I'd suggest splitting things out into git include files. See this.
You could give this clang-based auto-completion plugin a try. If you also want experimental tag-less clang-based jump-to-definition, try my fork of the above.
Here's the thread in vim_dev mailing group where ZyX proposed the patch: https://groups.google.com/forum/?fromgroups#!searchin/vim_dev/24bit/vim_dev/ed0GTyYrSYg/KMALGwbAAGAJ
Bram added this to the vim TODO. For anyone interested you can do :h todo
and then search for "Patch to add GUI colors to the terminal".
But man, that todo list is long.
Perhaps you mean the following issue discussed between Ben Fritz and me on the vim_use mail list two days ago:
Is there, perhaps via a Plugin, a way to recover the second last text editing operation in normal mode ? The dot '.' operator keeps only the last operation.
... Let's say I search for "Loch Ness", have a couple of matches, and replace the first match by "Love Nest" by placing my cursor on v
and typing ceve<esc>ert
. Then on the next match, I cannot repeat this operation by placing my cursor on v
and hitting .
because this is rt
.
It would be nice go back and forth between the last edit operations by <c-p>/<c-n> say right after hitting the dot operator ...
See https://groups.google.com/forum/#!topic/vim_use/CZ8KYt1i9BM