Lecture 10: Maps Part II: Core Commands
Announcements • HW3 due NOW!
Announcements • HW3 due NOW! • There will be no HW4... – Don't have enough time to give feedback for HW3. – However, everything covered so far will still be on the exam regardless.
Announcements • What will be on the exam: – EVERYTHING from Part II of the course, including the homework material. – Maps and commands from today. – You do not need to know about code tools (covered next lecture)...Though you probably should.
Announcements • Exam format: – Will NOT involve descriptions. – Will get very little credit for writing descriptions only. (You NEED to know all the commands.) – Use commands at your discretion (ergonomics, clarity) – Have to know sound practices of vimscript! – Will be penalized (hard) for bad practices.
Something else you have to know • The undo and redo commands: u Undo previous change <C-r> Redo previous change • Will NOT undo/redo previous locate, use <C-o>/<C-i> for that.
Today: Maps
Today: Maps • Absolute worst of vimscripting
Today: Maps • Absolute worst of vimscripting • Dark side of vimscript
Today: Maps • Absolute worst of vimscripting • Dark side of vimscript • Be extra careful!
Today: Maps • Absolute worst of vimscripting • Dark side of vimscript • Be extra careful! • Sometime I don't get it right (and it's near impossible to debug)
Maps • A map is pressing one key combination to perform another key combination . • Note that this does NOT guarantee pressing one key combination to execute certain commands!
Maps • A map is pressing one key combination to perform another key combination . • Note that this does NOT guarantee pressing one key combination to execute certain commands! – wrong mode, previous keymaps, and other shenannigans (which you shall see).
Maps • Notation: • If I want to press the keys Q to perform the keys dt , I write: Q --> dt
Maps • Why do we need our own notation?
Maps • Why do we need our own notation? • Because SHENANIGANS !
Maps • Why do we need our own notation? • Because SHENANIGANS !
General Syntax for Maps
General Syntax for Maps
General Syntax for Maps • To map: <keystrokes1> --> <keystrokes2> • We put this in vimscript: <maptype> <keystrokes1> <keystrokes2>
General Syntax for Maps • To map: <keystrokes1> --> <keystrokes2> • We put this in vimscript: <maptype> <keystrokes1> <keystrokes2>
<maptype> • <maptype> indicates what kind of context your map works in.
<maptype> • <maptype> indicates what kind of context your map works in. • Two questions: • Which mode does your mapping work in? • What kind of mapping should it map to?
<maptype> • Which mode should it work in? Should it work in... – Normal Mode, prefix with n – Insert Mode, prefix with i – Visual Mode, prefix with v (not true technically, but nobody cares). – Command Line Mode, prefix with c – Any mode, don't prefix.
<maptype> • Which mode should it work in? Should it work in... – Normal Mode, prefix with n – Insert Mode, prefix with i – Visual Mode, prefix with v (not true technically, but nobody cares). – Command Line Mode, prefix with c – Any mode, don't prefix. (99.999% of time, you don't want to map to every mode)
<maptype> • Examples: • nmap u v – u --> v (in normal mode only) • imap xx <Esc> – xx --> <Esc> (in insert mode only)
<maptype> • What kind of mapping should it map to?
<maptype> • What kind of mapping should it map to? • Much much harder question to answer.
<maptype> • What kind of mapping should it map to? • Much much harder question to answer. • When I map: u --> v , whose functionality should I invoke?
<maptype> • What kind of mapping should it map to? • For example: • v --> i • u --> v
<maptype> • What kind of mapping should it map to? • For example: • v --> i • u --> v • So is u --> i ?
<maptype> • What kind of mapping should it map to? • For example: • v --> i • u --> v • So is u --> i ? Depends on <maptype> .
<maptype> • What kind of mapping should it map to? • For example: • v --> i • u --> v • Two cases: – if I want to use the default behavior of Vim's v keystroke, it is called a nonrecursive mapping. – if I want to use my already mapped behavior of Vim's v keystroke, it is called a recursive mapping .
<maptype> • Syntax for <maptype> : • <mode indicator><recursive?>map • Where <recursive?> can be: – Nothing, if it is recursive – nore , if it is nonrecursive.
<maptype> • Examples! • nnoremap u v – u --> v (in normal mode, and invokes the default behavior of v , which is enter/exit visual mode) • nmap lol u – lol --> u (in normal mode, and invokes the mapped behavior of u , which so far, is the same as invoking the default behavior of v , which is enter/exit visual mode)
<maptype> • Best Practices (they are strict, always follow them!): • ALWAYS ask yourself those two questions when writing maps!
<maptype> • Best Practices (they are strict, always follow them!): • Bad examples: • 1. Mapping to all modes: – noremap Q K – When in insert mode, can't type Q anymore!
<maptype> • Best Practices (they are strict, always follow them!): • Bad examples: • 1. Mapping to all modes: – noremap Q K – When in insert mode, can't type Q anymore!
<maptype> • Best Practices (they are strict, always follow them!): • Bad examples: • 2. Using a recursive mapping when a nonrecursive mapping should be used instead. – nnoremap w W – nmap Q :w<CR> • w --> W . • Q --> :w<CR> --> :W<CR> • Not valid command anymore!
<maptype> • Best Practices (they are strict, always follow them!): • Bad examples: • 2. Using a recursive mapping when a nonrecursive mapping should be used instead. – nnoremap w W – nmap Q :w<CR> • w --> W . • Q --> :w<CR> --> :W<CR> • Not valid command anymore!
<maptype> • Best Practices (they are strict, always follow them!): • Bad examples: • 2. Using a recursive mapping when a nonrecursive mapping should be used instead. – nmap u v – nmap v u • u -> v -> u -> v -> u -> v -> u -> v -> ...
<maptype> • Best Practices (they are strict, always follow them!): • Bad examples: • 2. Using a recursive mapping when a nonrecursive mapping should be used instead. – nmap u v – nmap v u • u -> v -> u -> v -> u -> v -> u -> v -> ...
<maptype> • Best Practices (they are strict, always follow them!): • Bad examples: • 2. Using a recursive mapping when a nonrecursive mapping should be used instead. – nmap u v – nmap v u • u -> v -> u -> v -> u -> v -> u -> v -> ...
<maptype> • Hence: • ALWAYS write maps on the specific mode you want to map to (you can guarantee that you will never use a raw map ). • Don't use recursive maps unless you know what you are doing (few cases permit that, when you really want to perform your own mappings!)
<maptype> • When to use recursive maps: " Magically map %% to current file directory cnoremap <expr> %% getcmdtype() == ':' ? expand('%:h').'/' : '%%' " Quick directory edit load nmap <leader>e :edit %%
and now, onto the actual shenannigans...
and now, onto the actual shenannigans...
Bad Syntax Design 101 • <maptype> <keystrokes1> <keystroke2> • Are delimited by single spaces...
Bad Syntax Design 101 • <maptype> <keystrokes1> <keystroke2> • Are delimited by single spaces... • ... and is not a good idea!
Bad Syntax Design 101 • nnoremap u v ^ ^^ • So is it: • u --> <Space>v ? • u<Space> --> v ? • u --> v ?
Bad Syntax Design 101 • nnoremap u v ^ ^^ • So is it: • u --> <Space>v ? • u<Space> --> v ? • u --> v ? • Short answer: I don't know! Depends on version. Never rely on that.
Bad Syntax Design 101 • nnoremap u<Space> v ^ ^ • Right way to write that ^. • So is it: • u --> <Space>v ? • u<Space> --> v ? • u --> v ? • Short answer: I don't know! Depends on version. Never rely on that.
Bad Syntax Design 102 • nmap <leader>e :edit %% • ^ ^ ^ • So is it: • <leader>e --> :edit<Space>%% ? • :edit --> %% ? • Something else ?
Bad Syntax Design 102 • nmap <leader>e :edit %% • ^ ^ ^ • So is it: • <leader>e --> :edit<Space>%% ? • :edit --> %% ? • Something else ? • Vimscript maps are ALWAYS greedy in these situations! • Swallows the first two spaces, maps the the thing in between the two spaces to after the second space.
Recommend
More recommend
