Re: mapping g
On Wed, Nov 15, 2006 at 08:11:42PM -0600, Manfred Georg wrote:
> Hi,
>
> Apparently this isn't a very popular thing to do, but I remap g
> to help me do indentation. There are two problems with this.
> In gvimrc_example.vim , there is some code (which has been copied
> all sorts of places) which does automatic
> jump to last position when file was closed. This uses the command g'"
> Unfortunately when g has been remapped it triggers this mapping.
>
> To fix this the line with
> \| exe "normal g'\"" | endif
> should read
> \| exe "normal! g'\"" | endif
>
> the ! stops it from remapping g to the local mapping.
The patch at the end of this e-mail implements this change. The
file is vimrc_example.vim, not gvimrc_example.vim . (You can probably
do this yourself. See my tip at
http://www.vim.org/tips/tip.php?tip_id=618 .)
> Also, some plugins create some mappings that start with g .
> The problem is that I don't want to wait for the disambiguation delay
> before triggering my mapping. So I want to unmap those mappings in
> the user .vimrc . The problem is that plugins are sourced after
> the user .vimrc . This makes it impossible to countermand the
> mappings created by the plugins automatically (barring using even more
> magical techniques like autocmd). It really seems to me like the
> .vimrc should be sourced after the plugins, it should have the final say.
>
> Thank you,
>
> Manfred
The following function could use some more testing, but the idea is
that
:call Mapclear('g')
should :unmap any mapping that starts with "g". If you do this in your
after/plugin/ directory (maybe after/plugin/zzz.vim ) and then define
your mapping for "g", then you should be in good shape.
fun! Mapclear(init)
redir => mapstr
execute "silent! map" a:init
redir END
let maplist = split(mapstr, '\n')
if len(maplist) == 1 && maplist[0] == 'No mapping found'
return
endif
for mapline in maplist
let parts = split(mapline)
let mode = mapline[0]
let lhs = parts[mode == ' ' ? 0 : 1]
echo mode . "unmap" lhs
endfor
endfun
There is a chicken-and-egg problem: you want to be able to
enable/disable plugins in your vimrc file, so it has to be read before
the plugins are loaded. There are other surprises, too: you might
expect command-line options to override vimrc settings, but they do not.
(Maybe they do not *always* override vimrc settings.) I think we are
stuck with the current system for reasons of backwards compatibility.
It may even be a question of vi-compatibility.
:help design-compatible
HTH --Benji Fisher
*** /usr/local/share/vim/vim70/vimrc_example.vim2006-05-08
10:42:46.0 -0400
--- temp/vimrc_example.vim 2006-11-15 23:30:24.792231281 -0500
***
*** 69,75
" (happens when dropping a file on gvim).
autocmd BufReadPost *
\ if line("'\"") > 0 && line("'\"") <= line("$") |
! \ exe "normal g`\"" |
\ endif
augroup END
--- 69,75
" (happens when dropping a file on gvim).
autocmd BufReadPost *
\ if line("'\"") > 0 && line("'\"") <= line("$") |
! \ exe "normal! g`\"" |
\ endif
augroup END
Re: wrong direction of 'n' -- when #,n are remapped and inside function
On Tue, Nov 14, 2006 at 12:03:45PM +0200, Yakov Lerner wrote: > In the script below, where # and n are remapped, > n goes the wrong direction after #. To see: >vim -u NONE bad.bim >:so % >gg/bannn#n > -- the last n goes forward. we expect it to move backward. > > But when script is rewritten to the form #2, then n after # works > correcty. Plain moving the 'silent! exe "norm!"...' out of the > function changes the behavior. > > Yakov I think this is a side effect of the fact that functions do not change the search pattern. I guess the search direction is stored along with the pattern. Either :help :endfun and scroll up one paragraph or :help :fun /search I think re-mapping "n" does not matter: mapping "#" to call a function will not change the search direction. I am not sure what you are trying to do, but perhaps you can store the search direction in your own (script-local) variable and check that with your re-mapped "n" command. HTH --Benji Fisher
Re: RFE: :amap and :menu
On Thu, Nov 09, 2006 at 12:37:48PM -0700, Christian J. Robinson wrote: > On Thu, 9 Nov 2006, Bram Moolenaar wrote: > > > buffer-local menus are complicated. What about menus that are not > > for the current buffer, hide them? Would make jumping between > > buffers very slow. > > When I've defined menus that are only applicable to a buffer or a > filetype I've just defined autocommands that does an :amenu disable on > BufLeave and :amenu enable on BufEnter. I've found this is usually > the best compromise and in fact has some advantages; it can be > confusing and otherwise problematic to have menu items, or entire > menus--especially toplevel menus--disappear and reappear. > > - Christian Thanks. I had forgotten about the ":menu disable" option. The disadvantage is that if I have several different file types open, each with its own top-level menu, then my menu bar will be crowded with disabled menus. --Benji Fisher
Re: RFE: :amap and :menu
On Thu, Nov 09, 2006 at 08:14:41PM +0100, Bram Moolenaar wrote: > > Benji Fisher wrote: > > > Maps and menus work in much the same way, and when writing a vim > > script (especially an ftplugin) I like to make a menu item corresponding > > to each key map that I define. Unfortunately, there are two ways that > > maps and menus differ: > > > > 1. There is an :amenu command (and also :anoremenu), but there is no > > :amap command (nor :anoremap). > > > > 2. I can make buffer-local maps with :map , but :menu > > does not work. > > > > Both of these shortcomings can be overcome with scripting, but it > > would be more convenient and more consistent if :amap and :menu > > were both implemented. > > Both are in the todo list. I neglected to check. Maybe I need to update my todo list: I see a remark about buffer-local menus, but nothing about :amap. > ":amap" would not be terrible difficult to implement. > > buffer-local menus are complicated. What about menus that are not for > the current buffer, hide them? Would make jumping between buffers very > slow. I will try deleting and refreshing them with autocommands and see how slow it is. Off hand, I would say hide them: I do not want to waste menu space on TeX-related items when I am editing another file type. --Benji Fisher
RFE: :amap and :menu
Maps and menus work in much the same way, and when writing a vim script (especially an ftplugin) I like to make a menu item corresponding to each key map that I define. Unfortunately, there are two ways that maps and menus differ: 1. There is an :amenu command (and also :anoremenu), but there is no :amap command (nor :anoremap). 2. I can make buffer-local maps with :map , but :menu does not work. Both of these shortcomings can be overcome with scripting, but it would be more convenient and more consistent if :amap and :menu were both implemented. --Benji Fisher
Re: script able to detect +NUM commandline option ?
On Fri, Nov 03, 2006 at 01:49:24PM +0200, Yakov Lerner wrote: > Whether Bram thinks it's useful to store this info in some > v:variable (so script can know it) ? > Within last year, there were requests how script can know > whether vim had +NUM option on command line. > > Yakov You mean as in :help -+ I guess? That is too specific; why not make the entire command line available? We have v:progname but not the command-line options (including +NUM). I have wanted this, too. BTW, there are too many v: variables for my taste. Why not put all the v:beval_* variables in a v:beval Dictionary? Of course, the old ones would have to be kept around for compatibility for a few releases ... HTH --Benji Fisher
RFE: 'wordpat' option
Vim Dev gurus: The mailing list has been slow enough that several of us worried it might be broken (or have unsubscribed us) so maybe this is a good time to post a request for a new feature. I already raised this on the vim users' list, but maybe starting a new thread will get more attention. The motions w, b, e, and others depend on the definition of a word. So do the text-object iw and insert-mode completion and and probably a lot of other things. Currently, a word (:help word) consists of a sequence of keyword characters (as specified by 'iskeyword'), separated by non-keyword characters (or start of line or end of line). In other words, a word is specified by the regular expression /\k\@
Re: [PATCH] zip plugin: support any filename
On Mon, Oct 23, 2006 at 10:42:41PM +0200, Martin Stubenschrott wrote: > On Mon, Oct 23, 2006 at 10:02:48PM +0200, [EMAIL PROTECTED] wrote: > > I'm using this to edit firefox extensions directly inside their jar > > files. I'm also attaching a patch that adds the required associations > > (jar and xpi, I'm sure there are more). > > I exactly wanted to do the same, but it didn't work. Hopefully your > patch gets accepted (didn't test it myself yet though). The patch applies to runtime files, so you should be able to apply it without having to re-compile. HTH --Benji Fisher
using autoload/gzip.vim to filter files
Suppose I want to filter foo.doc through antiword or bar.pdf
through pdftk. (Both of these are tricks that I have learned only
recently.) It seems simple enough. For example, vim tip #790,
http://www.vim.org/tips/tip.php?tip_id=790
suggests
autocmd BufReadPost *.doc silent %!/usr/bin/antiword '%'
(along with an autocmd or two to set 'ro' and--I am not sure
why--'nohlsearch'. I tried this, and it worked pretty well until I
tried it on (ugh) file\ with\ spaces.doc . So now I have
autocmd BufReadPost,FileReadPost *.doc execute '%!antiword' escape(@%, ' ')
IIUC, all the details like error handling and escaping spaces in
file names are already handled by autoload/gzip.vim . Before settling
on the above, I tried
" autocmd BufReadPost,FileReadPost *.doc call gzip#read("antiword")
but, as you can see, I commented it out because it did not work. I
apologize: I have not tried as hard as I might to get it to work. Does
anyone else know how to do this? Or does autoload/gzip.vim need to be
made more flexible before it can be applied to other filters (antiword,
pdftk for example) as well as gzip?
--Benji Fisher
:diffsplit | verbose set fdm?
While replying to a post on the vim users' list, I noticed a slight
problem. The diff commands set some options, but this is not reported
with "verbose set". For example
:e foo.txt
:set fdm=marker
:diffsplit bar.txt
:wincmd w " back to foo.txt
:verbose set fdm?
foldmethod=diff
:only
:verbose set fdm?
foldmethod=manual
--Benji Fisher
Re: Convert2HTML Again
On Wed, Oct 11, 2006 at 06:48:47PM +0100, Edd Barrett wrote: > > On 10/10/06, Benji Fisher <[EMAIL PROTECTED]> wrote: > > > > The samples look fine to me (using Mozilla 1.7.12 on Linux). I > >would like to see an example where the background color changes, if only > >so that I can see some situation where > > > > (text) > > > >looks simpler (by rudimentary measures such as character count) than > > > > (text) > > I'm not sure what you mean here. Please explain... I just mean that, looking at the above example and just thinking about how easy it is to read the source, there does not seem to be any advantage to using CSS. With CSS, there will be extra material in the header (defining the attributes for the foo class) and the markup in the body will be about as complicated. However, if the bar class defines foreground and background colors, then the CSS version will still have something like (text) in the body, while the non-CSS version will have something like (text) and now the CSS version is easier to read. If you add a syntax error to your example file, then it should show up with Error highlighting. With most color schemes, this will change the background color as well as the text color. Then we can see how this gets translated into HTML or XHTML. HTH --Benji Fisher
Re: Convert2HTML Again
On Tue, Oct 10, 2006 at 01:40:04PM +0100, Edd Barrett wrote:
> On 01/10/06, Edd Barrett <[EMAIL PROTECTED]> wrote:
>
> > Hope your enjoying your weekend.
> >
> >As promised i have ammended the patch.
>
>
> Hi Guys,
>
> I havent recieved any feedback on this patch yet, did anyone get a
> chance to look at it?
>
> Sorry to be a bore.
>
> Best Regards
>
> Edd
Be careful about what you ask (or wish) for: you just might get
it! ;)
The samples look fine to me (using Mozilla 1.7.12 on Linux). I
would like to see an example where the background color changes, if only
so that I can see some situation where
(text)
looks simpler (by rudimentary measures such as character count) than
(text)
How does the encoding get set? For example, in xhtml.html I see
If I have
:set enc=utf-8
will I get utf-8 in that line?
Have you actually tested for W3C compliance?
Very minor points: you might want to change the line
if exists("html_font")
to
if exists("g:html_font")
Some readers will find this clearer, and if those lines ever get wrapped
in a function, then it will actually make a difference. Please fix the
indentation in places like this:
- if exists("use_xhtml")
-let s:LeadingSpace = ' '
- else
let s:LeadingSpace = ' '
- endif
HTH --Benji Fisher
Re: bugs in vim scripting highlighting
On Tue, Oct 03, 2006 at 12:00:23PM +0200, Mikolaj Machowski wrote: > Hello, > > Noticed two bugs in vim script highlighting: > > 1. xnoremap and snoremap are not fully recognized. Compare highlighting >of those three lines: > > inoremap CtrlC() > xnoremap CtrlC() > snoremap CtrlC() > >Arguments of xnoremap and snoremap aren't highlighted > > 2. Function element addButton is highlighted as error: > > function! forms#form.addButton(fname, flabel, fvalue, hotkey, listener) > >But it works (as in forms.vim). the same apply to call call. > > syntax/vim.vim version: > " Last Change:May 02, 2006 > " Version:7.0-50 > > m. There is a more recent version at ftp://ftp.vim.org/pub/vim/runtime/syntax/vim.vim If that does not solve the problem, then you should e-mail the maintainer directly. (Dr. C, a.k.a. Chip Campbell, usually follows this list, but a direct e-mail is more reliable.) The Maintainer line is just above the Last Change line you quoted; you will have to remove the non-contiguous letters "NOSPAM" to un-obfuscate the e-mail address. HTH --Benji Fisher
Re: Non-intuitive default behaviour of gI
On Tue, Sep 26, 2006 at 09:14:46PM -0700, Gautam Iyer wrote: > Hi All, > > I noticed that pressing "gI" inserts text at column 1 of the current > line (as documented in the help). > > However given the commands gj and gk, wouldn't it be more intuitive to > have gI insert text at the first screen column? > > I guess I can just do > > nmap gI g0i > > in my ~/.vimrc, but I though I would point out the inconsistent > behaviour. Unless I am missing something, the current meaning of gI is not very useful. Is there any difference between [count]gI and 0[count]i ? (Note that both have the same number of key strokes.) Unfortunately, I think it is too late to change it to something like g0i, which would save a key stroke. I am not convinced by the consistency argument. IIUC, "g" is not a Normal-mode command in traditional vi (and it may be the only alphabetic character with this distinction.) Thus "g" is used in vim for a wide variety of commands, with "g" usually meaning some variant of "". See :help g for a list. HTH --Benji Fisher
Re: better user-definition of paragraphs
On Wed, Sep 27, 2006 at 01:10:12PM +0200, Stefano Zacchiroli wrote:
> Hi all,
>
> playing with formatoptions+=a I stumbled on the 'paragraphs' option
> and I must confess I feel it's quite dumb (probably due to compatibility
> issue with old vi? don't know ...)
Yes, I think that is the problem. Note that ":help 'paragraphs'"
is *not* marked with "{not in Vi}".
I think this is already mentioned in todo.txt:
- Be able to redefine where a paragraph starts. For "[[" where the
'{' is not in column 1.
> My main problem is that I want a way to define where paragraphs start,
> ... even if I'm not writing nroff! Two use cases that may clarify my
> needs:
>
> 1) TeX
[snip]
> 2) Mail
>
> Similarly, I usually write mails in mutt editing headers. I want to
> tell vim that a line starting with ^\u\U+: (an header name at the
> beginning of a line) marks a new paragraphs. Such that the following:
I have been meaning to do that, with some folding and so forth. Do
you have anything worth sharing in ftplugin/mail.vim , or do you use
anything that is already posted on vim.org ?
HTH --Benji Fisher
Re: Convert2HTML Again
On Sun, Sep 24, 2006 at 02:16:27AM +0100, Edd Barrett wrote:
> >>
> >> I beg you, please don't hardcode Courier New!
> >
> >Hear, hear!
> >
> >> Not only is it the worst possible monospaced screen font, it is also
> >> Microsoft specific (in spite of it finding its way onto Tony's Linux
> >> box). (Even Microsoft has seen the light, and changed the default
> >> monospaced font to Consolas in Windows Vista.)
> >>
> >> The proper thing to do is to only list "font-family: monospace".
> >> That will use the default monospaced font on any platform, which is
> >> Courier New by default in any case on current Windows browsers. Only
> >> people who have consciously chosen to change their monospaced font
> >> (and people on non-Windows platforms) will not see Courier New.
> >
> >It's not just the proper way, it's the first thing discussed in the
> >specification:
> >
> > http://www.w3.org/TR/REC-CSS2/fonts.html#font-specification
>
> Again
>
> ...
>
>
> I await a decision
Does that mean that you are waiting for Bram to give his blessing?
IMHO that is not necessary, since the consensus seems to clear. Do not
hard code any font. The simple solution is to leave it at "monospace".
If you, as the author of the patch, are willing to add a few lines of
code, you could check for the existence of a global variable in order to
give the user a little more control. Something like
if exists("g:2html_font")
let s:msfont = g:2html_font . ", monospace"
else
let s:msfont = "monospace"
endif
or the more compact
let s:msfont = (exists("g:2html_font") ? g:2html_font . ", " : "") . "monospace"
and then use the s:msfont variable later in the script. Then, the
occasional user who cares can either set
let g:2html_font = "myFavoritefont, Courier New"
in his or her vimrc file or even define it before :source'ing 2html.vim .
The more complex solution would satisfy one of the design goals:
:help design-flexible
HTH --Benji Fisher
Re: Convert to HTML patch. Opinions / Testing.
On Fri, Sep 15, 2006 at 01:37:57PM +0100, Edd Barrett wrote: > On 15/09/06, Benji Fisher <[EMAIL PROTECTED]> wrote: > >I think the decision of > >whether to include the tags should be based on principles of logical > >mark-up: are these naturally paragraphs? > > This depends upon if you are writing a book or some code. The spacing > of the lines should be governed by the whitespace of the sourcecode, > and I cant think of how you define a "paragraph of code". > > But consider this: > The whole file is contained in a , so the gap introduced (if any) > will either be right at the top or bottom of the code (or both?), > neither of which are benificial to the format of the page. > > Agree? I agree that enclosing the whole file in and tags is not very helpful. HTH --Benji Fisher
Re: Convert to HTML patch. Opinions / Testing.
On Thu, Sep 14, 2006 at 08:27:01PM +0100, Edd Barrett wrote: > On 14/09/06, Mikolaj Machowski <[EMAIL PROTECTED]> wrote: > > Dnia sobota, 9 września 2006 20:03, Edd Barrett napisał: > >> > >> - I removed 's because you cannot contain a in a according > >> to w3. An unstyled would make no difference in this case anyway. > > > >While I agree with most of your changes *where* cannot be inside of > >? > > > >m. > > Your right. You can have spans in p's.. hmmm . I could have swore the > validator moaned at me the first time i tried it. > > Still the 's wouldnt make any difference to formatting in this > case. If you really want them back I can alter the patch, but I dont > really see the need. > > best Regards > > Edd I was wondering about that, too, but I was too shy to ask. It depends on the browser whether the tag makes any difference to the display; some browsers may leave extra space. I think the decision of whether to include the tags should be based on principles of logical mark-up: are these naturally paragraphs? my $0.02--Benji Fisher
Re: Fixed: prevent slowness from Insert mode completion
On Thu, Sep 14, 2006 at 09:06:49AM +1000, Peter Hodge wrote: > > --- Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > The word "stop" doesn't really describe well what its effect is. > > > > There are other situations where you would like to stop completion, not > > only with backspace. Especially when using "longest". I would suggest > > using a regexp pattern for this. So that you could do: > > > > :set completeopt+=stop=[-.[:backspace:]] > > > > This would stop completion when typing backspace, '.' or '-'. > > > > No, it does in fact stop completion on every character typed (unless I've done > something wrong and it only *sometimes* works, but it does work 100% > consistently for me). I'm not sure the feature would be popular enough to > warrant an entire regex to specify the 'stop' characters, and at any rate, I > don't think I'd be up to the task. > > Thank you for feedback, > Peter If the patch works as described, I think it is worth including in its present form. I, for one, would include "stop" in 'completeopt'. I cannot think of a reason I would want to end completion when I type some characters but not others. my $0.02--Benji Fisher
Re: testing patchlevel from script
On Sun, Sep 10, 2006 at 01:05:11PM +, Yakov Lerner wrote:
> How can a script test for specific patchlevel ?
> For example, I have vim 7.0.86 and I need to check in the script that
> patchlevel is >= 7.0.86. But v:version is 700. How ? It would be
> nice if to have patchlist available through some v: variable.
I agree that a List of patch numbers would be convenient. You can
test for a specific patch with has("patch86").
:help has-patch
HTH --Benji Fisher
Re: Convert to HTML patch. Opinions / Testing.
On Sat, Sep 09, 2006 at 07:03:14PM +0100, Edd Barrett wrote: > > Here is the patch: http://arameus.net/users/edd/vim-test/2html.vim.diff > > Also in the same directory you will see the output of my tests, please > test them on other browsers. I viewed the output using the following systems and browsers: Linux, Mozilla 1.7.12 Windows XP, Mozilla 1.7.12 and IE 6.0.2900.2180.xpsp_sp2_gds.050301-1519 Mac OS X, Mozilla 1.7.12, IE 5.2.3, OmniWeb 4.5, and Safari 1.3.2 Note that two of the Mac browsers are a couple of years old. The pages all looked pretty much the same. On IE/Mac, the CSS versions seemed to use slightly smaller fonts than the non-CSS versions. In several browsers, the CSS versions had a little more "white" space at the top of the screen than the non-CSS versions. (Maybe because of the tags?) I do not see any problems in my browsers, so I vote in favor of improved compliance with the W3 standards. Minor point: in http://arameus.net/users/edd/vim-test/xhtml_no_css.html (XHTML without CSS) there are some "empty" tags such as . Isn't the standard advice to add a space before the slash, as in ? I think this still complies with the standard, and it is supposed to be easier for some older browsers to parse. > I am completely new to your development community (but I've been using > vim for many years), so I aplogize if I have broken any coding style > rules/other rules. =) I like to think that we are not too picky. Thanks for the contribution. HTH --Benji Fisher
Re: matchparen tweak
On Wed, Sep 06, 2006 at 02:15:36AM +0200, A.J.Mechelynck wrote:
> Benji Fisher wrote:
> >
> > Now that the problem has been pointed out, I think the patch should
> >be made in the official distribution. How about (simple but oh, so
> >clever)
> >
> > let plist = split(&matchpairs, '.\zs.')
> >
> >which removes every second character? Will that have trouble with
> >multibyte characters? Are these even allowed in 'matchpairs'?
>
> The help for 'matchparen' mentions only "single characters" which "must
> be different". You might try it with Arabic "ornate parentheses", U+FD3E
> (left i.e. closing) and U+FD3F (right i.e.opening), which are obviously
> meant to pair with each other.
I assume you mean the help for 'matchpairs', not 'matchparen'. I
tried
:let &mps = "\uFD3E:\uFD3F"
:set mps?
and the value was not changed. I think the docs should be changed to
mention that multi-byte characters are not allowed; as I read it,
"single characters" does not rule out multi-byte characters. I also do
not like the absence of an error message. I guess this is an issue with
:let & since I do get an E474 from
:set mps=uFD3E:uFD3F
(*not* typed literally).
> IIUC, a dot in a pattern matches one character, which may be one or more
> bytes, and which may occupy one screen cell, two for a wide CJK
> character, one to eight for a tab, etc.
Yes, and
:echo split("\uFD3E:\uFD3F", '.\zs.')
returns ['﴾', '﴿'] as expected. So I think my proposal for
matchparen.vim is safe even if 'matchpairs' is changed to allow
multi-byte characters.
HTH --Benji Fisher
matchparen tweak (was: vim 7 errors)
On Wed, Sep 06, 2006 at 01:20:13AM +0200, A.J.Mechelynck wrote: > > It's supposed to treat ? and : on the one hand, and = and ; on the other > hand, as "paired brackets". However, the matchparen plugin uses a rather > elementary algorithm to split 'matchpairs' into individual items: any > colons and commas are regarded as delimiters, and then odd "parts" are > treated as "left brackets", even ones as "right brackets". Good catch. I think the line you are referring to is let plist = split(&matchpairs, ':\|,') in $VIMRUNTIME/plugin/matchparen.vim . > I see the following possible cures, use only one of them: > (a) disable matchparen matching > > :set loaded_matchparen = 1 > > (b) remove the questionable pair "?::" from the 'matchpairs' options > > (c) patch plugin/matchparen.vim to refine the splitting algorithm, so > that a colon should be treated as either a separator or a "bracket" > depending on position within the option. Now that the problem has been pointed out, I think the patch should be made in the official distribution. How about (simple but oh, so clever) let plist = split(&matchpairs, '.\zs.') which removes every second character? Will that have trouble with multibyte characters? Are these even allowed in 'matchpairs'? HTH --Benji Fisher P.S. cc'ed to vim-dev for further discussion
Re: Fixing cweb.vim
On Sat, Sep 02, 2006 at 01:36:06AM +0300, Ilya wrote:
> Benji Fisher wrote:
> >On Fri, Sep 01, 2006 at 09:36:55AM +0300, Ilya wrote:
> >
> >>David Brown wrote:
> >>
> >[...]
> >
> >>>However, tex.vim frequently will enclose large sections of the document
> >>>within a region and the cweb.vim which the webCRegion is not part of.
> >>>
> >>>I think I can fix this by adding an appropriate containedin=... field to
> >>>the definition of webCRegion.
> >>>
> >>>What I'm having difficulty with is figuring out what to put there. Is
> >>>there a way of finding out what region a given part of the buffer is in?
> >>>
> >>From :help synID
> >>
> >> Example (echoes the name of the syntax item under the cursor): >
> >> :echo synIDattr(synID(line("."), col("."), 1), "name")
> >>
> >
> > IIUC, synIDattr() always returns a syn-match or syn-keyword group.
> >It does not tell you whether you are in a syn-region.
> >
> >HTH --Benji Fisher
> >
> It does return region names for me.
So it does, but only if there is no active match nor keyword at the
cursor. What I should have said is that synIDattr() (or maybe I should
say synID()) reports only the "innermost" syntax item at the cursor.
For example,
:help r
:normal 6j0
:echo synIDattr(synID(line("."), col("."), 1), "name")
reports helpLesdBlank but does not mention that this syn-match (defined
with "contained") is inside a helpExample syn-region. (Verify this by
moving the cursor to the first non-blank on the lins.)
In brief, synID() *sometimes* reports the current syn-region, and I
do not think this is good enough for David Brown's purposes.
HTH --Benji Fisher
Re: Fixing cweb.vim
On Fri, Sep 01, 2006 at 09:36:55AM +0300, Ilya wrote:
> David Brown wrote:
[...]
> >However, tex.vim frequently will enclose large sections of the document
> >within a region and the cweb.vim which the webCRegion is not part of.
> >
> >I think I can fix this by adding an appropriate containedin=... field to
> >the definition of webCRegion.
> >
> >What I'm having difficulty with is figuring out what to put there. Is
> >there a way of finding out what region a given part of the buffer is in?
> From :help synID
>
>Example (echoes the name of the syntax item under the cursor): >
>:echo synIDattr(synID(line("."), col("."), 1), "name")
IIUC, synIDattr() always returns a syn-match or syn-keyword group.
It does not tell you whether you are in a syn-region.
HTH --Benji Fisher
Re: better recognising of tex vs plaintex filetype
On Wed, Aug 30, 2006 at 10:36:09AM -0700, Gautam Iyer wrote:
> On Wed, Aug 30, 2006 at 07:17:16PM +0200, Stefano Zacchiroli wrote:
>
> > > I agree with the comment that plain TeX users may also define such
> > > sectioning commands. Maybe it would be safe if you check for such
> > > definitions, using an include-file search ... but of course, that is
> > > more convenient after ftplugin/plaintex.vim has been :source'd.
> >
> > I'm not really fond of plain TeX, but I think it is not really
> > widespread to \input slices of plain TeX. So the idea mentioned in
> > this thread was to implement the policy: "if a document starts with a
> > lot of blanks followed by one of the possible LaTeX sectioning
> > commands, then it is (probably) a LaTeX source file". What do you
> > think of this policy?
I think my undergraduate thesis (1985, plain TeX, just about the
time the first version of LaTeX came out) was structured that way (i.e.,
split into separate files, each beginning with a \chapter command or
something like that. (My thesis was also my introduction to vi.)
I also had several collections of macros, so my TeX files usually
started out with
\magnification 1200
\input standard
\input math
\input smiley
or something like that. I do not recall whether I defined any
sectioning commands in these files.
Now that you describe your proposed policy more, I like it a little
better. Specifically, I like the idea of looking at the first
non-comment, non-blank line, since that gets around the problem that
something that *looks* like LaTeX might be defined in an \input file. I
would like it better if it were more conservative. The problem is that
the LaTeX sectioning commands are not very LaTeX-y: if you were looking
for
\begin{chapter}
instead of
\chapter
then I would be a lot happier.
> I actually like this policy a lot. Most people who break latex files up
> into tonnes and tonnes of little files, do so based on sections. Odds
> are, that the little files will begin with a bunch of comments, and a
> sectioning command.
>
> It would make life easier if this made it into filetype.vim. Especially
> because changing g:tex_flavor means that every time I edit a plain tex
> file, I need to unlet this variable.
Another option is to add one of the lines
%&plain
%&tex
%&pdfplain
or
%&pdftex
at the top of the plain TeX files (assuming that they are your own).
This is the most reliable method for determining file the TeX flavor,
since it overrides a format specified on the command line:
$ latex myfile
will *not* load the LaTeX format if myfile.tex starts with one of the
above lines. The only problem (unless this has changed since the last
time I checked) is that the pdftex program is not smart enough to change
%&plain to %&pdfplain .
For now, I suggest doing what you think is right in the Debian
package. If plain TeX is really as rare as you think (I do not
disagree, but I am willing to be surprised!) and there are no
complaints, then I might vote for a change to the vim distro based on
feedback from Debian users.
HTH --Benji Fisher
vim mailing lists
On Sun, Aug 27, 2006 at 02:40:24PM +0200, Bram Moolenaar wrote:
>
> Apparently the sorbs blacklist mechanism is still being used, causing
> trouble for some people. I have asked the mail server maintainer to
> remove sorbs a few times now...
Twice recently, sorbs has bounced my mails to the list because some
server between my ISP and the vim-dev list is on its blacklist.
Do you have any plans to move the vim mailing lists to a new
server, where you (or someone more responsive) has administrative
control?
--Benji Fisher
Re: better recognising of tex vs plaintex filetype
On Tue, Aug 29, 2006 at 09:16:41PM +0200, Stefano Zacchiroli wrote:
> On Tue, Aug 29, 2006 at 03:06:39PM -0400, Benji Fisher wrote:
> > I do not think there is any reliable way to distinguish between
> > plain TeX and LaTeX. After my RFC, I decided to treat plain TeX as the
> > default, since it is the more basic, even though I agree that LaTeX is
> > probably far more common now. I suggest adding
> >
> > let tex_flavor = "latex"
> >
> > to your vimrc file.
>
> Hi Benji, thanks for your feedback.
>
> In my mail I was more talking as the maintainer of the vim package (and
> of the vim-latexsuite add-on), than as a vim user. Since I've been
> bugged by users asking for more recognition of LaTeX I was wondering if
> you agree to change the vim-wide default, instead of changing it on a
> per-user basis.
If you maintain a vim package (for Debian, guessing from your
sig?), then you can always define g:tex_flavor in a system vimrc if you
want. BTW, the documentation for this is under
:help ft-tex-plugin
Having already made the decision one way after a RFC, I am reluctant to
reverse it. If I then get a rash of complaints from plain TeX and
conTeXt users, would I have to reverse it again?
> Since you agree that LaTeX is more common, what is exactly your argument
> against having it as the default?
Plain TeX came first, so it has priority. (Maybe LaTeX 2ε is an
independent format, but I remember when LaTeX first came out that it was
actually a bunch of \def's made on top of plain TeX.) This is the same
logic that leads to keeping vi-compatible regular expressions, despite
the persistent suggestions that vim adopt PCRE.
Defaults should cater to users who do simple things, and plain TeX
is simpler than LaTeX. Writing LaTeX and splitting your document among
multiple files (so that most of them do not have the \begin{document}
line) is complicated, and anyone doing this should be willing to
customize his or her vimrc file appropriately.
Please read the thread on this list started Mar 2, 2006, with the
subject
RFC: filetypes for TeX, LaTeX, ConTeXT (others?)
> Beside that, I agree with the other proposal in this thread of
> recognizing as LaTeX files which starts with a sectioning command (after
> several possible blanks of course), and I'm going to implement it.
>
> Any comments on that choice?
Do you mean you plan to implement it as a proposed modification to
$VIMRUNTIME/filetype.vim in the standard distribution, or a change to
your vim package? I agree with the comment that plain TeX users may
also define such sectioning commands. Maybe it would be safe if you
check for such definitions, using an include-file search ... but of
course, that is more convenient after ftplugin/plaintex.vim has been
:source'd.
HTH --Benji Fisher
Re: better recognising of tex vs plaintex filetype
On Sat, Aug 26, 2006 at 01:38:11AM +0200, Stefano Zacchiroli wrote:
> [ Forwarded to vim-dev, as requested by Bram. Consider both the patch
> and the suggested default change as RFCs ]
>
> Hi Bram,
> could you please consider the attached patch for filetype.vim? It
> provides better recognition of 'tex' filetypes against 'plaintex' ones.
> It looks for sectioning commands that are specific to latex (\part,
> \section, \paragraph, ...).
>
> Also, according to a comment in filetype.vim, the code distinguishing
> between 'tex' and 'plaintex' should default to 'tex', whereas, according
> to these lines:
>
> " Default value, may be changed later:
> let format = exists("g:tex_flavor") ? g:tex_flavor : 'plain'
>
> I assume it defaults to 'plaintex'. Is there a reason for that or it is
> just a typo? I found the default to 'tex' much more reasonable, as most
> of people write latex these days ...
>
> What about changing it so that it matches the comment?
>
> Many thanks in advance,
> Cheers.
I believe that Bram does not use any version of TeX himself. I
maintain the plaintex and latex ftplugins, and I suggested the current
detection scheme (after a RFC before vim 7.0 was released). If the
comments, documentation, and code do not agree, it is probably my fault.
I do not think there is any reliable way to distinguish between
plain TeX and LaTeX. After my RFC, I decided to treat plain TeX as the
default, since it is the more basic, even though I agree that LaTeX is
probably far more common now. I suggest adding
let tex_flavor = "latex"
to your vimrc file.
HTH --Benji Fisher
Re: Netrw and cindent
A quick look at netrw.vba.gz (searching for "swf") suggests that
this may be the problem:
fun! netrw#NetBrowseX(fname,remote)
[snip]
if a:remote == 1
set bh=delete bt=nofile noswf
exe "norm! \"
redraw!
endif
" call Dret("NetBrowseX")
endfun
All the other matches for "swf" involve either :setlocal or :let &l: .
I did not see anything suspicious with "cin".
HTH --Benji Fisher
On Tue, Aug 22, 2006 at 07:51:57PM -0700, Mark S. Williams wrote:
> Chip,
>
> Thanks for your response. I downloaded v103f and tried it. It didn't
> seem to help. After much experimenting I found that if I enabled
> filetype indent in my .vimrc, the problem with cindent goes away, as
> :verbose setl cindent? now reports last set by the Java indent file. I
> don't understand why, but it works.
>
> But I still see an issue with the swapfile option being turned off by
> netrw. To test, I unset my HOME environment variable to eliminate my
> .vimrc and all my installed plugins. Then when I repeat the 2 scenarios
> from my original post, noswapfile is set and :verbose setl swf? reports
> noswapfile last set by netrw.vim.
>
> BTW, I'm running GVim on XP.
>
> -Mark
>
>
> Charles E Campbell Jr wrote:
> >Mark S. Williams wrote:
> >
> >>I think I've uncovered an odd bug involving Netrw and the cindent
> >>local buffer option for Java files, where cindent is unset under
> >>certain conditions.
> >
> >I'm afraid that I don't see this problem; I tried both your examples.
> >Please try v103f from my website:
> >
> >http://mysite.verizon.net/astronaut/vim/index.html#VimFuncs , see
> >"Network Oriented Reading, Writing, and Browsing".
> >
> >If this problem continues to occur, then its likely some setting or
> >other plugin is interfering (the latter most likely via an autocmd).
> >
> >Regards,
> >Chip Campbell
> >
Re: more on local additions in help.txt -- debian bug?
On Wed, Aug 16, 2006 at 03:33:42PM -0400, Gabriel Farrell wrote: > > Aha. Benji's explanation is correct. My $VIM points at > /usr/share/vim/addons/ which contains doc/matchit.txt, doc/tags, and > plugin/matchit.vim. This is the default for the Debian installation. > The screwy thing is that unless I copy matchit.vim into > $HOME/.vim/plugin/, matchit isn't installed, and I can't see any help > for it because, as you surmised, :helptags hasn't been run on > /usr/share/vim/addons/doc/ -- the tags file in that directory is > empty. > > I'm not sure if this is a bug in vim or the debian package; I think > mostly the package. > > gabe I think you are right that the package only partially installs the plugin. Just to be clear, there are three related things; I will use to denote a path that is in the 'runtimepath' option. (1) A line appears under :help local-additions if /doc/matchit.txt exists. (2) A tags file for /matchit.txt is created if you run :helptags and :help will find those tags if is in 'runtimepath'. (3) The plugin will be effective if /plugin/matchit.vim exists. This particular plugin also relies on /ftplugin/*.vim to set buffer-local variables that control its behavior. HTH --Benji Fisher
Re: more on local additions in help.txt
On Wed, Aug 16, 2006 at 02:18:55AM +0200, A.J.Mechelynck wrote: > Gabriel Farrell wrote: > >Hi, > > > >Regarding a thread [1] back in February on this list about local > >additions, I'm not seeing some of the errors remarked upon at that > >time, but I do see 'matchit.txt' under the LOCAL ADDITIONS heading > >even when it's not installed. If I do copy it into the doc directory > >and run helptags, it's listed twice. A minor annoyance, to be sure. > > > >gabe > > > >[1] http://marc.theaimsgroup.com/?t=11395267213 > > What you see there may depend on how you update your Vim runtime files, > and when you last did. I do it by downloading the contents of > ftp://ftp.vim.org/pub/vim/runtime/ except its dos/ subdirectory, my > help.txt is dated: > > *help.txt*For Vim version 7.0. Last change: 2006 Jun 16 > > I have matchit.txt (and two more files) in $VIM/vimfiles/doc, and I see > > LOCAL ADDITIONS: *local-additions* > |matchit.txt| Extended "%" matching > |pi_netrw.txt| For Vim version 7.0. Last change: 2006 Jun 08 > |pi_vimball.txt| For Vim version 7.0. Last change: 2006 Jun 19 > > -- > > > Running "less" on the same file shows that the LOCAL ADDITIONS section > is actually empty in the file as it resides on disk. You might want to > open it with a text editor other than Vim, and remove all non-blank > lines between LOCAL ADDITIONS and the horizontal line. > > > Best regards, > Tony. If there are any non-blank lines there, I would consider the file corrupted. The documentation on this feature is a little terse. Using :helpgrep local-add leads to :help write-local-help which explains where those lines come from. The surprising thing (for me) is that these lines are added whether or not :helptags has been run on the directory containing the doc files. I did not figure this out until I looked at the source: vim70/src $ grep local-add *.c vim70/src $ vim ex_cmds.c /local-add According to the comments there, vim builds the "LOCAL ADDITIONS" section by looking for doc/*.txt in every 'runtimepath' directory other than $VIMRUNTIME and extracting the first line. Conclusion: if you have a line for matchit.txt under LOCAL ADDITIONS, then you probably have doc/matchit.txt somewhere in your runtime path; if you have duplicate entries, then you have duplicate files. It does not matter whether you have installed the help files with :helptags . Does this explain what you see? HTH --Benji Fisher
Re: Invoke _gvimrc.vim / unexpected expansions
On Fri, Aug 11, 2006 at 07:07:58AM -0400, James Vega wrote: > On Fri, Aug 11, 2006 at 08:43:10AM +0200, jandl wrote: > > Dear colleagues, > > I have 2 problems with gvim > > > > 1/ when I start gvim in Windows XP (double click on icon), gvim opens > > without invoking the _gvimrc.vim. I have _gvimrc.vim located in > > c:\programs\vim. I have also tried to put _gvimrc.vim into > > c:\programs\vim\vim70 but it was not automatically started from there > > either. > > > > 2/ I am using gvim for edition my latex files and have the Latex-Suite > > as an add-in. That has generated some conflict: whenever I press a '.' > > I get '=SmartDots()'. > > > > Here is my _gvimrc.vim: > > [snip] > > " To use it, copy it to > > " for Unix and OS/2: ~/.gvimrc > > " for Amiga: s:.gvimrc > > " for MS-DOS and Win32: $VIM\_gvimrc > > As your _gvimrc says, there should be no ".vim" extension on your > _gvimrc (or _vimrc). :) That will fix 1). > > As for 2), you may have to edit the plugin to change that mapping so it > doesn't override a normal Vim command. I think there is a good chance that, since the gvimrc file is never :souce'd, the OP is running with 'compatible' set, and that this causes the problem. If so, then fixing the first problem will fix the second. HTH --Benji Fisher
Re: [RFC] fixing wrt '\\ ' handling
On Thu, Aug 10, 2006 at 11:38:25PM +0300, Yakov Lerner wrote:
> " XX \\ works, 2 args ('\\')
Is that correct?
> " XX a bworks, 2 args ('a','b')
> " XX a\ b works, 1 arg ('a b')
> " XX a\\b 1 arg ('a\\b') Shall it be 1 arg('a\b') ?
So I guess " XX a\b" gives 1 arg ('a\b') ?
> " XX a\\ b bug: 1 arg('a\ b') Expected 2 args('a\','b')
> " XX a\\ b bug: 2 args ('a\ ','b'). Expected 2 args('a\','b')
I agree with Matthew on this. If '\\' will be used for '\' in some
situations, it is easier to remember if it always means that. So if you
want 'a\b', use 'a\\b' and if you want 'a\\b', then use 'ab'.
$0.02 --Benji Fisher
P.S. I cannot resist tweaking a vim function:
> command! -nargs=* XX :call Test()
> fun! Test(...)
> echo "XX: ".a:0." args("
echo "XX:" a:0 "args("
Both :echo and :execute (!) accept multiple arguments.
> let i=1
> let argc=a:0
Warning: variable argc is defined but never referenced.
> while i <= a:0
> echon "'".a:{i}."'"
> if i != a:0 | echon "," | endif
Instead of the above two lines, I prefer
echon "'" . a:{i} . "'" . (i != a:0 ? "," : "")
> let i = i + 1
> endwhile
> echon ")"
> endfun
Re: No way to color-region(s) of text -- highlighter mode.
Vim does a lot of optimization of regular expressions, but I do not know how it would perform in this case. I would just try it and see. If it does not work well, that would be a good reason to try :syn match instead of :match . HTH --Benji Fisher On Sun, Aug 06, 2006 at 09:59:31AM -0700, Mohsin wrote: > I can try making a large regexp. I was under the impression that > alternating regexps can be exponentially slow. Is %l %c %v matching > is implemented in constant time? ie. Does vim try to match the regexp > at every point - or it can optimize and start matching from the given line? > Nothing to do with implementation just the hard theoretical limit, > I am afraid, this might not work on slower machines. > > thanks > mohsin > > On 8/5/06, Benji Fisher <[EMAIL PROTECTED]> wrote: > > > > I think that Tony mentioned > > > >:help /\| > > > >in a previous post, but maybe you missed it. I just tried > > > >:highlight User1 term=bold,underline cterm=bold,underline > >gui=bold,underline > >:match User1 /\%>3l.\%<7l\&\%>3v.\%<7v\|\%>12l.\%<18l\&\%<33v.\%>20v/ > > ^^ > > > >and it marked two rectangular regions in this e-mail. I admit that this > >is just a proof of concept, not very convenient to use. It should not > >be too hard to store a List of Lists, each inner list giving the > >boundaries of a rectangle (four Numbers), and then to write a function > >that processes this list to :execute the appropriate :match statement. > >Then another function could add or remove Lists to the outer List. > > > >:help List " vim 7.0 only > >:help :for " ditto > > > > It is also possible to use ":syn match" instead of ":match". Each > >approach has some advantages. Without knowing how you would want to use > >such a feature, I do not know which would be more appropriate. > > > >HTH --Benji Fisher > >
Re: No way to color-region(s) of text -- highlighter mode.
On Fri, Aug 04, 2006 at 04:01:38PM -0700, Mohsin wrote: > > On 8/4/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: > >A.J.Mechelynck wrote: > >> Mohsin wrote: > >>> I want to use a highlighter mode on my text file, example: > >>> > >>> :color_region bold line1 col1 line2 col2 > >>> :color_region bold 5 5 6 6 > >>> :color_region underline 5 5 6 6 [snip] > >> > >> Vim regexps allow you to specify line and/or column numbers. Example, to > >> match a block defined by lines 55 to 77, virtual columns 15 to 37, and > >> highlight it in bold-underlined text: [snip] > >> :highlight User1 term=bold,underline cterm=bold,underline > >> gui=bold,underline > > > >After testing, the above regexp won't work but this one will: > > > > :match User1 /\%>54l.\%<78l\&\%>14v.\%<39v/ [snip] > > > >Best regards, > >Tony. > > > I already tried your solution, it only works for a single region at a time > On applying the same higlighting to second region and the first one is > un-highlighted. > > Try this (the third command will unhilight the first region): > > :highlight User1 term=bold cterm=5 guibg=red > match User1 /\%>54l.\%<78l\&\%>14v.\%<39v/ > match User1 /\%>84l.\%<88l\&\%>14v.\%<39v/ > > - mohsin. I think that Tony mentioned :help /\| in a previous post, but maybe you missed it. I just tried :highlight User1 term=bold,underline cterm=bold,underline gui=bold,underline :match User1 /\%>3l.\%<7l\&\%>3v.\%<7v\|\%>12l.\%<18l\&\%<33v.\%>20v/ ^^ and it marked two rectangular regions in this e-mail. I admit that this is just a proof of concept, not very convenient to use. It should not be too hard to store a List of Lists, each inner list giving the boundaries of a rectangle (four Numbers), and then to write a function that processes this list to :execute the appropriate :match statement. Then another function could add or remove Lists to the outer List. :help List " vim 7.0 only :help :for " ditto It is also possible to use ":syn match" instead of ":match". Each approach has some advantages. Without knowing how you would want to use such a feature, I do not know which would be more appropriate. HTH --Benji Fisher
Re: foldmethod=expr very slow
On Wed, Jul 26, 2006 at 03:33:55PM -0500, Thore B. Karlsen wrote:
>
> Well, I think I've found a solution that works for me. It turns out
> that what was causing my problems was where vim interpreted a number
> following a marker as a fold level. A line like this would mess up my
> folds:
>
>int array[16] = {0};
>
> In those cases it's easy enough to insert a space before the 0, but
> there are cases where it's not that easy, or not desireable.
>
> What I ended up doing was changing fold.c to not look for a fold level
> after a marker, and recompiling. Now everything seems to work great,
> and I don't notice any slowdown.
>
> Perhaps there should be an option for not interpreting numbers after a
> fold marker as a fold level, but I don't know if this is causing
> enough people grief that it would be included. I'm happy with my quick
> fix for now.
I am surprised that {0} is recognized as a fold marker. Do you
have 'foldmarker' set to the default value of {{{,}}} or something else?
In my limited tests (try zc in Normal mode and see whether vim throws an
error message) {0} is not recognized as a fold marker but {{{0}}} is.
HTH --Benji Fisher
Re: Bug in :runtime ?
On Wed, Jul 26, 2006 at 07:45:12AM +0200, A.J.Mechelynck wrote: > Bill McCarthy wrote: > >Hello Vim Developers, > > > >I was timing the startup process by stepping though what I > >think Gvim does (on Win XP Pro with 7.0.42). > > > >gvim -u NONE -N > > > >That starts up without _vimrc or _gvimrc or plugins and sets > >nocp. > > > >:so $vim\_vimrc > > > >worked fine. > > > >:so $vim\_gvimrc > > > >also worked fine. > > > >:ru! plugin\**\*.vim > > > >didn't seem to do anything. Repeating the above as > > > >:verb ru! plugin\**\*.vim > > > >reports: not found in 'runtimepath': "plugin\**\*.vim" > > > >Hmm, when I tried again with the unixy > > > >:ru! plugin/**/*.vim > > > >the plugins were finally sourced. > > > >Bug? > > > > IIUC, it's a feature: \* means a literal asterisk. Not a very good > feature since IIUC, asterisks are not allowed in filenames on Windows. > Or can they happen in long file names? Right, as explained under :help dos-backslash (There is not enough detail there to predict what vim will do in this particular situation, though.) This might also work (but I am not going to find a W32 box to test it, sorry): :ru! plugin\\**\\*.vim HTH P.S. Maybe something should be added under :help wildcard or :help starstar-wildcard to explain using \**\ on DOS-like systems. In fact, after reading that, it seems to me as though \**\ *should* be interpreted as path separator, wildcard, path separator in this case.
Re: Crazy wish: vimcat
On Fri, Jul 21, 2006 at 03:31:15PM -0500, mwoehlke wrote: > Is this possible? It just occurred to me that it would be great if there > was a VIM-related program that would 'cat' in color using VIM's > highlighting rules. Is this something that VIM could be made to do via > scripting, or would it need to be a totally new program? If the latter, > any guesses how hard it would be to make such a critter? > > I notice that "echo ':q' | vim " sort-of works... it gives the > first page, plus trailing '~'s (if less then a page), although this > wouldn't work with TERM's where curses displays are a separate buffer > (like 'xterm', but not 'linux'). Maybe this is what you want: http://www.vim.org/tips/tip.php?tip_id=121 HTH --Benji Fisher
Re: VIM7 on Tandem OSS
On Wed, Jul 19, 2006 at 03:51:36PM -0500, mwoehlke wrote: > > Well, I'll hope for a reply from Bram. I'm used to projects that don't > appreciate people shooting e-mail off to any particular individual when > there is a designated list/forum. :-) Vim is different from most open-source projects in several ways. I think the basic difference is that it is controlled by one person, which would not be possible with a much larger project like mozilla or Open Office. Other differences follow from Bram's personal preferences. The official code is what he says it is, and no one else has access (e.g. by CVS) to change it. I think he once said, "I am vim's bug-tracking system." I think Bram is somewhere in the process of moving to (or near) Zurich and starting work at Google, so please be patient. > So nice to have the keys behave, though. :-) > (While we're on the subject, can someone remind me how to *make* a > .patch? Is it just 'diff -u' or is there something special in getting > the multiple-files-in-one-output-block right?) I think that "diff -c" is preferred. I wrote a tip on generating patches: http://www.vim.org/tips/tip.php?tip_id=618 . That tip does not mention multiple files, though. You can either concatenate the diff output or use "cvs diff" (if you happen to be using cvs). HTH --Benji Fisher
Re: question for charles (or anyone): netrw whacking t
On Wed, Jul 12, 2006 at 01:24:51PM -0400, Charles E Campbell Jr wrote:
> Benji Fisher wrote:
>
> >I think I see the problem. In $VIMRUNTIME/autoload/netrw.vim , in
> >the function netrw#DirBrowse() , there are the lines
> >
> > if &fo =~ '[ta]'
> > set fo-=t
> > set fo-=a
> > echohl Warning
> > echo '***warning*** directory browsing and formatoptions "ta" are
> > incompatible'
> > echohl None
> > endif
> >
> >(I am not sure that I ever get to see that warning message.) I think
> >that replacing :set with :setlocal will fix the problem. Remember, when
> >dealing with a local option, :set changes both the local value and the
> >global default; :setlocal changes only the value...
> >
> >I think it should be
> >
> > :let &l:spell = ...
> >
> >
> Actually, I don't want to use local settings; just obstinate, I guess!
> What netrw v102h does
> (and its available at my website,
> http://mysite.verizon.net/astronaut/vim/index.html#VimFuncs
> as "Network Oriented Reading, Writing, and Browsing) is save global
> settings, make them
> netrw-friendly, do the browsing thing, restore the settings.
In that case, use the &g: prefix. For example, try the following
experiment:
:set spell
:new
:setl spell!
:echo &spell &l:spell &g:spell
I think you should get
0 0 1
(as I do). So &spell references the local value of the option, not the
global value. Now, consider the lines
let w:spellkeep = &spell
...
if exists("w:spellkeep")|let &spell = w:spellkeep |unlet w:spellkeep|endif
in $VIMRUNTIME/autoload/netrw.vim . The first sets w:spellkeep to the
local value, and the second sets the global value.
Bottom line: while testing the OP's problem before my original
post on this thread, I did find that options ended up being set in ways
I did not want nor expext, and
:verbose set spell?
told me that netrw was the culprit.
HTH --Benji Fisher
Re: question for charles (or anyone): netrw whacking t
On Tue, Jul 11, 2006 at 06:53:23PM -0500, scott wrote:
> charles--
>
> i have formatoptions set in my .vimrc to tcroqn
>
> i have a script i call gvime that starts 'vim -g -c Explore'
> (i tried 'gvim -c Explore' with the same result)
>
> if i run gvime, and select a file to edit, i find
> formatoptions is now croqn -- the t has been whacked,
> and even with a modeline setting textwidth, i am
> manually formatting paragraphs, running scriptnames,
> and generally having a bad day
I think I see the problem. In $VIMRUNTIME/autoload/netrw.vim , in
the function netrw#DirBrowse() , there are the lines
if &fo =~ '[ta]'
set fo-=t
set fo-=a
echohl Warning
echo '***warning*** directory browsing and formatoptions "ta" are
incompatible'
echohl None
endif
(I am not sure that I ever get to see that warning message.) I think
that replacing :set with :setlocal will fix the problem. Remember, when
dealing with a local option, :set changes both the local value and the
global default; :setlocal changes only the value.
I think other options are being affected, too. I am too
bleary-eyed to be sure, but I think that 'spell' and 'tw' in other
buffers are being affected by the netrw window. I think the problem
comes from lines like
if exists("w:spellkeep")|let &spell = w:spellkeep |unlet w:spellkeep|endif
if exists("w:twkeep") |let &tw = w:twkeep |unlet w:twkeep |endif
Instead of
:let &spell = ...
I think it should be
:let &l:spell = ...
:help local-options
:help expr-option
HTH --Benji Fisher
Re: oddity with :noautocmd when editing a help file
On Thu, Jul 06, 2006 at 01:19:48PM -0400, Charles E Campbell Jr wrote: > Benji Fisher wrote: > > >How did 'filetype' get set to "help"? > > > > > > Dr BF! You forgot one of your favorite answers! :) Try > > :verbose set ft? > > (it was probably set via a modeline at the bottom of the help page) Right you are. Thanks! --Benji Fisher
oddity with :noautocmd when editing a help file
Bug or feature? While editing this e-mail, :set ft=log :set ft? syntax? filetype=log syntax=log :noa e! "/tmp/mutt-localhost-19331-88" "/tmp/mutt-localhost-19331-88" 7L, 108C :set ft? syntax? filetype=log syntax=log as expected. While editing a help file, :set ft=log :set ft? syntax? filetype=log syntax=log :noa e! "autocmd.txt" "autocmd.txt" [readonly] 1260L, 52535C :set ft? syntax? filetype=help syntax=log How did 'filetype' get set to "help"? --Benji Fisher
Re: vim7 repeats ';' and ',' not working for till 't' and 'T'
On Tue, Jun 27, 2006 at 04:23:36PM -0700, Mike Li wrote: > in normal mode, ';' and ',' are not working to repeat the last till > commands (i.e. 't' and 'T'), though they do seem to work for find > commands (i.e. 'f' and 'F'). i see this for both the win32 vim7 > binaries and FC5 builds from vim7 svn source. > > -x If, in Normal mode, you type tx then (assuming there is an "x" in the current line) the "tx" part will take you to the position before the "x" and the later ";" commands will leave you there. This is by design. If, instead, you type txl;l; then each "l" (lower case L, not number 1) will move you onto the "x" and the ";" will take you to the characte before the next one. HTH --Benji Fisher
Re: Copying UTF-8 characters from Vim to Vim inside xterm
On Sat, Jun 24, 2006 at 12:36:42PM +0200, Nikolai Weibull wrote: > Say I have a buffer like the following: > > ★ > > Say that I then select and copy that character. I then get: > > ★★ > > Say that I then copy it again (i.e., pressing middle-button twice > inside the xterm): > > ★★# > > Why does that happen? > > nikolai I cannot reproduce this. I tried copying the character using yl (in Normal mode) and also by selecting with the mouse (in a gnome-terminal, not having an xterm handy). I tried pasting by using p in Normal mode and by using the middle mouse button in Insert mode. Can you be more specific about how to reproduce the problem? Does it matter whether you are running vim in an xterm or some other terminal, or in gvim? I am running vim 7.0 (no patches yet) on Linux (Fedora Core 2). HTH --Benji Fisher
Re: matchparen bug?
On Wed, Jun 07, 2006 at 03:07:49PM -0700, Gary Johnson wrote:
> On 2006-06-07, Jared <[EMAIL PROTECTED]> wrote:
> > On 06/07/2006 15:10, Gary Johnson wrote:
> > > On 2006-06-07, Jared <[EMAIL PROTECTED]> wrote:
> > > I haven't been following this discussion very closely, but I just
> > > tried the experiment on Red Hat Linux 9, SunOS 5.8 and Windows XP
> > > with vim 7.0, no patches, and the cursor always goes to the 'o' in
> > > the third line. Is that what you were looking for?
> >
> > Which test case are you using? My original snippet:
> >
> > let g:loaded_autoit_completion = 1
> > let s:cache_name = []
> > " This function is used for the 'omnifunc' option.
> >
> > Or Benji's:
> >
> > long line
> > ()
> > another
> >
> > Reason I'm asking is because if you're using mine, then you do NOT see the
> > bug. If you're using Benji's then you do see the bug. It's an unfortunate
> > coincidence that 'o' signifies a success in one case but a failure in the
> > other.
>
> I was using Benji's. ...
I call that reproducing the bug. That makes three of us who see
the bug, one who does not. Looking at the plugin, I think I understand
what causes it. I explained that a few posts back, didn't I?
HTH --Benji Fisher
Re: matchparen bug?
On Tue, Jun 06, 2006 at 05:11:13PM +0300, Ilya wrote: > Benji Fisher wrote: > > Perhaps you have set 'matchpairs' so that it does not include > >"[:]"? > matchpairs does include "[:]" - as by default. And brackets are > highlighted when cursor is near one of them. > > Since you snipped the three sample lines, here is another > >example: > > > > long line > > () > > another > > > >After going to "long line" and doing $i do you have the cursor > >after the parentheses, with the parentheses highlighted? > > > Yes, I do. And after doing I have cursor after 'r' in 'another'. I am stumped. I tried it with $ vim -u NONE :set nocp :runtime plugin/matchparen.vim and I still get the cursor on the "o" in the third line. --Benji Fisher
Re: gvim crash using mouse with mousefocus set on opensuse 10.1
On Tue, Jun 06, 2006 at 10:27:12PM +0100, William S Fulton wrote: > The version of gvim shipped with Suse 10.1 crashes when using the mouse. > I've filed a bug: https://bugzilla.novell.com/show_bug.cgi?id=182212, > but here is the stack trace again (below). Any suggestions on fixing > this would be welcome. > > William > [stack trace snipped] > > [EMAIL PROTECTED]:~> gvim --version > VIM - Vi IMproved 6.4 (2005 Oct 15, compiled May 2 2006 09:49:20) I could suggest upgrading to the current version (vim 7.0) but I actually think that 6.4 is a little more stable. > Included patches: 1-6 > Compiled by [EMAIL PROTECTED] > Big version with GTK2 GUI. Features included (+) or not (-): [snip] > +path_extra +perl +postscript +printer +python +quickfix +rightleft -ruby [snipp > Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK > -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/X11R6/include > -I/usr/include/libpng12 -I/opt/gnome/include/gtk-2.0 > -I/opt/gnome/lib/gtk-2.0/include -I/opt/gnome/include/atk-1.0 > -I/opt/gnome/include/pango-1.0 -I/opt/gnome/include/glib-2.0 > -I/opt/gnome/lib/glib-2.0/include -O2 -march=i586 -mtune=i686 > -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -Wall -pipe > -fno-strict-aliasing -fstack-protector-all -I/usr/X11R6/include > -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -pipe > -Wdeclaration-after-statement -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > -I/usr/lib/perl5/5.8.8/i586-linux-thread-multi/CORE > -I/usr/include/python2.4 -pthread > Linking: gcc -L/usr/X11R6/lib -Wl,-E > -Wl,-rpath,/usr/lib/perl5/5.8.8/i586-linux-thread-multi/CORE > -L/usr/local/lib -o gvim -L/usr/X11R6/lib -L/opt/gnome/lib > -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 > -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lfreetype > -lfontconfig -lXrender -lXext -lpng12 -lz -lglitz -lXt -lncurses -lacl > -lgpm -Wl,-E > -Wl,-rpath,/usr/lib/perl5/5.8.8/i586-linux-thread-multi/CORE > /usr/lib/perl5/5.8.8/i586-linux-thread-multi/auto/DynaLoader/DynaLoader.a > -L/usr/lib/perl5/5.8.8/i586-linux-thread-multi/CORE -lperl -lutil -lc > -L/usr/lib/python2.4/config -lpython2.4 -lutil -lm -Xlinker -export-dynamic Bram often mentions that there are known problems with python and multiple threads. It might be worth compiling yourself with big features and -python to see whether that helps. If you have not compiled vim before, read the instructions in the comments of src/Makefile . HTH --Benji Fisher
Re: matchparen bug?
On Mon, Jun 05, 2006 at 04:24:38PM +0300, Ilya wrote:
> Benji Fisher wrote:
> > I can reproduce it. Perhaps we just need more explicit
> >instructions on how to reproduce it. Using the text above, go to the
> >g:loaded_autoit_completion line and (starting in Normal mode) type
> >
> > $i
> >
> >to reproduce.
> >
> > I can see the problem in $VIMRUNTIME/plugin/matchparen.vim . In
> >this situation, the plugin moves the cursor left one character, onto the
> >"]", and then back. When this happens, vim forgets that it is trying to
> >keep the cursor in the same column as the "1".
> >
> > I do not see any way to fix this in the plugin. Perhaps the
> >getpos() and setpos() functions can be changed so that they will keep
> >the information that is being lost.
> >
> >HTH --Benji Fisher
> >
> Hm, strange, but it does not happen to me, even if I do as you say
>
> My action:
> 1. Open gvim.
> 2. Paste text from first mail.
> 3. $i
>
> and cursor is to the left of 'o' in 'onmifunc'.
Perhaps you have set 'matchpairs' so that it does not include
"[:]"? Since you snipped the three sample lines, here is another
example:
long line
()
another
After going to "long line" and doing $i do you have the cursor
after the parentheses, with the parentheses highlighted?
HTH --Benji Fisher
Re: matchparen bug?
On Thu, Jun 01, 2006 at 10:16:44PM +0300, Ilya wrote: > Jared wrote: > >[...] > >When I'm in Insert mode and moving across lines, if the cursor passes over > >a > >paren (defined here as any character in the matchpairs option), the cursor > >will stay in the column position when moving to the next line. See the > >following code for an example: > > > >let g:loaded_autoit_completion = 1 > >let s:cache_name = [] > >" This function is used for the 'omnifunc' option. > > > >Now, if my cursor is on the '1' in the first line and I press down twice, > >I'd expect the cursor to end up on the 'o' in 'omnifunc' in the third line. > > However, if I'm in Insert mode and matchparen is active, then my cursor > >will instead end up on the 'e' in 'used'. > > > >[...] > I do not have this bug. I can reproduce it. Perhaps we just need more explicit instructions on how to reproduce it. Using the text above, go to the g:loaded_autoit_completion line and (starting in Normal mode) type $i to reproduce. I can see the problem in $VIMRUNTIME/plugin/matchparen.vim . In this situation, the plugin moves the cursor left one character, onto the "]", and then back. When this happens, vim forgets that it is trying to keep the cursor in the same column as the "1". I do not see any way to fix this in the plugin. Perhaps the getpos() and setpos() functions can be changed so that they will keep the information that is being lost. HTH --Benji Fisher
Re: Regression in gvim 7.0.00x
On Thu, May 25, 2006 at 03:17:54PM +0200, Luc Hermitte wrote: > * On Thu, May 25, 2006 at 08:30:52AM -0400, Benji Fisher <[EMAIL PROTECTED]> > wrote: > > > I see the following note in doc/version7.txt : > > > > --- fixes and changes since Vim 7.0f --- > > [...] > > Prevent that using CTRL-R = in Insert mode can start Visual mode. > > Must I understand that the workaround I've found won't work in the > future ? (the workaround consists in returning > gv to i_CTRL-R=) AFAIK this will continue to work. The change is what you already noticed (I think): if = calls a function, and that function changes the mode, that will not be respected. It is OK if the function returns characters that change the mode. You might also have a look at :help :map-expression I have not played with it yet, but I think the idea is to give a simpler alternative to certain = constructions. > What about @= ? Can I use it to execute a sequence that will change the > mode to insert- or select-mode, according to the result of my function ? > Or is it also an undocumented feature that may not be supported in the > future ? I am not sure what you have in mind. Changes like this are not at all common. In this case, vim was put in an undocumented mode, and Bram was afraid that its behavior would be unpredictable in that case. (It could be considered a bug, since all of vim's modes are supposed to be listed under :help vim-modes .) HTH --Benji Fisher
Re: Regression in gvim 7.0.00x
On Thu, May 25, 2006 at 02:06:55AM +0200, Luc Hermitte wrote: > Hello, > > I've been observing a regression on gvim since the release of vim 7.0. > I'm observing it on gvim 7.0.000 on windows, gvim 7.0.015 (or 17, I do > not remember) on Linux (gui=GTK2/Athena). It seems I do not have it with > the console version on Linux -- I haven't had the opportunity to test > the following lines of code with the console version. > > I don't remember the problem on gvim 7.0e (at least I do not have it on > vim 7.0a on windows) > > > The problem consists in the combination of a few things: > - a nmapping selects (as in select-mode) a few characters > - an imapping calls a function (through i_CTRL-R) that executes the > previous mapping with :normal, and then returns "\" to terminate > the INSERT-SELECT mode and finish in select-mode. I do not have time to look at this closely, but I assume it is because certain undocumented modes are now no longer supported. This was discussed on the vim users' list on the thread "Insert Visual mode", started by Gerald Lai on April 22. (That is from my personal mail archive; I assume that is enough information for you to find the thread.) I see the following note in doc/version7.txt : --- fixes and changes since Vim 7.0f --- [...] Prevent that using CTRL-R = in Insert mode can start Visual mode. HTH --Benji Fisher
Re: please unsubscribe me
On Wed, May 24, 2006 at 12:33:50PM +0200, Ulrich Lauther wrote:
> As the automatic unsubscribing process does not seem to work and mail to
> [EMAIL PROTECTED] doesn't help either, could please some kind soul
> remove me from the list?
I think that moving the vim mailing lists to a new server is on
Bram's TODO list when he gets back from vacation. Until then, I do not
think there is anyone who can help. I have not tested myself, but
judging from your post and others, the mail admin is MIA. :-(
--Benji Fisher
Re: PC sources lacks if_sniff.c
On Wed, May 24, 2006 at 12:26:35PM +0200, Mathias Michaelis wrote: > Hi vimmers! > > The source archive > > ftp://ftp.vim.org/pub/vim/pc/vim70src.zip > > contains the file if_sniff.h but not the corresponding source file > if_sniff.c. Has this a specific reason or has if_sniff.c simply been > forgotten? > > With kind regards > > Mathias I think it is a mistake. At first, I thought that if_sniff.c was a generated file, but then I checked my copy of the sources: $ bzcat vim-7.0.tar.bz2 | tar tf - | grep sniff vim70/runtime/doc/if_sniff.txt vim70/src/if_sniff.h $ tar tzf vim-7.0-lang.tar.gz | grep sniff $ tar tzf vim-7.0-extra.tar.gz | grep sniff vim70/src/if_sniff.c So the file is there in the "extra" archive, so I think it should be included in the PC version. HTH --Benji Fisher
Re: Pattern questions
On Tue, May 23, 2006 at 02:22:32PM +0200, Zdenek Sekera wrote:
> > >
> > > if (char =~ '\m[;|<>?:[EMAIL PROTECTED]&*(){}\\_+-[\]/\"]')
> > > do something
> > > endif
> > >
> > > 2. why when the pattern ends with '+' or '\+' do I get
> > >an error?
Can you be more specific? I tried
:let char = "a"
:echo char =~ '\m[;|<>?:[EMAIL PROTECTED]&*(){}\\_+-[\]/\"]+'
:echo char =~ '\m[;|<>?:[EMAIL PROTECTED]&*(){}\\_+-[\]/\"]\+'
and neither generated an error.
HTH --Benji Fisher
Re: vim7: problem with regex subst and combining chars
On Wed, May 17, 2006 at 08:34:22AM -0700, Ron Aaron wrote: > Arrgh! I can't send this message to the list, for some reason! Maybe > because it has strange characters in it? > > OK: you can download my test.zip from here: > > http://ronware.org/test.zip > > In it you will find a file 'test.txt' which is UTF8 and will tell you how > to see the problem I am finding with using s/// with combining > characters. I can confirm the problem (on Linux, GTK2, enc=utf-8, vim 7.0.000). Maybe I can get the offending characters to the list. The following should be a no-op: :s/.*/& but it is not on the following line of voweled Hebrew: הִלְכּוֹת I notice other problems. For example, $ (in Normal mode) takes me to the fifth character. (With 'ruler' set, I see 17-5 in the status line.) Maybe there is a null byte in the fifth or sixth multi-byte character? --Benji Fisher
Re: FW: [Vimoutliner] I have a windows installation issue.
Please take the time to edit out the parts we do not need to read. I just tried :tab split and I am about to yank this line. OK, I yanked it, did a gt back to the original tab, and now I will paste it: and I am about to yank this line. No problem. If this supposed bug is reproducible, please give details. HTH --Benji Fisher On Wed, May 17, 2006 at 02:27:38PM +0200, Zdenek Sekera wrote: > >From another mailing list. > Is there a problem using tabs on the same file? > > ---Zdenek > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Peter Princz > Sent: 17 May 2006 13:53 > To: Vim Outliner User and Developer Mailing List > Subject: Re: [Vimoutliner] I have a windows installation issue. > > So far I've been using :split to open several windows to the same > buffer, but now in vim7 I tried the tabs. It is a very preliminary > observation but it seems to work perfectly until you yank from one tab > to the other, then the second tab becomes garbled. (Note: both tabs > show the same buffer, the same file.) > > Luckily it is garbled on the display only, not the file itself. Also > it can report ambigously on the tabs whether the file is saved or > dirty.
Re: formatexpr, append() and undo
On Tue, May 16, 2006 at 08:33:43AM +0200, Jiří Černý wrote:
>
> Here are the scripts and the test case. It is relatively complicated,
> but I did not find a simpler one. It works in vim 7.0 (Included patches:
> 1-17)
I have simplified the example somewhat. I may look at it some more
later, or maybe someone else will take it from here. Save the attached
files foo (unchanged) and format.vim (simplified) and start vim with
$ vim -u NONE +"source format.vim" foo
On the first (blank) line, start Insert mode and type
12345
$67890 1234$ 5678
9012
letting vim do the line breaks. Then back to Normal mode and u to
undo: the 9012 line is left and 'modified' is not set.
Curiously, if I *do* add the line break myself after the first
line, the problem seems to go away. The bug seems to surface only when
two lines have been changed by the function.
HTH --Benji Fisher
==
==
set nocp tw=20
set laststatus=2" so I can watch the 'modified' flag
setlocal formatoptions=tcqr
setlocal formatexpr=MyTeXFormat(v:lnum,v:count)
fun! MyTeXFormat(lnum,count)
let line = getline(a:lnum)
let curlineindent = indent(a:lnum)
let aftercursor = line[col(".")-1:]
let beforecursor = line[:col(".")-2]
let numdollars = len(substitute(beforecursor, '[^$]', '', 'g'))
let evendolars = numdollars % 2
let dolarpos = matchend(beforecursor, '.*\$')
if evendolars == 0
if dolarpos < &tw "vim can do the job
return 1
endif
endif
if beforecursor[dolarpos-1] != ' ' "no space before $
let dolarpos = strridx(beforecursor,' ',dolarpos-1)
let dolarpos = dolarpos + 1
endif
if dolarpos != curlineindent "formula does not start at first char
call setline(a:lnum,strpart(beforecursor,0,dolarpos))
call append(a:lnum,"XX")
let newline = strpart(beforecursor,dolarpos) . aftercursor
call setline(a:lnum+1,newline)
call cursor(a:lnum+1,strlen(beforecursor)-dolarpos+1)
return 0
endif
return 0
endfun
Re: [vim7] a strange behavior of completeopt
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 fo, fo will completed as foo, that is expected, > input '.b' after "foo", now the text becomes "foo.b", then press > , 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
Re: :cw messes with _ =
On Mon, May 15, 2006 at 10:24:33PM -0700, Yegappan Lakshmanan wrote: > > This is because the quickfix window has the 'winfixheight' option > set. So when you try to make the height of all the windows equal, the > windows with the 'winfixwidth' option set are skipped. If you reset the > 'winfixheight' option for the quickfix window then CTRL-W_= will work. > > - Yegappan Thanks, that helps. The docs for 'winfixheight' mention behavior with 'equalalways' but not with = . If 'winfixheight' is supposed to affect both, I think the docs should mention this. --Benji Fisher
popup menu sticks after :
I noticed a case where the popup menu sticks around after I enter
Command-Line mode. I type (in Insert mode)
fee fie fo fum
f:
and I get the completion fum (since that is in my text so far) with
the popup menu, and the menu is still there until I leave Command-Line
mode. If I wait a second after the before typing the :, there is
no problem.
I narrowed this down. (Someone, please pat me on the back for this
job. I had to sort through a bunch of plugins to narrow it down to my
ftplugin/mail.vim and the matchparen plugin before I got this!) It
seems to depend on 'lazyredraw' and the CursorMoved,CursorMovedI
autocommand events. Just source the following lines and try the
experiment above:
set nocp
setlocal lazyredraw
let s:nop = 0
autocmd! CursorMoved,CursorMovedI * let s:nop += + 1
Yes, it works with -u NONE.
It may depend on having an xterm-like terminal, so that
triggers a delay ('timeoutlen' or something like that). I use
gnome-terminal (but I do not compile with Gnome support, just GTK2).
--Benji Fisher
:cw messes with _ =
After opening the quickfix window and using _ to make it
larger, I find that = no longer works until I close the quickfix
window.
Details: vim 7.0 (no patches) on Linux + GTK2 (so 'encoding' is set to
utf-8) + Normal features (compiled OOTB).
$ vim -u NONE
:helpgrep guifont=\*
:cw
:wincmd _
:wincmd =
--Benji Fisher
Re: formatexpr, append() and undo
On Mon, May 15, 2006 at 03:56:25PM +0200, Jiří Černý wrote:
> Hello,
>
> I have tried to write a function for formatting TeX files using the new
> 'formatexpr' function. Goal is (of course) to keep matching dollars on
> one line and not to use the insert mapping of .
>
> I have more or less found a good solution. The only problem is that this
> solution interacts quite badly with the undo mechanism of vim. The
> function I wrote uses vim internal formatting algorithm when no special
> treatment is necessary (returns 1) otherwise it does the formatting job
> and returns 0. In the second case it uses append() function to add a new
> line under the current line.
>
> I have feeling that this append() function is not recorded for the undo.
> Essentially, every use of append() for formatting during an insertion of
> a long paragraph results in one line that is left in the file after
> undoing this insertion.
>
> I can post the scripts that I use if it is necessary, but maybe the
> description is sufficient to understand the problem.
>
> It is also maybe possible to use different means to append the line, but
> I find append() to be the best one.
>
> This problem appears in VIM 7.0c10. I had no time to compile the final
> version, so sorry if this problem has been already resolved.
Please do post the script you use, simplified as much as possible,
so we can test it. I tried
:call append(line("$"), "This line brought to you by append()")
and then (in Normal mode)
u
and it worked fine. This is with vim 7.0.
An alternative is to use
:put='This line brought to you by :put'
instead of append(). I do not know whether that will work any better.
HTH --Benji Fisher
Re: situation in which n doesn't switch 'hls' on after 'h' in viminfo disabled 'hls'
On Mon, May 15, 2006 at 12:07:55AM +0300, Yakov Lerner wrote: > On 5/14/06, Benji Fisher <[EMAIL PROTECTED]> wrote: > > > >I have not tried it inside a function, but > > > >:set hls > > > >seems to undo the effect of > > > >:nohls > > > >so perhaps a work-around is to add > > > >:if &hls | set hls | endif > > > >either to the function or (replacing "|" by "") to the mapping. > > Yes, adding 'set hls' to rhs of the mapping (outside > function) solves it. (But adding ':set hls' inside function > doesn't). I realize now that this is probably by design. If this is for your personal use, do what you please. If you plan to distribute this script, I suggest using the :if since the end user might be annoyed by having 'hls' set unconditionally. HTH --Benji Fisher
Re: situation in which n doesn't switch 'hls' on after 'h' in viminfo disabled 'hls'
On Sun, May 14, 2006 at 03:37:26PM +, Yakov Lerner wrote: > Hello, > > I use my own mapping of 'n' which invokes ":normal! n" inside. > I noticed that my n does not turn on 'hls' automatically > when 'hls' is disabled by 'h' in viminfo. This is strange because > my map for n does invoke ':normal! n', which itself > would turn hls on. Here is test case: >vim --noplugin -u yy.vim yy.vim >/. >ZZ >vim --noplugin -u yy.vim yy.vim >gg >n >ZZ > - this works, turns on 'hls' >vim --noplugin -u xx.vim xx.vim >" assume search pattern "." comes from viminfo >n > - does not turn on 'hls' > > Yakov > --- xx.vim - > set nocp > :set viminfo='20,<50,s10,:20,h > :set hls > function! MySearch_n() >:silent! exe "normal! n" > endfu > nmap n :call MySearch_n() > -- > 2. > -- yy.vim --- > set nocp > :set viminfo='20,<50,s10,:20,h > :set hls > nmap n :silent! exe "normal! n" > Is there a reason to use :exe "normal! n" instead of simply :normal! n ? I assume this is a simplified version of something real... The main difference is that xx.vim wraps the "normal! n" command in a function. At the very end of :help :function-verbose just above :help :endfunction the docs say The last used search pattern and the redo command "." will not be changed by the function. I guess the "last used search pattern" is the thing used by :s// ; I do not think it is exactly the same as @/. though these are usually the same. I guess that, as a side effect of this special rule for functions, search highlighting is left turned off. I have not tried it inside a function, but :set hls seems to undo the effect of :nohls so perhaps a work-around is to add :if &hls | set hls | endif either to the function or (replacing "|" by "") to the mapping. HTH --Benji Fisher
Re: visual block mode and text objects
On Sat, May 13, 2006 at 10:37:46PM +0200, Tobias Klein wrote:
> Hi list,
>
> I noticed a non expected behaviour (for me) using visual block mode in
> combination with text objects.
>
> Here is an example:
> say we have a file containing only two lines (one character each):
> a
> b
>
> Then typing:
> CTRL-V apIx
> (starting visual block mode and selecting both lines _with an text
> object_ to insert 'x' in front of every line)
>
> results in:
> xa
> b
>
> I expect:
> xa
> xb
>
> Tested on VIM 7.0 (Patches 1-16)
> with
> vim -u NONE
>
> Tobi
I see the same thing. I notice that
:echo line("'<") col("'<") line("'>") col("'>")
shows
1 1 2 2
and that a 2x2 block (including one space beyond the end of each line)
is highlighted after CTRL-V ap . If I start on the "a" and try
CTRL-V jl then the highlighted area is an L shape, including only the
"a" on the first line. I get the same response
:echo line("'<") col("'<") line("'>") col("'>")
1 1 2 2
with either selection.
Does anyone want to try to fix this before Bram gets back from
vacation?
HTH --Benji Fisher
Re: gvim7 filename tab completion insert CTRL-I
On Thu, May 11, 2006 at 09:27:25AM -0700, inet working wrote: > I just installed vim7 on windows xp. the installer > prog also removed vim6 (i chose to keep the vimrc file > i'd). > > first problem i ran into is, in gvim command mode, > typing > :Ex c:\LongDir > > insert ^I instead of completing the file/dir name to > LongDirName. This always worked until vim7. > > Do I (how) need to edit .vimrc somehow so tab file > name completion would work again in Vim7 ? It looks as though you are getting vi-compatible behavior of on the command line. Specifically, 'wildchar' may be set to its vi-default rather than its vim-default. Please check the following. :verbose set compatible? cpo? wildchar? You are supposed to get 'nocompatible' and vim-defaults as soon as vim finds a user vimrc file, so please also check that your vimrc file is being loaded by looking at :scriptnames HTH --Benji Fisher
Re: Strange behavior with text wrapping / reflowing
On Tue, May 02, 2006 at 11:48:35PM +0200, Georg Dahn wrote: > Hi! > > Eric Arnold wrote: > > setlocal formatoptions+=bcroqan2t" better without w > > setlocal linebreak > > I have tried these setting of formatoptions now. I see, that even if I > don't set textwidth (it is 0) and if there are very much more than 80 > columns, the text gets wrapped at column 80. The value of wrapmargin > is ignored. If I start gVim with gvim -u NONE and set the formatoptions, > the text always gets wrapped at the last column. This is a feature (since it is documented) and not a bug. Under :help auto-format (Follow the link from the "a" flag in :help fo-table .) there is the note - Set 'textwidth' to the desired width. If it is zero then 79 is used, or the width of the screen if this is smaller. I am not saying I like this, but then I do not like the "a" flag at all. HTH --Benji Fisher
Re: More ^P/^N weirdness
On Tue, May 09, 2006 at 11:27:02PM +1000, Robert Webb wrote:
> I'm still finding the ^P/^N behaviour in insert mode kind of annoying.
> I just did something like this:
> - Edit a file with the text "numMatches" in it.
> - Type "numMb" and hit ^P.
> - It's a typo so no matches come up. In the meantime vim starts
> madly searching through header files in the background.
> - Hit , then "a" to give the text "numMa".
> - Now it should find the right match. Vim still seems to be
> searching in the background. Is it supposed to find the correct
> match now straight away? It doesn't. Or is it up to me to hit
> ^P again?
> - If I hit ^P again, nothing happens. I can repeatedly hit it and
> no matches are found and no menu appears (note: all this is
> still while vim is searching in the background). In 6.3 this
> would have given me the right match.
> - So instead I try ^N. Now a menu appears with my original text
> ("numMa") and the match I want ("numMatches"), but no matter how
> many times I hit ^N it just stays stuck on the first item which
> was my original text! It's stuck again in a similar way to what
> I described in another email.
>
> What is supposed to happen when you hit then hit another letter
> during completion mode?
>
> I still think ^N/^P should wrap around the matches found so far while
> bim is searching in the background.
I tried this (using a different "wrong" character since this e-mail
contains "numMb" in it). Vim did not seem to search madly for matches,
but I did notice one annoyance. After I got to the "numMa" stage, the
completion menu shoed two options: "numMa" and "numMatches", but
neither was highlighted. Hitting cycled through three states:
one or the other option was highlighted, or neither. Two of these
options have the same text, "numMa", in the buffer.
HTH --Benji Fisher
P.S. There have been times when hitting removed characters that I
had typed, and I had to re-type them. I have not been able to figure
out how to reproduce this. :-(
Re: set pt= doesn't work
On Fri, May 05, 2006 at 10:20:10AM -0400, Charles E Campbell Jr wrote: > Hello! > > Instead of getting paste mode when inserting when hitting the key, > I'm getting Tag Completion, a popup window, > and a selection made for me that I don't want. This is with vim 7.0g02. > > Regards, > Chip Campbell I do not see this. I tried vim 7.0 final and 7.0f. Maybe the problem is at your end, or maybe it depends on the terminal you are using. (The docs mention that 'paste' is usually not needed in the GUI or in a terminal where vim handles mouse events.) HTH --Benji Fisher
Re: gvim + X + geometry + set line + cttrl-f + folding (whew!) : a bug
On Tue, May 02, 2006 at 09:04:06PM +0200, Bram Moolenaar wrote: > > Charles Campbell wrote: > > > >>This one appears to be a ctrl-f (and ctrl-b) bug. Here's the setup: > > >>(using Linux,vim-7.0g, huge) > > >> > > >>.vimrc : > > >> set nocp > > >> > > >>.gvimrc : > > >> set lines=21 > > >> > > >>no .vim/ directory. > > >> > > >>Now, for the problem: > > >> > > >>gvim -geometry "139x22+0+4" netrw.vim > > >>11j > > >>z > > >>4j6k4j > > >> > > >> > > >>Note that the does not advance a page; instead, the cursor > > >>returns to the top line (which is a fold). Similar misbehavior > > >>happens with a ctrl-b. I have to use hit ctrl-e several times to move > > >>the folds off the top; then, ctrl-f works again. > > > > > >I don't see the problem. Perhaps you can tell us what the display looks > > >like after each command. I'm not sure I have the same version of > > >netrw.vim (there have been quite a few!). > > > > > >Also, it's easier if you start with "gvim -u NONE -N ...". > > > > Using another command line option, I get the same misbehavior with > > .vimrc and .gvimrc as shown above, > > > > gvim --noplugin -geometry "139x22+0+4" netrw.vim > > > > and using the same directions. > > If I do that I get all my vimrc settings, including 'scrolloff', and > that probably avoids the problem you notice. Please start with "-u NONE > -N", otherwise it's hard to reproduce. If you don't see it with "-u > NONE -N" then there must be something on your system that triggers it. > What? Bram, maybe you missed Charles's "with .vimrc and .gvimrc as shown above," which is almost as good as starting with -u NONE. But I agree that I cannot reproduce the problem. I compiled with huge features on Linux/GTK2 and started gvim with $ gvim -u NONE -U NONE --noplugin -geometry "139x22+0+4" +"set nocp lines=21" ../runtime/autoload/netrw.vim and tried the experiment, did not see anything unusual. HTH --Benji Fisher
Re: vim70f, ft=vim, syn on -- highlighting of matching parens fails
My first guess is that you have another copy of the matchparen.vim
plugin lying around. Try
:scriptnames
and look for something like
path/to/plugin/matchparen.vim
Is this in your personal plugin directory or $VIMRUNTIME ?
My second guess is that you did not upgrade your runtime files.
Try
:e $VIMRUNTIME/plugin/matchparen.vim
and look at the top few lines. In my copy, the revision date is April
27.
HTH --Benji Fisher
On Tue, May 02, 2006 at 01:49:25PM +0200, Milan Berta wrote:
> I can still reproduce the wrong behavior of parens. Using vim7.0g.
>
> Best regards,
> Milan
>
> On Sun Apr 30, 2006 at 01:57:28PM +0200, Bram Moolenaar wrote:
> >
> > Milan Berta wrote:
> >
> > > I was browsing some Vim-scripts and I found strange that a highlighting
> > > of matching parens fails on this line:
> > >
> > >
> > > let l:fg=substitute(l:bcdefg,".*\\C" . l:cde . ",\\([^,]\\),.*","\\1","")
> > >
> > >
> > > It fails when the cursor is on
> > > - the first, the second of '('
> > > - the first '['
> > > - the last ')'
> > > - everything else is OK.
> > >
> > > It works well when ':syn off', it fails when ':syn on'. ft=vim.
> > >
> > > I can reproduce the problem with this simple line alone in a file.vim or
> > > by changing the 'ft' and 'syn' for a buffer.
> >
> > This problem was fixed a few days ago. Please try the current snapshot
> > or the next beta (should be later today).
Re: exists("*Foo!garbage") = 1 ?
On Tue, May 02, 2006 at 12:13:37AM +0200, Bram Moolenaar wrote:
>
> Charles Campbell wrote:
>
> > Bram Moolenaar wrote:
> >
> > >The problem of changing something like this is that all scripts that are
> > >included in the release need to be checked for effects. And there are
> > >lots of scripts now. I wouldn't be surprised if, for example, the netrw
> > >plugin stops working properly.
> >
> > In perusing netrw, I believe that all the netrw usages of
> > exists("*func") give exists() a full function
> > name; ie. they don't depend on its just being a prefix. So, I expect
> > that netrw should work ok with
> > such a change.
>
> Bad example... I meant that there are scripts that are too big to
> check.
I tried
:vimgrep /exists[^)]*\*/ $VIMRUNTIME/**/*.vim
:cl
and found that there are 111 matches. If all we are worried about is
exists("*") where contains non-'isk' characters, then I
am willing to check them. I bet there are very few.
HTH --Benji Fisher
Is visualmode() local to buffer?
I checked the behavior of visualmode() while answering a question
on the vim users' list, and I noticed that the return value depends on
the current buffer. Is this the way it is intended to work? If so, I
think the docs should mention this.
Example: Open two buffers in two windows. Use linewise Visual
mode in one and characterwise Visual mode in the other. Try
:echo visualmode()
:wincmd w
:echo visualmode()
and one will echo "v", the other "V".
--Benji Fisher
Re: Insert mode: does not paste the whole register
On Fri, Apr 28, 2006 at 11:44:06AM +0200, Bram Moolenaar wrote: > > Georg Dahn wrote: > > > Simetimes in Insert mode is very useful. I use it to > > format articles automatically. I set 'noai' and 'tw=78'. But > > for texts with many lines this fails. I use the file > > vimtips.txt I downloaded from vim.org. > > > > 1. Open vimtips.txt > > 2. Do :set noai > > 3. Do :set tw=78 > > 4. Cut the whole file to a register, for example " > > 5. In Insert mode do " > > > > Then it stops somewhere near line 3500 (vimtips.txt has over > > 4 lines at the moment). Just pasting it with 'p' works, > > this I suppose that the whole file is in the register. > > Where do you find this vimtips.txt with 4 lines? I only found one > with 3543 lines. > > I tried another file but it worked fine. Perhaps you run out of memory? > Also note that text gets formatted if you put it like this. If you have > 'autoformat' set the number of lines will change. It should be possible to test whether you are running out of memory by copying and pasting 3000 lines at a time. If you are *not* running out of memory, but there are some problematic characters on or about Line 3500, you should be able to narrow down the problem. Perhaps :help i_CTRL-R_CTRL-R will help. Bram, is there any way to issue a warning when a copy/paste operation runs out of memory? HTH --Benji Fisher
Re: minor problem with matchparen plugin
On Thu, Apr 27, 2006 at 06:23:30PM -0400, [EMAIL PROTECTED] wrote:
> I noticed that the matchparen plugin sometimes highlighted the wrong
> parenthesis.
>
> If syntax=c and the user types 'A' to start inserting text at the end of
> the following line:
> ((""))
> then the last ')' will be highlighted, but the _second_ (not the first)
> '(' will be highlighted.
>
>
> The following fixes this problem:
> ===
> --- runtime/plugin/matchparen.vim (revision 12)
> +++ runtime/plugin/matchparen.vim (working copy)
> @@ -88,7 +88,7 @@
>endif
>
>" When not in a string or comment ignore matches inside them.
> - let s_skip ='synIDattr(synID(line("."), col(".") - before, 0), "name") ' .
> + let s_skip ='synIDattr(synID(line("."), col("."), 0), "name") ' .
> \ '=~? "string\\|comment"'
>execute 'if' s_skip '| let s_skip = 0 | endif'
> ===
Coincidentally, this problem was reported yesterday (or maybe late
the previous day) on the vim users' list. Bram and I each posted a
patch similar to yours: we also moved the lines shown in your patch
down a few lines.
--Benji Fisher
Re: help with vimrc on 7.0e beta on Win
On Sat, Apr 22, 2006 at 10:32:16AM -0400, Dave wrote: > Hello. I've been using vim on Win up through 6.4 with no problems. I > uninstalled 6.4 (and removed registry entries), installed 7.0e. I then: > > set the 2nd and 3rd lines in _vimrc to: > source $VIMRUNTIME/daverc.vim > source $VIMRUNTIME/davercwin.vim > > I then went into the vim70 dir and added those 2 files(daverc.vim and > davercwin.vim). I didn't set VIMRUNTIME anywhere, but I never have. When I > start 7, it doesn't see my rc changes. > > I also tried just leaving the default files (the "example" files) and > addding my customization. Again, no errors, but my customizations weren't > seen. > > I'm sure this is something dumb, but I'd appreciate help. First, the usual advice is to avoid adding your own files to $VIMRUNTIME. Among other things, it means you have to do it again when you upgrade to a new version of vim (such as the upcoming final release of 7.0). Why not put these files near your vimrc file? See also :help vimfiles Now, to figure out what is going wrong, try :echo $VIM :echo $VIMRUNTIME :scriptnames HTH --Benji Fisher
Re: Mappings fail me, yet again
On Fri, Apr 21, 2006 at 01:41:46AM +0200, Nikolai Weibull wrote:
>
> I would be able to define my long-wanted "g:"
> mapping that makes : act like an operator, i.e., first waits for a
> range and then starts command mode with that range on the command
> line:
>
> noremap g: :set operatorfunc=GetCommandModeRangeg@
>
[snip]
> I can't put the :...-stuff after the g@, as Vim will just eat them up
> for the g@ command.
>
> Perhaps I'm missing something, but I don't think so. There's simply
> no way to do what I want.
>
> If anyone has a hack to enable me to do this, please share it with me.
You *can* add the range '[,'] at the end of the mapping if you use
inputsave() and inputrestore(). The following example uses g@ with a
dummy function to set these two marks. If you use the GetMotion()
function from foo.vim
http://www.vim.org/script.php?script_id=72
(my file of example vim functions) then you do not have to hit
after entering your motion. It is not entirely smooth, and adding
"silent" does not help much, but please tinker.
HTH --Benji Fisher
fun! Dummy(mode)
endfun
fun! Gat()
call inputsave()
" silent let mtn = GetMotion("")
let mtn = input("motion: ")
call inputrestore()
set operatorfunc=Dummy
execute "normal g@" . mtn
endfun
map g: :call Gat():'[,']
Re: RFC: (x)html completion support in Vim7
On Thu, Apr 20, 2006 at 10:51:04PM +0200, Mikolaj Machowski wrote: > Hello, > > I am author of (x)html completion scripts and related (php, css, > javascript). I'd like to ask what you think it should like. > > At the beginning I was pushing for one default: XHTML 1.0 Strict. Bram > didn't like it and now there are two: fot &ft='html' HTML 4.01 > Transitional and for &ft=='xhtml' XHTML 1.0 Strict (user can still > choose another version with b:html_omni_flavor variable - this > improvement may be not yet in snapshot/cvs/svn). Bram still doesn't like > it. According for him completion should be more flexible and not limited > to some standard. For me it defies whole idea of omni-completion > - completion suggestions should be precise. Problem with (X)HTML is > there are many standards but creation of messy compilation from > them has no sense. Vim is superb program and should support writing of > good code - according to standards. I like the idea of encouraging XHTML 1.0 Strict, but since I write so little HTML code myself, perhaps my vote should be discounted. > To make this support full it could look: > > - provide data files for most of (X)HTML standards: > > - HTML 3.2 Strict (for legacy pages) > - HTML 4.0 Transitional > - HTML 4.0 Strict > - HTML 4.0 Frameset > - HTML 4.01 Transitional > - HTML 4.01 Strict > - HTML 4.01 Frameset > - XHTML 1.0 Transitional > - XHTML 1.0 Strict > - XHTML 1.0 Frameset > - XHTML 1.1 > > That is 11 data files, ca. 45kB each (5kB packed) - total 500 kB (55kB) I have not looked at the structure of the completion scripts, but isn't there a way for one script to include another? Under $VIMRUNTIME/ftplugin/ the file tex.vim (for LaTeX) :source's plaintex.vim , which :source's initex.vim . You should be able to do something similar with XHTML 1.0 Frameset/Transitional/Strict. This strategy no only reduces file size, it also makes maintenance easier. Suppose someone notices a mistake in one of these files: do you want to correct it in one place or in three? > Add functions for detection of DOCTYPE to ftplugins for xhtml and html. > > Still there is usability problem for creation of new files. Maybe some > general completion for insertion of DOCTYPE and setting appropriately > completion. Right, and allow users to set a variable (g:html_omni_version or something) that the ftplugins can check to use as a default for new files. HTH --Benji Fisher
Re: Possible utf-8 bug
On Tue, Apr 18, 2006 at 12:40:17PM +0200, Bram Moolenaar wrote:
>
> Srinath Avadhanula wrote:
>
> > I found the following difference in behavior between vim6 and vim7:
> >
> > 1. Open a buffer (vim -u NONE)
> > 2. :set encoding=utf8
> > 3. Type some stuff
> > 4. Type the following in insert mode:
> > =substitute('foo', '.', "\\", 'g').'bar'
> >In vim6:
> > The last three characters are deleted and 'bar' is inserted in
> > their place.
> >In vim7:
> > A whole bunch of control codes are inserted instead of text being
> > deleted. In vim7, however, the following
> > =repeat("\\", 3).'bar'
> > does delete the last three characters and inserts 'bar'
> >
> >
> > Note that with 'encoding' set to 'latin1', vim6 and vim7 both delete the
> > last three characters and insert 'bar'.
>
> I don't see the problem. I don't think this is system-dependent. I
> have no idea why it would fail for you...
There was a problem like this, specifically with encoding=utf8, but
it was fixed several versions ago. Srinath, can you post your full
:version output?
HTH --Benji Fisher
Re: Strange behavior with highlights defined in gvimrc
On Mon, Apr 17, 2006 at 02:34:28PM +0200, Georg Dahn wrote: > Hi! > > > Yes, your vimrc file should be executed first. I am still curious > >about the result of > > > >:verbose hi Constant > > Last set by C:\Programme\Vim\vim70e\syntax\syncolor.vim > > >Along with > > > >:scriptnames > > > >This should give some clues as to what is going on. > > 1: C:\Programme\Vim\_vimrc [snip] > 11: C:\Programme\Vim\vim70e\syntax\syncolor.vim [snip] > 23: C:\Programme\Vim\_gvimrc It looks as though the Constant highlight group is being set in syncolor.vim (after the :syntax on line in your vimrc file) and not being changed when your gvimrc file is read. If you want to explore this further, you could add some debugging lines to your gvimrc file to try to figure out why hi Constant guifg=Maroon is not taking effect. HTH --Benji Fisher
Re: Vim crash..
On Mon, Apr 17, 2006 at 02:39:37AM -0400, sean wrote:
>
> Helped very much! After fighting with multiple cvs mirrors I finally got
> the 7.0e source down and rebuilt a new rpm. All fixed as promised.
The problem with the CVS server is being discussed on another
thread. For now, I think the right thing to do is to keep using
snapshots from ftp://ftp.vim.org/pub/vim/unstable/snapshot/ .
I think someone mentioned that the position of vim RPM maintainer
was vacant. Have you taken on that job? Can you give a pointer to the
RPM?
--Benji Fisher
Re: [BUG] Problem with expand("")
On Mon, Apr 17, 2006 at 01:27:10PM +0200, Bram Moolenaar wrote:
>
> Very strange. When at the trailing space I get nothing. You must have
> some setting at a different value...
>
> Oh wait, with 'encoding' set to "utf-8" I can see the problem. Now I
> can fix it.
I continue to be surprised at how many things are affected by this.
I will try to remember to mention utf-8 in the future.
--Benji Fisher
Re: Strange behavior with highlights defined in gvimrc
On Mon, Apr 17, 2006 at 08:24:20AM +0200, Georg Dahn wrote: > Hi! > > > Sorry, I meant to suggest trying > > > > :verbose hi Constant > > > > When I try this, it tells me that the Constant highlighting was set in > > $VIMRUNTIME/syntax/syncolor.vim . > > > This file is :source'd after the :syn on command. In your gvimrc > > file, do you have the lines to override the defaults before or after > > this line? > > The 'syntax on' is in my vimrc file, which (AFAIK) is executed before > gvimrc. After these highlights there are only two mappings. Yes, your vimrc file should be executed first. I am still curious about the result of :verbose hi Constant Along with :scriptnames This should give some clues as to what is going on. > But your debugging line (let g:foo=...) shows, that the background is > 'dark' there. It is dark at the beginning of vimrc, too. In gVim 6.4 > the value is 'light' in both cases, so I suppose the default value of > 'background' was changed. This could be the problem, because the > background is light when gVim is open and changing the value of > 'background' changes several things. > > BTW, if I do 'colo default' in my vimrc I get the defaults for dark > backgrounds but a white background, which makes the highlights > unreadable. This happens, because the background is set to dark at > that point, but this isn't, what the user expects. Have you tried :verbose set background yet? If it is set to "dark" at the start of your vimrc file, this will probably not tell you much ... but if it does tell you anything, it will be worth knowing. Have you checked vim 6.4 and 7.0 for system vimrc and gvimrc files? (See :version output for where vim will look for these.) Of course, :help 'background' points out that vim cannot reliably guess the right value and suggests setting it in your vimrc file. Maybe it is simpler to do this than to figure out what is affecting the default value. HTH --Benji Fisher
Re: [BUG] Problem with expand("")
On Sun, Apr 16, 2006 at 05:56:19PM +0200, Nikolai Weibull wrote:
> On 4/16/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
> >
> > Nikolai Weibull wrote:
>
> > > :x.
> > >
> > > and again position the cursor over/at the trailing space. Again execute
> > >
> > > :echo expand('')
> > >
> > > The expansion will be ':x.'.
> >
> > I don't see this, the result is empty both times. Are you sure the
> > cursor wasn't on the "."?
>
> Yes. Perhaps this was an issue in
>
> VIM - Vi IMproved 7.0b BETA (2006 Mar 24, compiled Mar 26 2006 13:06:54)
>
> so I guess I should upgrade...
>
> If you don't see it then hopefully everything is fine :-).
I just compiled vim 7.0e (Normal features, default "make" on FC2
Linux) and I see the same thing that Nikolai described. Note that his
first trial has leading and trailing spaces; the second trial only a
trailing one. I also tried the line
:x. :y.
and carefully placed the cursor on the trailing space. I got ":x."
again! With the cursor on the first space, I get ":y.", which seems
reasonable. (I have never liked the phrase in the docs, "the WORD under
the cursor." I think of the cursor as being on a character, and a word
or WORD may start there ...)
HTH --Benji Fisher
Re: Vim crash..
On Sun, Apr 16, 2006 at 10:49:35PM -0400, sean wrote: > Hi, > First off, thanks for a great editor! Sorry to be dropping in with a > problem ;o) > > When I start the Vim beta here[1] things work great. However, dropping > to the shell with :sh and then trying to start another copy of vim > results in a crash. Same thing happens when doing :!vim, that is: > > Vim: Caught deadly signal SEGV > Vim: Finished. > > The backtrace[2] lead me to suspect a problem with my .vimrc. Sure > enouch if I remove it, everything works as expected. However, even > an empty .vimrc causes the problem, so its not some quirk based on > the contents of my .vimrc. > > Happy to help do further testing if it's needed. > > Thanks again, > Sean > > [1] Fedora Core 5 + vim from development: vim-enhanced-7.0.d001-1, > vim-common-7.0.d001-1, vim-minimal-7.0.d001-1, vim-X11-7.0.d001-1 This was fixed in vim 7.0d002 or 7.0d003. It should certainly work in the latest, vim 7.0e. HTH --Benji Fisher
Re: Strange behavior with highlights defined in gvimrc
On Sun, Apr 16, 2006 at 02:57:37PM +0200, Georg Dahn wrote: > Hi! > > Since I dislike the highlights of 'Constant' and 'Title', which is > Magenta as default, I have defined in my gvimrc: > > hi Constant guifg=Maroon > hi Title guifg=Maroon > > I have no 'colo ...' or 'set background=...'. When gVim is open, the > Title is Maroon, but the Constant still is Magenta. Since in > gvimrc_example.vim some highlights are defined, too, I assume that this > should work. If I do 'set background=light' before defining above > highlights everything works well. In the example file the background is > not being set. On Sun, Apr 16, 2006 at 05:04:19PM +0200, Georg Dahn wrote: > Hi! > > > What does > > > >:verbose hi Constant guifg=Maroon > > > >show? > > Nothing. But the Constants are Maroon afterwards. Sorry, I meant to suggest trying :verbose hi Constant When I try this, it tells me that the Constant highlighting was set in $VIMRUNTIME/syntax/syncolor.vim . This file is :source'd after the :syn on command. In your gvimrc file, do you have the lines to override the defaults before or after this line? > Which could be related: I have a color scheme which decides if it takes > a dark or light scheme depending on the value of 'background'. In gVim > 6.4 I get the light scheme and in gVim 7.0 I get the dark one. > > > In addition to the above sort of debugging, you can add a line like > > > >let g:foo = "2006 April 16 background=" . &background > > > >to your color scheme file. The date stamp is to avoid confusion the > >*next* time you add debugging comments. > > :eval g:foo > > shows, that the value of 'background' is 'dark'. Shouldn't it be light > (docu: When starting the GUI, the default value for 'background' will be > "light")? The rest of the paragraph you quote contains various exceptions to this. I cannot guess what should be happening without seeing more of your gvimrc file. What I am sure of is that, when vim processes the color scheme, 'background' is set to "dark" and so the color scheme is choosing the way it is supposed to. HTH --Benji Fisher
Re: Strange behavior with highlights defined in gvimrc
On Sun, Apr 16, 2006 at 02:57:37PM +0200, Georg Dahn wrote: > Hi! > > Since I dislike the highlights of 'Constant' and 'Title', which is > Magenta as default, I have defined in my gvimrc: > > hi Constant guifg=Maroon > hi Title guifg=Maroon > > I have no 'colo ...' or 'set background=...'. When gVim is open, the > Title is Maroon, but the Constant still is Magenta. Since in > gvimrc_example.vim some highlights are defined, too, I assume that this > should work. If I do 'set background=light' before defining above > highlights everything works well. In the example file the background is > not being set. What does :verbose hi Constant guifg=Maroon show? > Which could be related: I have a color scheme which decides if it takes > a dark or light scheme depending on the value of 'background'. In gVim > 6.4 I get the light scheme and in gVim 7.0 I get the dark one. In addition to the above sort of debugging, you can add a line like let g:foo = "2006 April 16 background=" . &background to your color scheme file. The date stamp is to avoid confusion the *next* time you add debugging comments. HTH --Benji Fisher
Re: :!gvim does not work
On Sat, Apr 15, 2006 at 03:41:17PM +0200, Bram Moolenaar wrote:
>
> Hmm, I did fix a problem for setting $MYVIMRC: in vimrc_found() the
> "dofree" option wasn't initialized to FALSE. If this is missing in your
> source code is missing that might be the cause of the crash.
>
> The start of the vimrc_found() function should look like this:
>
>void
> vimrc_found(fname, envname)
> char_u*fname;
> char_u*envname;
> {
> int opt_idx;
> int dofree = FALSE;
> char_u*p;
Upgrading from 7.0d to 7.0d03 seems to fix the problem.
--Benji Fisher
Re: double click to close tab on win32
On Sat, Apr 15, 2006 at 01:48:34PM -, fangread wrote: > Bram wrote: > > Closing a tab cannot be undone, thus I don't think it should be done > > too easily. It's easy to double click while you meant to click once > > two times. > I know the reason now. > > How about providing a option? It's disable to double clicking to close > tab by default. It's really a convenient operation existing in a lot of > GUI programs, and a lot of people was used to it. In many cases, > opening a new tab is an temporary action. > It's user's duty to use this function. However, if vim does not > provides this mechanism, user will never get a chance of using the > speedy function. > I really hope the function can be added to vim. :) I would like to see a way to map mouse events in the tab line. Maybe someone out there wants to use this to run :make on the buffer. Something like :map ... where I get to fill it in with whatever works for me. I guess this is too much to expect now that vim 7.0 is well into beta testing. --Benji Fisher
Re: :!gvim does not work
On Fri, Apr 14, 2006 at 09:24:35PM -0400, Benji Fisher wrote: > On Fri, Apr 14, 2006 at 03:11:13PM +0200, Bram Moolenaar wrote: > > > > Check: it doesn't matter how you started the Vim in which you do > > ":!gvim"? > > Good question. This works: > > $ vim -u NONE > :!gvim > > But guess what? This works, too: > > $ vim -u ~/.vimrc > :!gvim Another thing that works: if I fire up vim 7.0c01 then both :!gvim " vim 7.0d :!vim7c/src/vim -g " vim 7.0c01 work. Of course, with this version, :echo $MYVIMRC does nothing. (I mention this because it is the only part of the code I know of that was added recently and cares about -u arguments.) HTH --Benji Fisher
Re: Autoformatting using vimscript
On Sat, Apr 15, 2006 at 12:22:06PM +0530, Praveena M wrote: > Hi, > > I am new to vim-dev. > > I am looking for some pointers to implement auformatting perl programs > (similar to perltidy) using vim script. Vim has features to adjust the indentation automatically, but not to break up lines of code. If that suits you, see :help indent-expression in the vim docs. (That is a short entry, and the docs do not say a lot about it. The most useful pointer in the section I suggest may be to the examples.) If you want to do more than adjust the indentation, it may be easier to call perltidy to do the work. :help 'equalprg' :help = HTH --Benji Fisher
Re: [bug] Error detected while processing function 10_Highlight_Matching_Pair:
On Fri, Apr 14, 2006 at 09:25:21PM +0200, Nicolas Weber wrote: > Hi, > >The error is: > > > >Error detected while processing function 10_Highlight_Matching_Pair: > >line 41: > >E121: Undefined variable: c_lnu > > > This was fixed in vim7d iirc. Try to upgrade. Until the CVS server gets back to normal, the best way to get the current source is from ftp://ftp.vim.org/pub/vim/unstable/snapshot/ . If you have a slow connection, I understand not wanting to use this all the time. HTH --Benji Fisher
Re: :!gvim does not work
On Fri, Apr 14, 2006 at 03:11:13PM +0200, Bram Moolenaar wrote: > > Benji Fisher wrote: > > > The problem is neither python nor plugins. This is the default > > version compiled on FC2, with Normal features, -python. When I start > > gvim with > > > > :!gvim -u ~/.vimrc ~/.gvimrc > > > > there is no segfault and I get the same plugins as if I do > > > > $ gvim > > > > I only get the segfault with > > > > :!gvim > > Well, there must be something different. > > Check: it doesn't matter how you started the Vim in which you do > ":!gvim"? Good question. This works: $ vim -u NONE :!gvim But guess what? This works, too: $ vim -u ~/.vimrc :!gvim Curiouser and curiouser! > Perhaps you can check what differences there are between using "gvim" > without arguments (which crashes) and "gvim -u ~/.vimrc -U ~/.gvimrc" > (which doesn't crash). E.g., with ":scriptnames". I already tried that, and I repeated it with the above tests. $ gvim :redir @a :scriptnames :redir END :put a Then visually select and yank into @+ (to avoid blank lines). Then $ vim :!gvim and repeat the process (but not into @+) and compare. This is the closest I can come: there is no way to do :scriptnames in the one that actually crashes. There should not be any difference, should there? I do not have a $VIMINIT environment variable. Nor do I have a system [g]vimrc file. --Benji Fisher
Re: odd completion (mis)behavior
On Fri, Apr 14, 2006 at 12:42:53PM +0200, Bram Moolenaar wrote: > > Benji Fisher wrote: > > > I am a few days behind: vim 7.0d (Linux). > > > > I have the text "Mary Ellen" and "May 2" in my buffer. I want to > > type "Mary Ellen" again, so (not noticing the "May 2") I do > > > > Ma > > > > but that gives me > > > > May 2 > > > > Oops! So I type a few times (three, to be exact). Much to my > > surprise, I get > > > > May x=EF=BF=BD> =10Ma > > > > (In case it gets garbled in translation, that looks like > > > > May x<99>> ^PMa > > > > to me.) When I repeat the experiment, I get different garbage, so I am > > guessing that there is an uninitialized variable here. > > I guess the state for adding completion isn't reset properly when you > backspace. The patch below makes it work better for me. But I could > not reproduce the "garbage" thus I can't verify that is fixed too. The patch gets rid of the garbage. There is still a slight problem. After Ma I now have Ma as expected. The pop-up menu shows "Mary" (selected) and "May", but the buffer just shows "Ma". One leaves me with "Ma" and nothing selected in the menu; another gives me "May", and a third gives me "Mary" (with the buffer matching the menu selection). IMO when I have "Ma" in the buffer, nothing should be selected from the pop-up menu. For the sake of users, like me, who are used to the old CTRL-X mode, I suggest the following addition to doc/insert.txt . Maybe a reference to |ins-completion-menu| would be better than the suggested |popupmenu-keys|. Or even rewrite the paragraph about CTRL-X mode above the lines I added. --Benji Fisher *** src/vim70d03/runtime/doc/insert.txt 2006-04-11 16:50:30.0 -0400 --- - 2006-04-14 08:47:29.251949000 -0400 *** *** 1,4 ! *insert.txt*For Vim version 7.0d. Last change: 2006 Apr 11 VIM REFERENCE MANUALby Bram Moolenaar --- 1,4 ! *insert.txt*For Vim version 7.0d. Last change: 2006 Apr 14 VIM REFERENCE MANUALby Bram Moolenaar *** *** 590,595 --- 590,598 CTRL-X mode command. Valid keys are the CTRL-X command itself, CTRL-N (next), and CTRL-P (previous). + If 'completeopt' comtains "menu" (the default), then the special meanings + described under |popupmenu-keys| apply. + Also see the 'infercase' option if you want to adjust the case of the match. *complete_CTRL-E*
Re: :!gvim does not work
On Fri, Apr 14, 2006 at 12:42:53PM +0200, Bram Moolenaar wrote: > > Mikolaj Machowski wrote: > > > Dnia czwartek, 13 kwietnia 2006 17:19, Bram Moolenaar napisa³: > > > Benji Fisher wrote: > > > > I just tried > > > > > > > > :!gvim > > > > > > > > and all I got was > > > > > > > > Vim: Caught deadly signal SEGV > > > > Vim: Finished. > > > > > > > > Command terminated > > > > > > > > Press ENTER or type command to continue > > > > > > > > I am using vim 7.0d on Linux (FC2). I get the same result running vim > > > > (in a gnome-terminal) or gvim. > > > > > > Works fine for me... Check what program is actually executed, perhaps > > > in a ":!" shell $PATH is different. > > > > Confirming for vim7.0d on Linux Mandriva 2006.0 . $PATH is the same in > > terminal and inside vim. > > > > Problem is in script-space. when both calls are with -u/U NONE I can > > play with any level. Seem that Benji and me have the same plugins :) > > It would be good if you can pinpoint the script that causes a problem. > > I first suspected it would have something to do with compiling with > Python support, thus using threaded libraries, but if -u NONE avoids the > problem it must be something else. The problem is neither python nor plugins. This is the default version compiled on FC2, with Normal features, -python. When I start gvim with :!gvim -u ~/.vimrc ~/.gvimrc there is no segfault and I get the same plugins as if I do $ gvim I only get the segfault with :!gvim --Benji Fisher
Re: [vim 70d] switching tab pages
On Thu, Apr 13, 2006 at 08:34:48PM -0400, James Vega wrote: > On Fri, Apr 14, 2006 at 01:18:19AM +0200, Wojciech Pilorz wrote: > > 2006/4/13, Bram Moolenaar <[EMAIL PROTECTED]>: > > > > > > Wojtek Pilorz wrote: > > > > > > > I have build gvim 7.0d on Fedora Core 4 as > > > > 'Big version with GTK2 GUI.' > > > > > > > > I have noticed the following behaviour with multple tab pages (gvim); > > > > > > > > 1. You can switch with Ctrl-Pgup - Ctrl-PgDown when in normal mode; > > > > In insert and replace mode you need to type Ctrl-O Ctrl-Pgup/PgDown > > > > (perhaps should be documented?) > > > > > > It is documented. > > I could not find that, at least in tabpage.txt. > > And I do not think it is obvious. > > I find this no less obvious than not being able to switch windows or > buffers while in insert mode. It's called insert mode for a reason. > Beginners may be confused by this, but I think that's more because they > usually haven't fully grasped the concept of Vim being a modal editor. I agree that "it" is not documented, where "it" means the fact that the help for Ctrl-Pgup does not mention that this works only in Normal mode. It is "implicitly documented" in the sense that there is no tag for i_CTRL-, and it is not mentioned under ins-special-special , but that only helps if you already know vim (and its docs) pretty well. If you want vim to behave that way, then :inoremap :inoremap ought to do it. Similarly, you can switch windows (with the mouse, for example) while in Insert mode. If you care to search the archives (back a few years, perhaps) you will find that I gave advice on how to do this, mapping and using window-local variables. :help design-flexible HTH --Benji Fisher
Re: :!gvim does not work
On Thu, Apr 13, 2006 at 09:16:17AM -0700, Yegappan Lakshmanan wrote: > Hi Bram, > > On 4/13/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > > Benji Fisher wrote: > > > > > I just tried > > > > > > :!gvim > > > > > > and all I got was > > > > > > Vim: Caught deadly signal SEGV > > > Vim: Finished. > > > > > > Command terminated > > > > > > Press ENTER or type command to continue > > > > > > I am using vim 7.0d on Linux (FC2). I get the same result running vim > > > (in a gnome-terminal) or gvim. > > > > Works fine for me... Check what program is actually executed, perhaps > > in a ":!" shell $PATH is different. > > I am able to reproduce this crash only in the GTK version of gvim. > In the Motif and Win32 versions, it works fine. > > - Yegappan I do not think there is anything funny about the shell I get with :! . I tried :! echo $PATH :! echo $HOME :! which gvim :! gvim --version and got the expected results. It may have something to do with GTK. I am running the default build of vim on FC2, which means GTK2 GUI. Now for the odd part. Someone else suggested that it might be a script problem, so I tried -u NONE and other things. :!gvim " SEGV :!gvim -u ~/.vimrc -U ~/.gvimrc " no problem Yegappan, do you get the same result? Anyone else on GTK? --Benji Fisher
odd completion (mis)behavior
I am a few days behind: vim 7.0d (Linux).
I have the text "Mary Ellen" and "May 2" in my buffer. I want to
type "Mary Ellen" again, so (not noticing the "May 2") I do
Ma
but that gives me
May 2
Oops! So I type a few times (three, to be exact). Much to my
surprise, I get
May x�> Ma
(In case it gets garbled in translation, that looks like
May x<99>> ^PMa
to me.) When I repeat the experiment, I get different garbage, so I am
guessing that there is an uninitialized variable here.
BTW, can someone point me to where it explains what characters get
me out of completion mode and which do not? I expected to do it.
--Benji Fisher
