Re: Matching JUST the nth occurence of a text in a line
All,
I am puzzled by a slightly more complicated version:
how to match a '%' character following the 2nd occurrence of home?
--Matt
On Fri, Dec 01, 2006 at 09:09:17AM -0500, Charles E Campbell Jr wrote:
Peter Hodge wrote:
Try:
/^.\{-}home.\{-}\zshome
for your reference:
\{-} makes the '.' match as little as possible
\zs makes the search match begin at this point in the pattern
To generalize to the n-th occurrence: (put the qty of skipped matches in N)
/^.\{-}\%(home.\{-1,}\)\{N}\zshome
So, for the 2nd home: let N=1.
Regards,
Chip Campbell
Re: Matching JUST the nth occurence of a text in a line
On Fri, Dec 01, 2006 at 10:34:14AM -0500, Charles E Campbell Jr wrote:
[EMAIL PROTECTED] wrote:
I am puzzled by a slightly more complicated version:
how to match a '%' character following the 2nd occurrence of home?
/^.\{-}\%(home.\{-1,}\)\{N}home.\{-}\zs%
This pattern doesn't work. Try it on this line:
home home home home home home% home
It should match nothing on that line, because the '%' doesn't follow the
2nd occurrence as desired.
--Matt
where N is 1 for the 2nd occurrence (N is 2 for the third occurrence,
etc).
This pattern matches up to and including the 2nd home, extends past a
minimal amount of anything up to but not including a %, whereupon the
pattern matching starts.
Regards,
Chip Campbell
anyone know how to execute a selection?
All,
What I want is similar to evaluating a region in emacs. I want to be
able to make a selection of vim code, and then execute it.
:source only takes files.
As for :exe, I have tried this: :exe getreg(''), and found it to be
unreliable.
Anyone have ideas?
--Matt
Re: anyone know how to execute a selection?
Fantastic.
Thanks.
--Matt
On Sat, Nov 25, 2006 at 02:13:11PM -0600, Bill McCarthy wrote:
On Sat 25-Nov-06 1:40pm -0600, [EMAIL PROTECTED] wrote:
What I want is similar to evaluating a region in emacs. I want to be
able to make a selection of vim code, and then execute it.
:source only takes files.
As for :exe, I have tried this: :exe getreg(''), and found it to be
unreliable.
Anyone have ideas?
I'm not familiar with emacs, but your question reads like
you want to visually select some text, yank it to a register
and source it.
If you yank it with just 'y' you will use the register.
To source that type:
:@
To read more:
:help :@
BTW, if each line of the text you are yanking starts with a
':', you can just execute the contents of the register with
the normal command '@' (assuming the register).
:help @
--
Best regards,
Bill
should space exit completion menu?
All, Recently I was appreciating the beauty of using pumvisible() to setup all kinds of mappings for the completion menu (ex. enter to do c-y). I noticed when messing around with all of that, that space actually exits the menu. Is this the desired behavior? Sometimes I am doing line completion (c-x,c-l) and I type part of the line to narrow the matches; however, space just exits the completion. If someone wants space to behave this way, couldn't he/she just make the mapping? --Matt P.S. Another example is c-xc-f; and some of the filenames have spaces in them. The menu exits before you can make your selection.
completion tip from vim.org
All, Due to some good feedback I've gotten on this tip, I'm posting it to this list. Here is the link: http://www.vim.org/tips/tip.php?tip_id=1386 The tip shows you how to make the completion popup menu in Vim work exactly like in IDEs. Meaning, you can just launch the menu whenever you want, type a few characters to narrow down matches, then just hit enter to insert the selected completion item. Without the mappings on that page, this behavior is not possible. --Matt P.S. I always welcome suggestions.
Re: buffer list count
On Tue, Nov 14, 2006 at 02:04:40AM +0100, A.J.Mechelynck wrote: Eggum, DavidX S wrote: Matt, You can speed up the calculations considerably if you keep several things in mind: - buffer numbers are never reused. - built-in vim functions are written in C and are very fast - although you can open many files at once (like vim *.cs), buffers are usually (always?) deleted one at a time. [...] Not always. The :bwipeout and :bdelete commands can take any number of space-separated buffer numbers and/or non-purely-numeric buffer names. Personally I sometimes use :bw in that way when :ls! shows too many buffers for my taste. That is correct. You can do something like 1,30bw. However, the only bugs I've found so far with the Buf(Add/Delete) autocmds have been related to autocmds and something like vim *.c. If I just put nested in all the autocmds and maually count the buffers on VimEnter, my scheme will probably work. Best regards, Tony. --Matt
buffer list count
All, I am trying to keep track of the number of buffers in the buffer list. I'm doing this with the following code: autocmd BufAdd * let g:zbuflistcount += 1 autocmd BufDelete * let g:zbuflistcount -= 1 The problem is I found this to be very unreliable in some circumstances, and I'm not sure why. The most obvious one is vim *.cs where multiple files would be opened; however, the BufAdd autocmd wouldn't run enough times. Any ideas? Thanks. --Matt
Re: buffer list count
On Sun, Nov 12, 2006 at 07:14:49PM -0600, Bill McCarthy wrote: On Sun 12-Nov-06 6:17pm -0600, [EMAIL PROTECTED] wrote: I am trying to keep track of the number of buffers in the buffer list. I'm doing this with the following code: autocmd BufAdd * let g:zbuflistcount += 1 autocmd BufDelete * let g:zbuflistcount -= 1 The problem is I found this to be very unreliable in some circumstances, and I'm not sure why. One approach is to eliminate the baggage of autocmd triggering and write a function to perform the count on the fly. Such as this Vim 7.0 function: Well I'm reporting the above g:zbuflistcount in my 'rulerformat'. I really don't think I can afford the baggage of calling your function from within my 'rulerformat'. function CountListedBuffers() let cnt = 0 for nr in range(1,bufnr($)) if buflisted(nr) let cnt += 1 endif endfor return cnt endfunction You may need to replace the buflisted() function to something accurate to your meaning of in the buffer list. -- Best regards, Bill --Matt
how can these two act differently?
All, I decided to make a mapping that simply hits down whenever the popup menu comes up. This is to make the popup behavior work more like in IDEs, where the user can just select the nearest completion item at any moment by hitting enter (c-y does this in Vim). Here are two mappings I tried to accomplish my goal: 1. inoremap c-n c-r=pumvisible() ? \ltc-n : \ltc-n\ltc-r=pumvisible() ? \\\ltdown\ : \\\ltcrcr 2. inoremap expr c-n pumvisible() ? \ltc-n : \ltc-n\ltc-r=pumvisible() ? \\\ltdown\ : \\\ltcr To me, they should be identical. However, the first doesn't work in some circumstances, whereas the second always works. Specifically, #1 doesn't work when the vim/gvim window is not large. For those of you who like the idea, use mapping #2. Here are more ideas: set cot+=menuone,longest inoremap expr cr pumvisible() ? \c-y : \c-gu\cr --Matt
Re: Flickering of completion menu
I would also love a flicker-less popup menu. I use the completion
excessively, since I've found it makes coding faster and less error
prone. I noticed the menu only flickers in some cases.
--Matt
On Wed, Nov 08, 2006 at 10:10:09AM +1100, Peter Hodge wrote:
Hello,
I agree, it would be great if the popup-menu could be optimized. One of the
best features of Vim is that is fast enough to keep up with my keystrokes
(many
editors will begin to 'lag' when given commands too rapidly, and I have to
stop
and wait for them). I often have to slacken my pace when it comes to Vim's
popup-menu, because it takes at least .2 seconds to redraw each time I press
CTRL-N.
regards,
Peter
--- Nikolai Weibull [EMAIL PROTECTED] wrote:
Hi!
As you've probably all noticed the completion menu flickers when you
move through the items rapidly. Why is this? Is it really necessary
to redraw the whole completion menu when it really only should require
redrawing the item previously selected and the item selected now [1]?
Anyway, would this be possible to implement?
Also, here's a set of mappings that make the digits move their value
number of items down the completion list (if displayed):
for digit in [1, 2, 3, 4, 5, 6, 8, 9]
execute 'inoremap silent ' . digit . ' C-R=pumvisible() ? ' .
repeat('\ltC-N', digit) . ' : ' . digit . 'CR'
endfor
(I guess this could be extended to include -n, for 1 = n = 9, which
would move n number of items upward. Any takers?)
It flickers like mad, but at least it goes a lot faster than holding
down CTRL-N or CTRL-P.
nikolai
[1] Excepting the case where one begins to scroll in the menu, when
all items need to be redrawn, as they move up or down one step - which
leads to a second question, wouldn't it be a lot more economical to
scroll like half a menu or something, so that scrolling wouldn't
require so many redraws? Or at least utilize the terminal codes that
enable scrolling in a buffer to be done with only redrawing the first
or last line when scrolling by a single line in a buffer?
Send instant messages to your online friends http://au.messenger.yahoo.com
avoiding unneeded buffer scrolling
All, It bothers me how when switching between tabs (gt) or switching between buffers (:bn, :bp), sometimes a buffer will end up being shifted/scrolled up/down within its window. For the occasions that I want to shift the buffer I have keys like zz to do this manually. I don't want this to happen automatically. Is there any way to avoid this automatic shifting that I'm talking about? --Matt P.S. There is a shift that frequently happens when closing the second to last tabpage. The last line of the newly active window will scroll to the bottom line of the window.
Re: getchar() trick with recursive expr map
Great. Yeah it always bothered me that there's no way to monitor every keypress unless you map every key, which is quite ugly. --Matt On Thu, Oct 19, 2006 at 11:26:53PM -0700, Hari Krishna Dara wrote: I remember someone posting a patch to add a new event called GetChar to receive an event for every keypress. This trick is not as powerful and flexible as that, but it can be very useful for a plugin, and is supported in Vim7.0 with no patches. Often there are questions on this list on how to capture every key press from a user, and the answer is that it can't, unless you map all keys. But even if you map all keys, it is not flexible enough. Here is a trick with recursive expr maps and getchar() to get all keys pass through your function. You can do whatever you want with the keys, swallow them or pass them to Vim. Here is a demo that shows how to use it in insert mode. What the function does is to double every key you press, except Esc and C-C, when it breaks the loop. imap buffer silent expr F12 Double(\F12) function! Double(mymap) try let char = getchar() catch /^Vim:Interrupt$/ let char = \Esc endtry exec BPBreakIf(char == 32, 1) if char == '^\d\+$' || type(char) == 0 let char = nr2char(char) endif It is the ascii code. if char == \Esc return '' endif redraw return char.char.\C-R=Redraw()\CR.a:mymap endfunction function! Redraw() redraw return '' endfunction You can do almost eanything that you can do normally in an insert mode, press BS, C-U etc. Hope someone finds this useful. I will also post this as a tip. -- Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Searching for selected text
I don't like this one more, but it's a good alternative: g/ g? Also, I feel that one day might do something in visual; at least visual line mode. --Matt On Sat, Sep 30, 2006 at 01:37:59PM +0200, Bram Moolenaar wrote: Sometimes people ask me for a command to search for the text that is currently visually selected. You could add a mapping for the '/' key, but then you lose the possibility to extend the visual area by searching for a pattern. Since we might need more commands in Visual mode later, and we only have a few keys left to be used, we need to use two key combinations for new commands in Visual mode. I think we can start using the '' key. Currently it doesn't do anything. For now we could add the commands: / search for the Visually selected text forward ? same, backward Is there a good alternative? -- Any resemblance between the above views and those of my employer, my terminal, or the view out my window are purely coincidental. Any resemblance between the above and my own views is non-deterministic. The question of the existence of views in the absence of anyone to hold them is left as an exercise for the reader. The question of the existence of the reader is left as an exercise for the second god coefficient. (A discussion of non-orthogonal, non-integral polytheism is beyond the scope of this article.) (Ralph Jennings) /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Vim BOF session
On Sun, Sep 03, 2006 at 01:21:06PM +0200, Mikolaj Machowski wrote: Dnia sobota, 2 wrze?nia 2006 12:36, Kim Schulz napisa?: Omnicompletion++: --- Omnicompletion is a great new feature, but I would like to see it become even stronger. The intellisense plugin for gvim on win32 has some of the features I would love to see in the generic omni completion: quickhelp for items in list if available: http://insenvim.sourceforge.net/images/vis_help.jpg parameter help in tooltip: http://insenvim.sourceforge.net/images/vis_tooltip.jpg Some of this might be possible to make with scripts, but it often tend to become slow if not natively implemented. (and please kill the pink color - it is really ugly) You point can be split in two: 1. Intellisense plugin is tied to widget system. It could mean that popup system had to be written each time for each GUI. Monstrous effort for writing and maintaining. But the current popup system in Vim does not require intense rewrites for each GUI. 2. Info provided by intellisense can be provided by current implementation of omnicompletion. Problem is efficiency and size of data. For example inclusion of built-in functions in PHP omnicompletion caused that phpcomplete.vim has almost 300K. Adding help would easily explode that file to few M [1]. Parsing of PHPdoc is also possible but it could take time (phpcomplete is already sluggish). pythoncomplete.vim is about 20K and seems to return a wealth of info. Also, I'm more interested in plugins that 3rd parties might make, that won't be included into Vim. Those 3rd party plugins might require people to download megs of xml data files or something of the sort; and who cares, it's not bundled with vim. --Matt [1] Hmm. It could be done by external manual and dependency on `lynx -dump`. OK, done (1h), but it is unusable because scrolling of info window is practically impossible. m.
Re: tab split scrolling problem
All, Can someone please try this out and confirm: On Tue, Jun 20, 2006 at 09:18:40PM -0400, [EMAIL PROTECTED] wrote: All, I mentioned this problem once on the list before; however, the issue wasn't reproducible. Now I found a way to consistently reproduce it. 1. Open a new plain vim in a terminal. 2. :h to open a help window. 3. :wincmd o to close all other windows except the help window. 4. G to go to the last line. 5. c-e a few times (around 5) to scroll down. 6. :tab split to open a new tab. 7. :tabclose to close the new tab and return to the previous. After all of this, the space generated by scrolling (via c-e) disappears. --Matt
Re: tab split scrolling problem
All, Can someone please try this out and confirm: On Tue, Jun 20, 2006 at 09:18:40PM -0400, [EMAIL PROTECTED] wrote: All, I mentioned this problem once on the list before; however, the issue wasn't reproducible. Now I found a way to consistently reproduce it. 1. Open a new plain vim in a terminal. 2. :h to open a help window. 3. :wincmd o to close all other windows except the help window. 4. G to go to the last line. 5. c-e a few times (around 5) to scroll down. 6. :tab split to open a new tab. 7. :tabclose to close the new tab and return to the previous. After all of this, the space generated by scrolling (via c-e) disappears. --Matt
tab split scrolling problem
All, I mentioned this problem once on the list before; however, the issue wasn't reproducible. Now I found a way to consistently reproduce it. 1. Open a new plain vim in a terminal. 2. :h to open a help window. 3. :wincmd o to close all other windows except the help window. 4. G to go to the last line. 5. c-e a few times (around 5) to scroll down. 6. :tab split to open a new tab. 7. :tabclose to close the new tab and return to the previous. After all of this, the space generated by scrolling (via c-e) disappears. --Matt
Re: completion question
All,
I'm curious to know peoples' opinions on this matter, especially Bram,
since he's back.
The issue is about whether the completion popup menu should disappear
when the user hits backspace all the way back to the initial
pre-completed state. Right now, the popup window disappears.
--Matt
On Mon, May 15, 2006 at 12:00:26AM +0200, Martin Stubenschrott wrote:
On Sun, May 14, 2006 at 05:24:35PM -0400, [EMAIL PROTECTED] wrote:
All,
If I hit c-n on an empty line to do keyword completion ('completeopt'
is set to longest,menuone), and I type a few chars, then hit backspace
all the way up to the beginning of the line; the popup window at that
point disappears. The behavior used to be that the popup window would
stay up. I think it's inappropriate to have the popup window disappear
just because you arrived at the initial state when the popup window
appeared. Couldn't the behavior be that the popup window disappears when
you go yet passed this point?
I also agree with your point.
Often after pressing c-xc-o to do context senstitive completion, I
press one character to narrow things down.
When I then see, that the narrowed matches don't make sense, I want to
press backspace to get all the previous machtes back.
E.g. often I don't know if it's .length() or .size() to get the length
of an array. Then I press array.c-xc.o and a 'l' - if this
doesn't show me a .length() parameter, pressing bssc-n to complete
.size() would make sense.
--
Martin
commandline window
All, Is there an elegant way of checking if the current window is a command line window other than seeing if the buffer name is command-line ? --Matt
Re: VIM script replacement question
Nikos, The one line :%s way that was posted before is the truly elegant way of solving this problem. However, I found that macros are especially appropriate in this case. I was able to execute the whole task in 15 seconds by recording a macro for the first line, and then playing it back 26 times. Remember q is for recording macros. --Matt On Thu, May 25, 2006 at 05:26:16PM +0300, Nikolaos A. Patsopoulos wrote: Hi all, I've got a series of files in the following format (tab delimited): 11000 20000 30000 41110 51100 60000 111101 121111 130000 140000 151000 161100 211101 221000 230100 241110 251111 260000 270000 I want to transform them in the following format: #1 1 0 0 0 #2 0 0 0 0 etc.. In detail: 1.I want in front of the number in the first column to add # , then change line after the value 2. change line after 3rd column 3. change line after 5th column 4. repeat all three steps Any ideas?? Thanks in advance, Nikos
Re: [vim7] a strange behavior of completeopt
On Tue, May 16, 2006 at 08:57:57AM -0400, Benji Fisher wrote: On Tue, May 16, 2006 at 04:06:27PM +0800, Linsong wrote: Hi, all I encounter a strange problem when use vim7, the following steps will reproduce the problem: 1. run vim with command: vim -u NONE -U NONE 2. set the follwoing options: :set nocompatible :set completeopt+=longest 3. input some text into the buffer like this: foo.bar bet better 4. then input foC-P, fo will completed as foo, that is expected, input '.b' after foo, now the text becomes foo.b, then press C-P, it will become fo. Is it expected or maybe a bug? Any explanation is welcomed! Best regards, Vincent I can confirm this. It looks like a bug to me. I have run into similar problems before, but have not figured out how to reproduce them. Thanks for the reproducible example. HTH --Benji Fisher I can confirm the same as well. Probably a bug. Difficult to catch because normally people get out of completion mode. If, at foo.b, one presses c-e to exit from completion mode, the following c-p will work appropriately. --Matt
Re: Vertical splits
You can always do a :vertical before the command, and whenever there is a split inside the command, the split will be vertical. --Matt On Mon, May 15, 2006 at 05:27:29AM -0700, Salman Khilji wrote: Regarding my previous post, I would like to change teh default behavior of VIM to prefer vertical splits instead of horizonal splits. I not only want to change C-W ] command, but all commands that have to split a window. Whats the quickest way to make this change? I am thinking along the lines of editing the VIM source code and searching for somehting like vertical_split() and horizontal_slit() functions and interchanging them. Salman __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Is there a way to move tabs around via the mouse?
On Sun, May 14, 2006 at 03:28:23PM -0600, Eric Arnold wrote: I've uploaded the patch. It's at proof-of-concept stage. Eric, I noticed you've made a few patches. I especially like the one where you introduced the GetChar event. This is a fantastic idea because the getchar() function itself is very limiting, disabling normal Vim behavior during its use. Something like this GetChar event will allow some extremely powerful plugins to be made. Have you proposed the patch to Bram? --Matt P.S. Maybe a GetCharPre/GetCharPost scheme would be useful, since because of mappings and what not, you might not know what's going to happen when the char is processed. You could use GetCharPost to see what happens after it was processed. Just a thought.
Re: :bd should NOT close the Window
You can try my short script which does exactly what you want: http://www.vim.org/tips/tip.php?tip_id=1078 --Matt On Fri, May 12, 2006 at 08:38:24PM +0300, Yakov Lerner wrote: On 5/12/06, Salman Khilji [EMAIL PROTECTED] wrote: When you have a window split, issuing a :bd command closes the buffer AND one panes of the split window as well. I like to have my maximized window split vertically in 2 panes all the time and would NOT want the :bd command to close any of the panes. Can it be done? You can't make :bd a total no-op. But. You can try the following trick to make the deteled buffer *re-appear*. Buffer will flick but won't go away if you work out all details of this. Here is the idea: 1. hook the BufDelete autoevent. 2. for your undeletable buffer(s), set some b: variable, say b:undeletable to true. (you probably won't want to make all buffers undeletable, only some). 3. In BufDelete event, check b:undeletable flag. If the flag is on, then 4. create new buffer with same size, position, contents, setting, and proper cursor position. I didn't try it, but i think it can be made to work. You'll need to resolve many small details along the way, like how to restore position, contents, cursor, and settings of the deleted/restore buffer. Note than undo history of the restores buffer will be inevitably lost. Yakov
Re: [Maybe Off Topic]: To Bram: About your paid job
Working for Google is indeed a great honor, and they probably gave you an 'offer you cannot refuse'. I hope you can spend some of the time you work at Google to develop Vim, I know they let their workers do so (this is something you know better than I am). Any way, if you do want to continue developing Vim as a full time job I hope you will be able to do so. It is indeed an amazing program, by now, it is the only text editor I can use. I know several big companies that use Vim internally. Maybe Bram could continue to work on a free Vim, but charge for support. --Matt
Re: cursor shape in terminal vim
I use urxvt (rxvt-unicode). It supports cursor shape and blinking. --Matt On Fri, May 05, 2006 at 11:27:52PM +0200, Bram Moolenaar wrote: William O'Higgins Witteman wrote: How do I set vim in the terminal to use the pipe character for the cursor when in insert mode? This seems to be the default behaviour for gvim, but I am happiest in my terminal window (or the console) and would like this to work there. Any suggestions? Thanks. In Vim 7 you can use the t_SI and t_EI termcap options. See :help termcap-cursor-shape. I don't think it is possible in Vim 6.4 or earlier. -- Time is an illusion. Lunchtime doubly so. -- Ford Prefect, in Douglas Adams' The Hitchhiker's Guide to the Galaxy /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: completeopt: menu|menuone + longest = bug?
On Tue, May 02, 2006 at 12:13:37AM +0200, Bram Moolenaar wrote: Eric Van Dewoestine wrote: I know about this: When you type the . and there no complete match was inserted (showing the longest common text in this example), Vim assumes you are extending the text to reduce the list of matches. Thus the completion still starts at BlahBlah. You need to stop completion somehow, e.g., with a space and backspace. This is not a nice way to work. I thought of having all punctuation characters stop completion, but that breaks completion of items where punctuation can be part of the match (e.g., () for functions). Ah, that makes sense. What about an option for specifying what characters end the completion? setlocal completedelim+=. or something similar? It's too complicated already, adding another option will mainly cause more users to get confused. Also, I wouldn't know what to set it to for C. It's not that confusing. This is not a good reason for not implementing something like 'completedelim'. A better reason would be that nobody feels like implementing it and documenting it. So far there are three options starting with complete. This is complicated? I thought Vim/Emacs are ultra configurable... and the menu/completion system is a big feature. If it were up to me, I would have an option for what characters end the completion, and also what characters select the current completion and then end the completion... or something like that. Maybe not. At least something like completedelim. --Matt -- ARTHUR: I've said I'm sorry about the old woman, but from the behind you looked ... DENNIS: What I object to is that you automatically treat me like an inferior... ARTHUR: Well ... I AM king. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: probably known bug
On Fri, Apr 28, 2006 at 04:08:32PM +0200, Nikolai Weibull wrote: On 4/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I found a bug related to syntax highlighting, although I wouldn't be surprised if people already know about this. Simply, the syntax highlighting sometimes gets messed up and I have to refresh the window (with c-l) in order make the highlighting correct again. I have been experiencing this for a while. Is there an effort to fix this? The syncing could probably be better, but this problem is sometimes unavoidable. Knowing what filetype the problem occurs for would help in investigating the issue further. I don't know if sometimes it's unavoidable, but definitely sometimes it is avoidable. In my experience, it happened probably at least once with every filetype I've worked with. Just off the top of my head, it happened yesterday in a JSP file, and later in a Perl file. And it seems to happen a lot in HTML files. nikolai
Re: swapping tab and escape
Yes... I, Matt, who recommended the tab mappings, do no advise mapping tab this way for command line because of the lack of completion. However, you can do a ctrl-d for a kind of completion. --Matt On Thu, Apr 27, 2006 at 01:58:53AM -0700, Gerald Lai wrote: On Thu, 27 Apr 2006, Robert Cussons wrote: Hi All, Matt kindly suggested this mapping for the above inoremap m-i tab nnoremap tab esc vnoremap tab escgV inoremap tab esc`^ but how would I add a mapping to make tab work as escape in the command line, also is there any loss of functionality making this mapping, I don't use tab in the command line, but does it do anything useful that I don't know about? Tab is used as the completion key in the command line. This is extremely useful, IMHO. For example, (with cursor as _ underscore) typing :help dos-p_ and then hitting Tab will produce :help msdos-problems_ If you'd like to make Tab act as Esc in the command line, do :cnoremap Tab Esc HTH :) -- Gerald
gm command
All, I use gm, H, M, L commands often. I noticed that gm aims at half the screenwidth, rather than half the line width. I realized that if it aimed at half the line width, it would be more useful. Could it be considered to change the behavior of gm. Is there any good reason why it functions the way it does now? Thanks. --Matt
Re: swapping caps lock and escape
On Mon, Apr 10, 2006 at 11:54:50AM +0200, Robert Cussons wrote: Thanks for the suggestions, at the moment I think, I like Gerhard's the most. I have created the file, and I'll just have to see tomorrow morning as I don't want to close everything and lock out and in again just now. Thanks again for the help, Rob. I do the following: inoremap m-i tab nnoremap tab esc vnoremap tab escgV inoremap tab esc`^ In this way, I use tab to do what escape does. It's great because it works on every machine. I used to map caps to escape but then when I went to work, I couldn't do the same on my work machine. --Matt
