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).
Related
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.
This has been bugging me for a while now. Why is it that I have to define colors for the floating/popup (you name it) menu by myself in (Neo)Vim, when there are all these beautiful color schemes.
I have to put a lot of time and effort into defining somewhat readable (not that pink hell) menus, which eventually might or might not match the underlying color scheme, but won't match anymore, once I decide to change the scheme.
Is there something I am missing?
Neovim inherits its built-in colorschemes from Vim.
Vim's built-in colorschemes are all very old, often predating the completion menu feature, and pretty much unmaintained. They lack many things beyond the completion menu and they are generally in a bad shape.
I started an initiative to modernise the built-in colorschemes but it will take time. If you feel like giving us a hand…
FWIW, Pmenu and PmenuThumb are built-in highlight groups so it is legitimate to expect them to be handled by the built-in colorschemes but CocInfoFloat is not so it is entirely the responsibility of the third-party plugin that defines it to, ideally, link it to a built-in highlight group.
FWIW2, thid-party colorschemes that don't handle 100% of the built-in highlight groups should be considered broken.
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.