Is there any standard way to specify the set of characters that vim uses to enumerate lines? For example, instead of numbers in succession, could I use lower-case letters {a, b, ..., aa, ab, ac, ...} (or even better, use only the characters in a keyboard's home row) and still act on specific lines by this new referencing system?
I suppose an escape key of sorts -- perhaps ':' or 'g' -- might be needed, but even so, if anyone has suggestions as to how I could implement this, I'd be quite appreciative.
Thanks.
There's nothing built-in other than absolute and relative line numbers, and it would be difficult to square a different addressing scheme with the numerical [count] prefixes to the Vim motions. However, plugins like EasyMotion and vim-seek implement such, though for motions like the built-in f inside a line.
For implementation tips, have a look at the RltvNmbr.vim plugin; it uses the sign column to emulate the now built-in relative numbering. As the sign column is two characters wide (and can display arbitrary characters), this would be fitting. That would take care of the visualization... you'd then only need a custom mapping to query for the Base26 line number, and translate that back into a jump.
Related
Vim provides a nice way to work on text objects, eg. I can type ciw and I will be changing the whole word no matter where in it my cursor is actually positioned.
Is there something similar for signed numbers? Ie. both positive and negative? Positive numbers are a word anyway, so I can use iw but what if they start with a minus? Ideally I want to have something that can be later repeated (with .) on other numbers in the file, no matter if they are positive or negative.
Concrete example:
Change -100 to 20.
w in Vim means "word", and "word" is a collection of letters from :h 'iskeyword' buffer local option. Hence an exact interpretation of w or iw depends on current option setting. There's no built-in "text objects" for every situation (although some plugins may provide them). There are only "word" and "WORD" (i.e. anything except spaces).
So your options are:
Use ciW if appropriate (number is surrounded by spaces)
Change iskeyword to include "minus" (it will influence many(!) other commands)
Find an existing plugin or write some custom stuff yourself using :h Operator-pending-mode
Use :h ctrl-a. E.g. 120 Ctrl-A will turn "-100" to "20"
Imagine you need to change a few last letters in a word.
From
.. visualizing a graph?_
(_ denotes where the cursor is, mode:normal)
you need to arrive at
.. visualize| a graph?
(| denotes the cursor, mode:insert)
How would you do this?
(please suggest how would you really do this, not the "super-doper" way nobody uses)
I am asking, because I do this insanely inefficiently:
type b until reach _visualizing a graph?,
followed by e (visualizinG a graph?),
followed by x to remove g under cursor,
followed by few Shift+x to remove what is before the cursor,
and, finally, i switch into the insert mode and type e.
With given example, I would do:
Tzcwe
If there are just a few words between the cursor and where I want to go, I will use CTRL+left as many times as needed plus CTRL+right once and <bs> 3 times. I may also use the mouse. It's not that different from what you use, except I don't leave the insert mode for simple moves. Note this is exactly what I use when I type messages in my browser (I've never been conquered by vimperator & co).
I'm aware of <esc>gegege...3<left>cwe<esc>. But that's definitively not my first choice.
I may use T and F on symbols with few occurrences, but I seldom use them on letters as I'll spend more time detecting the best character to use than using CTRL+cursor as many times as needed. Beside, when I'm correcting what I've typed, it's likely that my mind is in "reread+correct/refactor sentences" mode, speed typing is not my priority.
It appears, surprisingly, that more self-selected SO devs prefer to indent via tabs rather than spaces. Some people brought up the argument that you can use tabs to indent, and spaces to align. In theory this sounds cool, but in practice I suspect it would be more of a pain than anything, seeing as you can't see which character you have (unless you like turning on that sort of thing).
So I had an idea - why not the editors? Why shouldn't editors let you configure the number of spaces you're going to use to indent, but also the appearance of those spaces. That is:
Normal:
class MyClass:
____def myfun():
________somevariable = 42
________volts = 40000000 # If you're into that sort of thing.
________________________________# Not well-formatted Python, though.
Leading indent set to appear as 2 spaces:
class MyClass:
__def myfun():
____somevariable = 42
____volts = 400000000
Is it possible to do something like this with vim? I know it's totally possible to write a post-open/pre-save command to replace the contents, which might work the same... but I'm more curious if it's possible, in vim, to make it appear as though the leading spaces are less (or more) than they actually are?
Yes, you can, using the conceal feature. Demonstration (using the markup from your example text and a different replacement character instead of spaces for effect):
:syntax match Indent "\%(^\%(__\)*\)\#<=__" conceal cchar=#
:set conceallevel=2 concealcursor=nvic
The pattern matches every pair of __ at the beginning of the line, and replaces (conceals) each with a single #, effectively reducing the visible indent.
As a purely visual feature, I don't find it very useful though, and would prefer the post-open / pre-save solution you seem to be aware of.
Imagine I have a sentence like this:
Block chain, the decentralised public ledger that records transactions on the bitcoin network.
And if my cursor is at the end of the first word, is there a way to move relative to the end of the sentence rather than from the cursor position? Think of something like, the first c from right hand side is where I want to go, is there a way to reach rather than going to the end first and using F to reach the c ($Fc).
Yes, Vim has (an abundance of) motions that move relative to the current (cursor) position: l, w, f among them. And you can re-position the cursor easily with many motions: ^, 0, $, gm. When combined, that means you can reach almost any place with just a few keystrokes, and it's possible to remember each of those quite easily.
Given that there's a limit to available keys (and that Vim out of the box already uses most of them!), and a limit to what you can memorize, I think that's a perfect balance. In that light, I think $Fc is nothing to worry about (just compare with other editors!)
If that particular motion's inefficiency bothers you, you can always write a custom mapping (and assign one of the few available keys), but that doesn't scale well.
If you think $Fc 3 keystrokes is too many......
operator + target char have already 2 strokes.
We can dynamic capture the target char. But to make it 2 strokes, we have to scarify a normal mode key, I don't know which one you don't use, I just cannot find one on my keyboard, so as example I use the <F6> you can change it as you like.
This mapping allows you press <F6>c to that place, of course, c could be any character.
nnoremap <expr> <space> '$F'. nr2char(getchar())
And this won't work if the target char, i.e (c) is at the EOL. Well you can do further checking, e.g. write your own function to do it, if you think it is really necessary.
Personally I don't think it is worthwhile. Just get used to the $Fx.
Is there a way to assign an individual character, as identified by a height and depth index, to a highlight group? Every match feature I have come across uses a regex pattern as input.
The reason I ask is because I am making a syntax coloring plugin that will make text an increasingly lighter shade of gray with increasing parenthesis depth. If vim has no such feature and another algorithm makes character-by-character highlighting unnecessary, please point me to it!
Vim has a whole set of special regular expression atoms that can specify buffer positions.
For lines, \%23l matches only in line 23. You can also use \%>23l for all lines starting from 23, and concatenate two of those with < and > to specify ranges.
For columns, there are the corresponding \%23c and \%23v. The former uses byte indices (what Vim somewhat confusingly calls "columns"), as returned by functions like col() and getpos(), the latter screen widths (from virtcol()).
By combining those atoms, you can select arbitrary blocks of text, and highlight them, e.g. with :call matchadd(...). See :help /\%l for details on the atoms.
For your plugin implementation, you may be able to get some ideas from the vim js context coloring plugin, which highlights JavaScript code according to its scope.