I'm using NeoVIM, and I set up it to show folds automatically. The trouble is that when there is more than one level of folds, it's going to show numbers at the left.
Is there any way to remove them, just look like any other modern editors?
I searched on google, StackOverflow, and checked the vimhelp page. I haven't seen a way for this.
I'm sure that's the default behavior, I can reproduce it on the default vim of codesandbox and without any plugin. Please check this link https://codesandbox.io/s/wizardly-tereshkova-vwh5im?file=/README.md. Here is the screenshot.
As explained in :help fold-foldcolumn, when the value of :help 'foldcolumn is large enough, the fold level is indicated by vertical bars but, when there is not enough room, numbers are used instead. That behavior is not governed by any option so there is nothing you can do about it except rolling up your sleeves and modifying the source code.
That said, the ˇs in your screenshot are clearly not standard `:help 'fillchars', as hinted in the comments, so you should probably take a look at what is redefining those before taking any action.
Related
This problem really hit a nerve with me. I have both YouCompleteMe and UltiSnips installed on my vim 8.0 editor. It seems that both of these plugins use the tab key for doing the auto-completion and that has created an incompatibility that has been also addressed by this question. My question is more specific, though. When I write a piece of code like <html, there is a pop-up menu that shows me all related snippets for that code.
I use the tab key to navigate through that menu but when I hit ctrl+y to accept and therefore expand one of these snippets, nothing happens! I think this structure suggests that it's possible to somehow choose one of those snippets from the menu without trying to define a shortcut for UltiSnip. What am I doing wrong? How should I navigate and choose those snippets?
I also would not want to stuff my vim with any new plugins (like supertab, etc.).
The solution was actually a lot simpler than I expected. In the beginning, I felt stupid for not knowing it but when I find a similar question like this one, I thought that probably many were fallen into the same trap.
I don't know whether to name it a bug or not but it's how Ultisnips and YouCompleteMe work together. In order to expand a snippet, you have to write the initializer exactly as it's defined. Of course, this seems obvious, but when you see a pop-up menu of different snippets, you might think they can be chosen but it only works if you already wrote the snippet initializer exactly as it's defined.
So when a snippet is called "html5"---as it's shown in my question---writing an extra opening bracket (<) will cause it to stop working. It cannot be expanded.
Also, don't forget to check out Siegfried Gevatter configuration. It's not possible to use tab key both for navigating into the pop-up menu and expanding the snippets.
P.S. It was nice if navigating through the pop-up menu could change the whole word (including the angle bracket), not just what succeeds it. This feature works this way in most of the other editors I see and that's probably why I wasn't able to spot the problem in the beginning.
I use https://github.com/nsf/gocode in conjunction with https://github.com/Shougo/neocomplete.vim for my Go autocompletion.
It works really well, except for one little thing. When I type something like
fmt.pri
I get autocomplete option like so:
fmt.Println(a ...interface{}) (n int, err error)
Since I'm new to Go, this is super helpful, because now I know what arguments the method takes, what are the types, and also what does it return.
Unfortunately, as soon as I write past bracket, the information is gone.
fmt.Println(
So on more complex methods that I'm using for first time, I'm stuck, and have to jump to source definition, or run godoc.
It would be much easier to have that information available somewhere, preferably on the bottom of Vim where the command/status line is.
Does anyone know how such a thing could be achieved?
Preview window breaks my Vim so it's not an option.
I use autocomplpop (well, my fork of it) and it has a feature where it does a small split window with the completion text in it that sticks around. It does this when you set...
let g:acp_completeoptPreview = 1
I'm sure neocomplcache has a similar feature. Glancing through its documentation it discusses a preview window in several places. Search for preview in its docs and see what you can find.
This is ultimately controlled by 'completeopt' containing 'preview' (:h completeopt). The auto-completing packages often set these values as part of their functionality, which is why with autocomplpop you need to use its option to control it instead of just doing 'completeopt+=preview'.
Let me explain what I'm looking for, hopefully for the terminal, but if it exists in an IDE, i'll take that too.
I have a laptop with a 1366x768 resolution screen; I use vim for code-writing, and I use a fairly small font in my terminal (~7pt). So, as you might imagine, there's a lot of "wasted" horizontal space, especially when coding in a compact language like python.
I just checked and found that with a 6pt. font, the maxyx of my terminal is 82 rows x 271 columns. What I'd like to have, essentially, is a single terminal with the dimensions of 246 rows x 90(89?) cols, split into 3 panes and displayed side by side. But, they would need to behave as one contiguous vertical pane, i.e., when i scroll in my editor, all three of them scroll synchronously.
Does anyone know of a hack or anything to accomplish this? Maybe for vim/screen/similar?
Patching screen might be a fun project, but I don't have time to chase that rabbit. If someone out there does, though, I'll order them a pizza or something ;)
(although if i get around to it first, i'll have to order myself a pizza)
I had the very same desire and others want this as well. Lacking any options I implemented my own two column virtual terminal. See the --columns option for selecting a different number of columns than two.
EDIT: based on comments, I now understand the requirement better. i.e. viewing one text file in a newspaper-like multi-column format.
It seems more like an editor feature rather than a multiplexer feature (because the 2 editors should be linked). Thanks to #romainl for mentioning :set scrollbind. This seems capable of doing the job in combination with some additional vim magic.
Here's an superuser q&a showing how to use scrollbind for your purposes: https://superuser.com/questions/243931/how-do-i-maintain-vertical-splits-with-scrollbind-in-vim .
Original answer:
vim and [recently] screen both offer vertical-split, as does tmux.
I don't know about any way to scroll simultaneously, but tmux's 'synchronize-panes' does offer simultaneous input. Can be useful!
For vim, use :vsplit
For screen (recent versions), use C-a |
Alternative to screen, I use tmux. It offers (default keys)
C-b %, then you can use C-b :setw synchronize-panes for
simultaneous input across panes.
Hope this helps.
I'm using vimwiki, that allows you to write links like [[wiki link ...|name link]].
If you're in edit mode and in a line with a link, then you see the real file content, otherwise you just see "name link". (In a similar fashion to the vim help |links|).
But vim, to calculate the wrap, uses the real content and not the displayed content.
I would like for vim to use the displayed characters to calculate the wrap.
vimwiki uses the relatively new conceal feature to hide parts of the link, like the Vim help does with its markup. The illusion of hidden text isn't very deep, though, and Vim commands as well as the line wrapping still operate on the full text. The core Vim implementation would need to be extended to get what you want; someone needs to write a patch (and corresponding tests).
However, it's unclear how far this should be taken. After all, Vim is a text editor, not WYSIWYG. The conceal feature is a nice convenience and optical trick, not a core feature.
Instead of using conceal feature you can manage state of the actual content which is eventually written on the disk. As you can see this is a complicated approach and ridden with edge cases which risk data loss. A web equivalent of this would be rich text editors which are notoriously hard to get right.
I'm trying figure out how far I can go in fine-tuning the appearance of my Vim GUI. I'm using MacVim 7.3 and what I'd like to do is change the padding, text-alignment and border color of the line numbers.
I know there are some standard configuration parameters in the highlight command, particularly the gui group, but what if I want something beyond what's offered there? For example, a right border as opposed to underline. Is this possible?
It could be that it's simply not worth the trouble, but I'd like to at least know what the initial steps would be so I can make the call. (Even if it's just :help adding-border-to-line-numbers and I happened to miss it).
Thanks.
No, unless you intend to go into vim's source and hack it from there, changing line numbers appearance beyond what highlighting offers is not possible.
However, I do remember a few patches that dealt with something of a kind, so you might want to check the archives. You will still need to recompile vim doing that (if you manage to find a patch that does that).