Re: [Announcement] Subversion repository location changed
Edward L. Fox wrote: On 5/10/07, Gautam Iyer [EMAIL PROTECTED] wrote: [...] I've a question, though: isn't bleeding-edge development done in https://svn.sourceforge.net/svnroot/vim/trunk ? That /would/ be the appropriate line for the latest sources, right? I don't know. I'm still asking Bram for the latest sources. Currently, trunk and 7.1 branch will be the same. As for me there is actually no 7.1 branch, as there is no separate development on the main branch and the 7.1 branch. As Vim is developed linearly all the source should go into trunk directory and at the moment a new version is announced this version should be tagged. Branch would need to be created if someone will be developing some big change that will require a stable base, like 7.0 release, and this change will be developed separately and in parallel with the main branch.
Re: replace VimScript
Nikolai Weibull wrote:
On 4/24/07, A.J.Mechelynck [EMAIL PROTECTED] wrote:
Nikolai Weibull wrote:
On 4/24/07, Ilya Sher [EMAIL PROTECTED] wrote:
[snip]
I mean, seriously, it's a lot more intuitive to write
Vim.options['formatoptions'] =
Vim.options['formatoptions'].replace('t',
)
than
:set fo-=t
It's all about domain specific languages. It's said so on the
internet.
More intuitive?
Yes, it would be more intuitive for me in case I did not know VimScript.
(and that's the context of the discussion if I understand correctly).
Of course something like
vim.options.format.auto_wrap_without_comments = false
would be even more intuitive but that's probably not the way
to go anyway (making it so much more verbose just for beginners).
[snip]
--
For robots (please don't mail me there): [EMAIL PROTECTED]
Re: replace VimScript (was: wish: allow a: in the function def)
Robert Lee wrote: [snip] Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe using SpiderMonkey) so that people don't need to learn a new language If I understand you correctly, you assume that ECMAScript is the most popular language among the people that wish to customize VIM. How do you know the assumption is right? [snip] -- For robots (please don't mail me there): [EMAIL PROTECTED] My real email is ilya @ same domain
Re: replace VimScript
Yakov Lerner wrote: [snip] So do not worry, replacement of vimscript by the favourite language of some vim's random user is not going to happen. That is obvious. The point was the question why the OP named language X and not Y for this. Yakov -- For robots (please don't mail me there): [EMAIL PROTECTED]
Re: syntax highlighting and very long lines vim7
Sam Halperin wrote: I am trying to syntax highlight a file containing one very long line. (A machine generated chunk of ascii that needs to be visually checked when an error occurs.) The highlighting works up to about a screens worth of text (~2400 char), but stops highlighting well before the end of the line. If I insert a line break at the point that the highlighting ends, the first pages worth of the remaining block is highlighted. wrap/nowrap does not seem to affect this. If possible I would like to solve this without having to chop up the line. :help 'synmaxcol'
Re: Vim 8 enhancements
Rene de Zwart wrote: I would like it if vim could integrate more into a graphical application for instances an ide. The integration would allow application builders to use vim as a component. relief them of the burden of maintaining an editor Give them access to 20+ years matured editor code base If you take eclipse as an example then it integrate an editor with other services. like defining a project keeping an eye on the files in the project doing an update on the tags when the file has changed handling the integration with source code control systems handling the build. Vim is good at editing files that is it intended purpose and it works very well. I'm working with eclipse and a often hindered by its editor. Vim does already integrate. In vim7 you can call on an existing vim and open the file in a newtab. If vim could signal to the calling process when the file is written. I'm not suggesting that vim integrate into the graphical application. more an api for editing files. something like Hey Mr VIM here is my first file. BTW this is the tagfile and use this completion file Hey Mr Vim here is an other file BTW this is the completion file for this Thanks Mr Vim for telling me that the file has changed Thanks Mr Vim for telling me that the file has changed and closed Thanks Mr Vim for telling me that you closed down Externalizing the client-server communication part as an library and enhancing the interface? Rene Maybe you can try this: http://vimplugin.sourceforge.net/ or this: http://sourceforge.net/projects/eclim/
Re: JavaScript indentation
Gregory Seidman wrote:
I'm finding that smartindent is routinely wrong about how I want things to
be indented in JS, but I haven't been able to find an indent script. I'd be
interested in working on it myself, but I don't know the first thing about
how the function referred to when setting indentexpr is expected to behave.
Is anyone already working on an indentation file for JavaScript? If so, I'd
be interested in helping. If not, would anyone be interested in
collaborating on it?
--Greg
Hi,
I have a pretty working JS indentation script - javascript.vim, but it
handles only most common cases. It uses the build in C indentation
rules and does a bit of correction. Really much more corrections is
required in order to indent JavaScript correctly for all the cases.
Maybe C indent is a bad starting point for a complete JavaScript
indentation solution. I've also tried using syntax in order to
calculate indentation but this attempt lead me to even worth results -
javascript.vim.bad. Maybe you can fix the syntax based version, as it
is more promising. IIRC some changes were required in the syntax script
in order to get better indentation results...
Currently I'm not programming in JavaScript, so I doubt I can devote
much time to fixing its indentation script. But probably I will be, so
I am interested in having a complete JavaScript indentation solution in Vim.
Description: ECMAScript indenter
Author: After Johannes Zellner [EMAIL PROTECTED]
URL: http://www.zellner.org/vim/indent/html.vim
Last Change: Fri, 7 May 2004 20:00:00 +0200
Globals:
Only load this indent file when no other was loaded.
if exists(b:did_indent)
finish
endif
let b:did_indent = 1
[-- local settings (must come before aborting the script) --]
setlocal indentexpr=ECMAScriptIndentGet(v:lnum)
setlocal indentkeys=o,O,*Return,BS,{,}
set cpo-=C
fun! SIDGetSyntax(lnum)
let s1Comment = 0
let s2Comment = 0
if syntax == ''
return ''
endif
let s1 = synIDattr(synID(a:lnum, matchend(getline(a:lnum), '^\s*') + 1,
1), 'name')
if s1 == ''
let s1 = 'java'
endif
if s1 =~? 'comment'
let s1Comment = 1
endif
let s1 = matchstr(s1, '^\(java\)')
if strlen(getline(a:lnum)) = 1
let s2 = s1
let s2Comment = s1Comment
else
let s2 = synIDattr(synID(a:lnum, match(getline(a:lnum), '\s*$')
- 1, 1), 'name')
if s2 == ''
let s2 = 'java'
endif
if s2 =~? 'comment'
let s2Comment = 1
endif
let s2 = matchstr(s2, '^\(java\)')
endif
if s1Comment s2Comment
return 'comment'
endif
if s1 == 'java' s2 == 'java'
return 'java'
endif
if s1 == s2
return s1
endif
return ''
endfun
fun! ECMAScriptIndentGet(lnum)
Syntax of current line
let curSyntax = SIDGetSyntax(a:lnum)
let restore_ic=ic
let ic=1 ignore case
let ind = 0 Indent in sw multipliers. Added to indent of previous
line.
let presizeIndent = -1 Indent in spaces. int is ignores if
presizeIndent != -1.
Script source is indented seperatly from commments.
if curSyntax == 'java'
Find a non-empty line above the current line.
let plnum = prevnonblank(a:lnum - 1)
let prevSyntax = SIDGetSyntax(plnum)
Skip comments.
BUG: will not work when comments is mixed with other text in
the same line.
while plnum 0 (prevSyntax == 'comment' || prevSyntax == '')
let plnum = prevnonblank(plnum - 1)
let prevSyntax = SIDGetSyntax(plnum)
endwhile
Hit the start of the file, use zero indent.
if plnum == 0
presizeIndent = 0
else
Add 1 sw indent for each non closed { or (.
let ind = strlen(substitute(getline(plnum), '[^{(]\+',
'', 'g')) -
\
strlen(substitute(getline(plnum), '[^})]\+', '', 'g'))
let restPos = matchend(getline(plnum), '^\s*}')
if restPos == -1
let ind = strlen(substitute(getline(plnum),
'[^{]\+', '', 'g')) -
\
strlen(substitute(getline(plnum), '[^}]\+', '', 'g'))
else
let rest = strpart(getline(plnum), restPos)
let ind = strlen(substitute(rest, '[^{]\+', '',
'g')) -
\
Re: Problems with AutoIndenting comment lines in VHDL files
David le Comte wrote: This is my 2nd attempt, but with smaller sample vhdl file, The mail handler rejected my last email due to its being too large. Problem Description: When editing VHDL files, autoindent mode does not behave as expected with comment lines. I suggest that there is a problem with GetVHDLInsert(). I can not find function with name GetVHDLInsert in my vim source. Maybe you mean GetVHDLindent?. The problem may have something to do with how tabstop and softtabstop are set. Detailed Description: - With tabstop=4, when either opening a new comment line, or continuing in text insert mode from one comment line to the next, the new comment line will autoindent as one expects, ie it will start in-line with the previous comment line, BUT, after typing some text, the line will suddenly re-indent itself, usually a couple of spaces from the beginning of the line. I can not reproduce this behavior. But I can see that indentation is incorrect when tabstop is not 1. Maybe we have different versions of an indent file? I have version 1.36 by Gerald Lai laigera+vim?gmail.com. I can see that there is an updated version - 1.40 on vim.org, but it does not differ in the indentation logic from 1.36. After changing from tabstop=4 to tabstop=8, and setting softabstop=4, a new comment line will autoindent itself a long way in to the right from the previous line. This is purely a guess, but it seems to be treating spaces as though they were tabs? I have attached bugreport.txt as created by bugreport.vim, and also one of my VHDL files. Except for the vim version this bugreport is useless as for me. You shall use bugreport.vim just after you've reproduced the bug. Otherwise it contains rather general information, while your bug is very specific. In any case, automatically generated bug report does not contain script versions, so you shall include them in order to ensure we are on the same page. And the file you have attached it is so huge. Can the bug be reproduced on a small file? One or two lines length. Anyway, I have fixed a bug in my version of a VHDL indent script. Maybe this is the same bug you are experiencing. Please, try it. You should put the attached file into a $HOMEPATH\vimfiles\indent folder. vhdl.vim Description: application/octetstream
Re: BOF Vim 8 - Suggestions
John Beckett wrote: [...] Then, I could write an email to a friend saying Run gvim and do stuff to select a theme. Then you can press F11 to do clever thing. For example, perhaps F11 = :cn, Shift-F11 = :cp. [...] This sounds very like file types. When you are opening a file appropriate actions can be done automatically in order to adjust vim or you can do it yourself. So your do stuff to select a theme is spelled in vim like :set ft=file type. If you are writing an e-mail and you have vim set as your e-mail text editor it is possible that vim will detect you are writing an e-mail and will automatically adjust itself for e-mail editing. You may also add additional file types by downloading them from vim.org or somewhere else... So, most part of a file type specific settings should reside in a file type script. And if you have some general preferences them you should add them to your .vimrc. If a preference is file type specific you can add a FileType event to your .vimrc. I see no point in adding themes. As for me, everything that can be done using themes can already be done using things that already exists in vim. If you think that you can provide a better defaults for novice users you can just write a script that will adjust vim the way you see it and ask Bram to add it into the distribution along with a note in the tutor, like If you feel that vim is too difficult to master you may try another set of defaults specially crafted for novice users. In order to turn them on just add the following line to your .vimrc: here goes command to source your script.
Re: recent.vim plugin
Ilia N Ternovich wrote:
Hi all!
I'm trying to make recent.vim plguin working with vim-7.0
There is some kind of problem with mapping keys inside plugin:
function! OptionFiles()
let file = bufname(%)
if bufname()==recent_files
map Enter gf
set number
set noswapfile
else
set nonumber
set swapfile
if hasmapto('gf')
unmap gf
endif
endif
endfunction
command Recent edit ~/.vim/recent_files
autocmd BufEnter * :call OptionFiles()
I wonder why this function doesn't map Enter key to gf combination, when
I start vim... There is succesfully created recent_files buffer... But
keybinding doesn't work :(
Can anybody help me with this question
This is a bit off topic, but you probably want your function to look
like this:
function! OptionFiles()
let file = bufname(%)
if bufname()==recent_files
map buffer Enter gf
setlocal number
setlocal noswapfile
endif
endfunction
Not sure it will help with your problem, but this way all the changes are
buffer local.
autocmd and netrw
Hello, I have such line in my .gvimrc autocmd BufEnter * :lcd %:p:h (this is vim tip: http://vim.sourceforge.net/tips/tip.php?tip_id=101) but when I work with remote files via netrw it produces warning every time, 'cause scp copies remote files to /tmp dir Is there any way to determine whether file is opening via netrw to disable that autocmd? -- regards, Hegai Ilya
Re: syntax region match with braces
Peter Hodge wrote: Hello, I have the same problem with large PHP files, Vim gets confused in the midst of all the curly braces ... :-S Unfortunately I'm not yet familiar with the 'syn sync' commands, partly because they're so hard to test. Haven't followed the thread but :syntax sync fromstart usually works fine for me [snip] -- For robots (please don't mail me there): [EMAIL PROTECTED] My real email is ilya @ same domain
Re: FW: elastic tabstops and gvim's GTK text widget
Peter Hodge wrote: --- Nick Gravgaard [EMAIL PROTECTED] wrote: Hi Zdenek, On 30/10/06, Zdenek Sekera [EMAIL PROTECTED] wrote: Hi, Nick, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Gravgaard Sent: 19 October 2006 13:42 To: vim-dev@vim.org Subject: elastic tabstops and gvim's GTK text widget Hi all, I am the creator of a mechanism called elastic tabstops (see nickgravgaard.com/elastictabstops/). Right now, my plan is to try and implement this in as many text widgets as possible so that the editors that use them will be able to easily add this as a feature. Since vim (well, gvim really) is my editor of choice I thought I'd start with that. Could someone tell me which GTK widget gvim uses and what problems they think I might encounter? Any other comments are also welcome. I went to your side and read all about it, sounds very (read *very*) interesting. I would surely love it. As a comment, I'd suggest you reconsider implementing it only for gvim+GTK (as that's what I understood from all I read). First, it will quite significantly limit number of people who would be interested (not all have GTK when you go outside Linux) second, some people just do not use gvim (I for one use almost only console vim, I can't get gvim running with pleasing fonts and if it is not pleasing to my eyes, I don't like it). You seem to see a big advantage is being able to use non-monospce fonts. Sure, it is an advantage (perhaps even a big one), however, one gets very far with monospaced fonts, and I feel lots of people would think that way. In other words, those who can/want to run non-monospaced, great!, but don't leave out all the rest of us who have accomodated themselves well with monospaced outside of your project. Brief: consider seriously also the console vim. I think you may be right - I have a feeling vim is probably just treating it's GTK widget in a similar way to how it treats a console. If that's true, adding proportional font support is probably a much bigger task than I would like to solve right now... BTW, does anyone know if it's possible to implement elastic tabstops as a vim script? It would need to be called whenever a character is inserted or deleted and would then modify the size of the tabstops. The tabstops would need to have different widths on different lines. Is this possible? Actually, you might be able to get it done with Vimscript, but you'd need to use space characters instead of tabs. You would map TAB to call a function which examines the current line, the line above, the line below, and inserts the correct number of spaces, and also adjusts the lines above or below accordingly. Also, if you're inserting spaces instead of tabs, it's backwards compatible with just about everything, which would be great. But how will you save information about where is a tab and where is a space? You have to save tabs in a file on disk and in vim you'll have to remember where those tab were in some buffer local variable. cheers, Peter Send instant messages to your online friends http://au.messenger.yahoo.com
Re: insert-mode :map-alt-keys and 8-bit locales
A.J.Mechelynck wrote: Ilya Sher wrote: A.J.Mechelynck wrote: Alexey I. Froloff wrote: * Bram Moolenaar Bram@ [061022 17:41]: I don't want to support that, because it causes mistakes. Consider being in Insert mode and typing Esc o to open a new line or Esc n to find the next match. A timeout won't help, the two keys can be typed within ten msec. So, all plugins that imap something to Alt+Key a screwed up in all non-ascii 8-bit locales. Moreover, such maps breaks normal text entering. There is something outside your latin-1 world. Take a look around, you, 7-bit racists. - Maybe Bram Moolenaar can type at 100 keystrokes / second, I can't. Especially if one of the keys is Esc, which is far away from almost everything else. Assuming one-handed typing, (especially for Esco and Escn) which is almost always not true for vim users. Assumption that people use keyboard mappings where Esc is far away is true most of the time but not always. (Common exception is caps lock generating Esc). [snip] When I say I can't, I'm talking about me on my keyboard, where the Esc key is at top left, and the nearest keys are (²³¬) (1|) (é2@) and F1 (Between round brackets: unshifted, with Shift, and with AltGr, in that order, for a single key). I'm not assuming that _you_ cannot type 100 keystrokes per second, though I would bet that the Vimmers who can are a minority at best. ;-) I was probably not clear enough. The point is that one does not even have to type at that speed to hit pretty fast Esco if the Esc is not far away and both hands are used. ... the first condition is optional. Best regards, Tony. -- For robots (please don't mail me there): [EMAIL PROTECTED] My real email is ilya @ same domain
Re: [PATCH] cygwin: Trouble recognizing absolute path
Yakov Lerner wrote: [...] I mean, I tried 'ls c:\windows' in cygwin and it does not work .. strange is it issue of version of cygwin ? I saw even weirder differences in cygwin behaviour ... fat32 vs ntfs differences... Maybe this is because \ have a special meaning for bash or some other shell you use. Try ls c:\\windows works fine for me. It is 100% off-topic on vim-dev list, so I'm sorry. Yakov
Re: BUG: syntax region overlaps keyword *sometimes*
Peter Hodge wrote: Thanks for your help, I had another look and found out you need another syntax command to reproduce it properly. Here is the revised bug report Start vim using vim -u NONE insert the following test code (note that the 4th line must be indented). array($foo) is_array $foo is_array($foo) is_array($foo) Apply the following syntax commands: syn on syn keyword Function is_array syn region r1 matchgroup=Type start=/array(/ end=/)/ syn keyword Error foo containedin=NOTHING You will find that the keyword is_array and region r1 are confused over how to highlight is_array(...) when it doesn't start at the beginning of the line, and it has something to do with the 'foo' keyword having a 'containedin=' option. regards, Peter Yep, now I see this. Kind a strange highlight. I found that the highlight would be OK until foo is added, but then the bug could be seen even after :syn clear Error.
Re: BUG: syntax region overlaps keyword *sometimes*
Peter Hodge wrote: Hello, I have discovered that it is possible for a syntax region to overlap a syntax keyword, even though the region is not contained in the keyword. Take the following code example and apply the syntax commands below: TEST CODE: (is_array($foo)) ( is_array($foo) ) SYNTAX COMMANDS: syntax keyword Function is_array syntax region r1 matchgroup=Typedef start=/array(/ end=/)/ keepend extend Now what is even more odd, if I add another region for the ( and ) arround the test code, the overlap doesn't happen in the first example: syntax region r2 matchgroup=Delimiter start=/(/ end=/)/ keepend extend contains=ALL What is going on here? regards, Peter I do not see anything special. For me r1 does not contribute to highlighting at all, and r2 cause parenthesis to be highlighted. I have VIM - Vi IMproved 7.0 (2006 May 7, compiled Sep 22 2006 22:03:35) MS-Windows 32 bit GUI version with OLE support Included patches: 1-109 Also with changes from patch 117.
Re: Do Not Reply To This Message
A.J.Mechelynck wrote: [snip] The problem is, not only the KNBT pseudo-bounce is misdirected, it is incomplete. In particular, it doesn't say which address was not found, so all Felix (or Bram or someone) can know is that someone @knbt.com is no longer a valid address. But they can't go forcibly unsubscribing _every_ @knbt.com subscriber, can they? Quite probably there are more than one. Anyone knows how much of [EMAIL PROTECTED] are subscribed ? If they are not many we can even do manual check(s)... Best regards, Tony. -- For robots (please don't mail me there): [EMAIL PROTECTED] My real email is ilya @ same domain
Re: compilation of regular expressions/ enhancement?
Marc Weber wrote: When doing something like map([a,b],matchstr(v:val, \(.\))) will the regular expression \(.\) be compiled on every iteration? How about this: for l in lines if l =~regex ... ? How about :help profile ? ;) [...]
matchparen highlight bug
Hello.
I've found bug in highlighting when matchparen is used. Not sure it is
because of a matchparen thought.
Test case
=
gvim
i{}EschO
Now I can see first line with one character background been highlighted
and an insert cursor over it and '{}' on a second line, both highlighted.
Not sure how to reproduce this on -u NONE -U NONE...
VIM - Vi IMproved 7.0 (2006 May 7, compiled Sep 22 2006 22:03:35)
MS-Windows 32 bit GUI version with OLE support
Included patches: 1-109
Compiled by [EMAIL PROTECTED]
Huge version with GUI. Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset
+cindent +clientserver +clipboard +cmdline_compl +cmdline_hist
+cmdline_info +comments
+cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs -dnd
-ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path
+find_in_path
+folding -footer +gettext/dyn -hangul_input +iconv/dyn +insert_expand
+jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds
+localmap +menu
+mksession +modify_fname +mouse +mouseshape +multi_byte +multi_lang
-mzscheme +netbeans_intg +ole -osfiletype +path_extra -perl -postscript
+printer
+profile -python +quickfix +reltime +rightleft -ruby +scrollbind +signs
+smartindent -sniff +statusline -sun_workshop +syntax +tag_binary
+tag_old_static
-tag_any_white -tcl -tgetent -termresponse +textobjects +title +toolbar
+user_commands +vertsplit +virtualedit +visual +visualextra +viminfo
+vreplace
+wildignore +wildmenu +windows +writebackup -xfontset -xim -xterm_save
-xpm_w32
system vimrc file: $VIM\vimrc
user vimrc file: $HOME\_vimrc
2nd user vimrc file: $VIM\_vimrc
user exrc file: $HOME\_exrc
2nd user exrc file: $VIM\_exrc
system gvimrc file: $VIM\gvimrc
user gvimrc file: $HOME\_gvimrc
2nd user gvimrc file: $VIM\_gvimrc
system menu file: $VIMRUNTIME\menu.vim
Compilation: cl -c /W3 /nologo -D_MT -D_DLL -MDd -I. -Iproto
-DHAVE_PATHDEF -DWIN32 -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG
-DWINVER=0x0500 -D_WIN32_WINNT=0x0500 /Fo.\ObjGOd/ -D_DEBUG -DDEBUG /Od
-MDd -DFEAT_OLE -DFEAT_MBYTE -DFEAT_GUI_W32 -DDYNAMIC_ICONV
-DDYNAMIC_GETTEXT -DFEAT_HUGE /Zi /Fd.\ObjGOd/
Linking: link /DEBUG /DEBUGTYPE:cv /nologo /subsystem:windows
/incremental:no /nodefaultlib:libc advapi32.lib shell32.lib gdi32.lib
comdlg32.lib ole32.lib uuid.lib oldnames.lib kernel32.lib gdi32.lib
version.lib winspool.lib comctl32.lib advapi32.lib shell32.lib
/machine:i386 /nodefaultlib /fixed:no msvcrtd.lib oleaut32.lib
user32.lib WSock32.lib /PDB:.\ObjGOd/gvimd.pdb -debug
DEBUG BUILD
syntax. Contained items should not contribute to highlight outside of a containing keepend item highlighting area
Hello.
I'm continuing my investigation on Vim's syntax highlight for the
following syntax rules:
:syn cluster Top contains=Block,String,Identifier
:syn region Block start=+{+ end=+}+ keepend extend [EMAIL PROTECTED]
:syn region String start=++ end=++ contains=Identifier
:syn region Identifier start=+\${+ end=+}+ extend
and I've found that this code
{ block string } extra
is highlighted not exactly as I want it to be. Highlight is as follows:
{ block string } extra
S
The problem is that closing brace '}' is highlighted as a String because
Block does not have any kind of highlight and contained String region is
forcefully terminated at the same character as enclosing Block is.
So, I thought, that it would be logical that if I would limit Block
highlight to be completely inside braces then String would not highlight
brace character itself. It appears to be not the case. Here is a new
matching rule for Block:
:syn region Block start=+{+hs=e end=+}+he=s-1 keepend extend [EMAIL PROTECTED]
Problem is that when a region is terminated because an enclosing keepend
region is terminated, then the contained region highlight end is at the
same point as the keepend region match end is, while, from my point of
view, it should be where the keepend region highlight end is.
Here is a patch that makes Vim do as I want. Version 1 is for an
original syntax.c as it is in CVS now. Version 2 is for syntax.c that
was modified by my previous patch from extend inside normal inside
keepend e-mail.
Ilya Bobir
Index: syntax.c
===
RCS file: /cvsroot/vim/vim7/src/syntax.c,v
retrieving revision 1.62
diff -c -r1.62 syntax.c
*** syntax.c26 Apr 2006 23:58:59 - 1.62
--- syntax.c22 Sep 2006 19:38:24 -
***
*** 2564,2569
--- 2564,2570
{
int i;
lpos_Tmaxpos;
+ lpos_Tmaxpos_h;
stateitem_T *sip;
/*
***
*** 2583,2595
break;
maxpos.lnum = 0;
for ( ; i current_state.ga_len; ++i)
{
sip = CUR_STATE(i);
if (maxpos.lnum != 0)
{
limit_pos_zero(sip-si_m_endpos, maxpos);
! limit_pos_zero(sip-si_h_endpos, maxpos);
limit_pos_zero(sip-si_eoe_pos, maxpos);
sip-si_ends = TRUE;
}
--- 2584,2597
break;
maxpos.lnum = 0;
+ maxpos_h.lnum = 0;
for ( ; i current_state.ga_len; ++i)
{
sip = CUR_STATE(i);
if (maxpos.lnum != 0)
{
limit_pos_zero(sip-si_m_endpos, maxpos);
! limit_pos_zero(sip-si_h_endpos, maxpos_h);
limit_pos_zero(sip-si_eoe_pos, maxpos);
sip-si_ends = TRUE;
}
***
*** 2600,2605
--- 2602,2614
|| (maxpos.lnum == sip-si_m_endpos.lnum
maxpos.col sip-si_m_endpos.col)))
maxpos = sip-si_m_endpos;
+ if (sip-si_ends
+(sip-si_flags HL_KEEPEND)
+(maxpos_h.lnum == 0
+ || maxpos_h.lnum sip-si_h_endpos.lnum
+ || (maxpos_h.lnum == sip-si_h_endpos.lnum
+maxpos_h.col sip-si_h_endpos.col)))
+ maxpos_h = sip-si_h_endpos;
}
}
*** syntax.cFri Sep 22 22:39:57 2006
--- syntax.c.newFri Sep 22 22:26:23 2006
***
*** 2574,2579
--- 2574,2580
{
int i;
lpos_Tmaxpos;
+ lpos_Tmaxpos_h;
stateitem_T *sip;
/*
***
*** 2593,2605
break;
maxpos.lnum = 0;
for ( ; i current_state.ga_len; ++i)
{
sip = CUR_STATE(i);
if (maxpos.lnum != 0)
{
limit_pos_zero(sip-si_m_endpos, maxpos);
! limit_pos_zero(sip-si_h_endpos, maxpos);
limit_pos_zero(sip-si_eoe_pos, maxpos);
sip-si_ends = TRUE;
}
--- 2594,2607
break;
maxpos.lnum = 0;
+ maxpos_h.lnum = 0;
for ( ; i current_state.ga_len; ++i)
{
sip = CUR_STATE(i);
if (maxpos.lnum != 0)
{
limit_pos_zero(sip-si_m_endpos, maxpos);
! limit_pos_zero(sip-si_h_endpos, maxpos_h);
limit_pos_zero(sip-si_eoe_pos, maxpos);
sip-si_ends = TRUE;
}
***
*** 2610,2615
--- 2612,2624
|| (maxpos.lnum == sip-si_m_endpos.lnum
maxpos.col sip-si_m_endpos.col)))
maxpos = sip-si_m_endpos;
+ if (sip-si_ends
+(sip-si_flags HL_KEEPEND)
+(maxpos_h.lnum == 0
+ || maxpos_h.lnum sip-si_h_endpos.lnum
+ || (maxpos_h.lnum == sip-si_h_endpos.lnum
+maxpos_h.col sip-si_h_endpos.col)))
+ maxpos_h = sip-si_h_endpos;
}
}
Re: text is gone
scott wrote: [...] why would cindent kick in if i'm not editing c? [...] Maybe you set it yourself or some plugin set it for you. A.J.Mechelynck proposed you really good thing. Remove code that turns cindent off, restart vim and type :verbose set cindent? and you will see where this option was set last. If this would not make it clear for you who is setting cindent, then, I believe, you can post result of this command here and somebody could help you understand vim a bit better.
Re: Syntax matching. extend inside normal inside keepend
Yakov Lerner wrote:
On 9/3/06, Ilya [EMAIL PROTECTED] wrote:
Yakov Lerner wrote:
On 9/2/06, Ilya [EMAIL PROTECTED] wrote:
Hello.
I have a question regarding syntax matching. I have some kind of
syntax
and I have some solution to highlight it, but it does not work the
way I
expect it to.
What I want: match syntax that consists of blocks (enclosed in {}),
strings (enclosed in ) and identifiers (starts with ${ and ends
with
}). Block end should also end any string that starts inside this
block.
My solution:
:syn cluster Top contains=Block,String,Identifier
:syn region Block start=+{+ end=+}+ keepend extend [EMAIL PROTECTED]
:syn region String start=++ end=++ contains=Identifier
:syn region Identifier start=+\${+ end=+}+ extend
Your 'keepend' option clearly causes '}' which is end of
identifier to terminate the enclosing block, in full accordance
with :help syn-keepend.
No, it does not because of an extend option. Here is a picture (I've
already included it in my previous mail):
{ string ${var} string }
BB
SS SS
II
B - Block region
S - String region
I - Identifier region
I got this information using synID function.
If I read ':help syn-keepend' right, then 'keepend' does not
allow a region on which it is used to have proper subregions.
Except for 'extend' regions. That is why Block is 'keepend' and
'extend'.
What if 'extend' can override only the 'keepend' of only
immediately enclosing region ? The example in :help syn-extend
only has examlpe of overriding 'keepend' of immediately containing
region. Does not say whether 'extend' acts all the way up
the stack of enclosing regions.
That is nearly my question (look at the topic). But, if you consider
the way Vim currently takes an extend region that is inside a normal
region that is inside a keeped you can see (as I've pictured) that
external keepend region is not ended but middle normal region is. And
this is strange to me. I was expecting someone to comment on this
matter. Is there any sense in this approach or it is kind of a bug?
Yakov
Re: Syntax matching. extend inside normal inside keepend
Yakov Lerner wrote:
On 9/3/06, Ilya [EMAIL PROTECTED] wrote:
Yakov Lerner wrote:
When I removed both 'keepend' and 'extend', it
started to work as expected.
No, it would not work as I want it to. Block would not end unclosed
String. Like this:
{ Some string with a quote ( ) inside }
What about the following example:
{
1 }
{
}
Do you want to distinguish mismatched double-quotes
within one line only, or across multiple lines ? As you
syntax is currently written, your intention is ambiguoius.
On one hand, your 'syntax region String' can span multiple lines.
On other hand, you want that '}' inside quoted string terminate a block.
Do you want to consider line ' 1 }' a line with
mismatched quote, or it's supposed to match quote on
after ' {' ? NB that your 'syntax region String' does allow
strings spanning multilpe lines.
In your example, according to the rules in my solution, there should be
2 Blocks with 2 Strings inside. And both Strings would be without
closing .
Like this:
{
BB
1 }
BB
{
BBSS
}
SSB
And my solution work just as I expect it to on this code.
Yakov
Re: Syntax matching. extend inside normal inside keepend
Yakov Lerner wrote:
When I removed both 'keepend' and 'extend', it
started to work as expected.
No, it would not work as I want it to. Block would not end unclosed
String. Like this:
{ Some string with a quote ( ) inside }
With ''kepend extend', it
apparently takes identifier-closing brace for a
block-closing brace. I don't know why.
Again no. I've wrote wrote about it in my original email:
For some reason an Identifier region ends a String region and a
second word 'string' is not highlighted as a string (and Vim says that
it has Block match there).
So Block is not ended, but String is.
You might also try another solution: the 'syn match'
for identifier instead of region.
I've tried using match. And there is not difference to using region.
Yakov
Re: Syntax matching. extend inside normal inside keepend
Yakov Lerner wrote:
On 9/3/06, Ilya [EMAIL PROTECTED] wrote:
Yakov Lerner wrote:
When I removed both 'keepend' and 'extend', it
started to work as expected.
No, it would not work as I want it to. Block would not end unclosed
String. Like this:
{ Some string with a quote ( ) inside }
Ah, I have a guess what can be the problem. Maybe
region does not like it when ending pattern ([]) is same as
beginning pattern. It does not know then whether to treat 2nd
double-quote as a beginning of new nested
region (string), or end of previous block (string).
I do not understand how ending pattern for the String region could be
connected to my case, could you please explain in more detail what is
your point?
Note that I want ` ) inside ' to be highlighted as a String, but with
`}' String highlight should stop. And this could be easily achieved
with proposed solution. Problem arises only when String contains
Identifier. In this case Identifier region ends also enclosing a String
region, but not enclosing Block region. Here is picture:
{ string ${var} string }
BB
SS SS
II
B - Block region
S - String region
I - Identifier region
I believe that matching could be as follows:
{ string ${var} string }
BB
SS
II
Here is a picture for Block that contains only one quote. It is
perfectly legal and match my expectations:
{ string with a quote ( ) inside }
SSS
Maybe you should try
'syn match' for both strings and identifiers.
I've tried using match for both the String and the Identifier - there is
absolutely no difference from using two regions or using one region and
one match.
(nested 'syn match'). Maybe you should look into perl.vim
how it does it.
I'll gladly look there, but could you please be more specific? Where in
Perl syntax there is such a situation when outer block ends all
contained blocks of different type? I've used perl syntax highlight for
some time and I cannot remember if I thought something similar there and
rereading and understanding whole syntax highlight scheme, I believe, is
quite a bit of work...
In Perl everything could be understood from syntax. There is no need
to force some region to end unexpectedly. I'm trying to improve Tcl
highlight - there you could not tell whether some Block contains code
and thus should be highlighted appropriately or it contains some
arbitrary data that does not follow any of the Tcl code rules or follow
some other code rules (like been SQL code), without evaluation program
itself.
Yakov
Re: Syntax matching. extend inside normal inside keepend
Sorry for duplicating, but my mailer for some reason removed several
spaces from my pictures.
Yakov Lerner wrote:
On 9/3/06, Ilya [EMAIL PROTECTED] wrote:
Yakov Lerner wrote:
When I removed both 'keepend' and 'extend', it
started to work as expected.
No, it would not work as I want it to. Block would not end unclosed
String. Like this:
{ Some string with a quote ( ) inside }
Ah, I have a guess what can be the problem. Maybe
region does not like it when ending pattern ([]) is same as
beginning pattern. It does not know then whether to treat 2nd
double-quote as a beginning of new nested
region (string), or end of previous block (string).
I do not understand how ending pattern for the String region could be
connected to my case, could you please explain in more detail what is
your point?
Note that I want ` ) inside ' to be highlighted as a String, but with
`}' String highlight should stop. And this could be easily achieved
with proposed solution. Problem arises only when String contains
Identifier. In this case Identifier region ends also enclosing a String
region, but not enclosing Block region. Here is picture:
{ string ${var} string }
BB
SS SS
II
B - Block region
S - String region
I - Identifier region
I believe that matching could be as follows:
{ string ${var} string }
BB
SS
II
Here is a picture for Block that contains only one quote. It is
perfectly legal and match my expectations:
{ string with a quote ( ) inside }
SSS
Maybe you should try
'syn match' for both strings and identifiers.
I've tried using match for both the String and the Identifier - there is
absolutely no difference from using two regions or using one region and
one match.
(nested 'syn match'). Maybe you should look into perl.vim
how it does it.
I'll gladly look there, but could you please be more specific? Where in
Perl syntax there is such a situation when outer block ends all
contained blocks of different type? I've used perl syntax highlight for
some time and I cannot remember if I thought something similar there and
rereading and understanding whole syntax highlight scheme, I believe, is
quite a bit of work...
In Perl everything could be understood from syntax. There is no need
to force some region to end unexpectedly. I'm trying to improve Tcl
highlight - there you could not tell whether some Block contains code
and thus should be highlighted appropriately or it contains some
arbitrary data that does not follow any of the Tcl code rules or follow
some other code rules (like been SQL code), without evaluation program
itself.
Yakov
Re: Syntax matching. extend inside normal inside keepend
Yakov Lerner wrote:
On 9/2/06, Ilya [EMAIL PROTECTED] wrote:
Hello.
I have a question regarding syntax matching. I have some kind of syntax
and I have some solution to highlight it, but it does not work the way I
expect it to.
What I want: match syntax that consists of blocks (enclosed in {}),
strings (enclosed in ) and identifiers (starts with ${ and ends with
}). Block end should also end any string that starts inside this block.
My solution:
:syn cluster Top contains=Block,String,Identifier
:syn region Block start=+{+ end=+}+ keepend extend [EMAIL PROTECTED]
:syn region String start=++ end=++ contains=Identifier
:syn region Identifier start=+\${+ end=+}+ extend
Your 'keepend' option clearly causes '}' which is end of
identifier to terminate the enclosing block, in full accordance
with :help syn-keepend.
No, it does not because of an extend option. Here is a picture (I've
already included it in my previous mail):
{ string ${var} string }
BB
SS SS
II
B - Block region
S - String region
I - Identifier region
I got this information using synID function.
If I read ':help syn-keepend' right, then 'keepend' does not
allow a region on which it is used to have proper subregions.
Except for 'extend' regions. That is why Block is 'keepend' and 'extend'.
Yakov
Re: Fixing cweb.vim
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.
Syntax matching. extend inside normal inside keepend
Hello.
I have a question regarding syntax matching. I have some kind of syntax
and I have some solution to highlight it, but it does not work the way I
expect it to.
What I want: match syntax that consists of blocks (enclosed in {}),
strings (enclosed in ) and identifiers (starts with ${ and ends with
}). Block end should also end any string that starts inside this block.
My solution:
:syn cluster Top contains=Block,String,Identifier
:syn region Block start=+{+ end=+}+ keepend extend [EMAIL PROTECTED]
:syn region String start=++ end=++ contains=Identifier
:syn region Identifier start=+\${+ end=+}+ extend
Here is a sample that shows that this solution does not work:
{
string ${var} string
}
For some reason an Identifier region ends a String region and a second
word 'string' is not highlighted as a string (and Vim says that it has
Block match there).
Question: why the String region is not restored after the Identifier
region ends?
P.S. Removing keepend from a Block makes highlighting right in this
example but then an important point that Block should end unmatched
String is lost.
P.P.S. Solution code is in 1.vim and test code is in 1.vim.test so you
may try it on your vim with
vim -s 1.vim 1.vim.test
Ilya
1.vim
Description: application/octetstream
{
string ${var} string
}
Re: Unable to use :setf from $VIMRUNTIME/ftdetect/*.vim
Alexey I. Froloff wrote: filetype.vim looks like: augroup filetypedetect ... Generic configuration file (check this last, it's just guessing!) au BufNewFile,BufRead,StdinReadPost * \ ... some files are being setf'ed to conf Use the plugin-filetype checks last, they may overrule any of the previously detected filetypes. runtime! ftdetect/*.vim augroup END So, if Vim sets filetype to conf, it is not possible to use :setf from ftdetect/*.vim, because of but only if not done yet in a sequence of (nested) autocommands. setf feature. Solution is simple - source ftdetect/*.vim before conf fallback. You can do set filetype=... if you want unconditionally set file type.
Re: yanking into register and using that in command
Denis Perelyubskiy wrote: hello, I am trying to emulate textpad. In textpad, when cursor is over some word and you press ctrl-f5 the search box pops up, and a word is in the input area. So, an equivalent behavior (at least for now :-)) in vim is to press ctrl-f5 and have a word show up in the string :vimgrep/WORD/j c:/projects/foo/**/*.[ch] I know how to do this in a kludgy way, by yanking the word with viwy. However, that kills the * register. The question is whether it is possible to do what i want through some temp register, without killing the * (or using the * and then restoring it): I could map ctrl f5 to something like (kludgy): nmap C-F5 ESCviwy:vimgrep/S-Insert/j c:/projects/kopera/**/*.[ch] map! C-F5 ESCviwy:vimgrep/S-Insert/j c:/projects/kopera/**/*.[ch] nmap C-F5 ESC:vimgrep/C-RC-W/j c:/projects/kopera/**/*.[ch] map! C-F5 ESC:vimgrep/C-RC-W/j c:/projects/kopera/**/*.[ch] :help c_C-R_C-W There must be a prettier way of doing that (and a way which does not kill the *) Could someone please point me to the right direction? thanks, denis
Re: Suggestion for a change to compiler/gcc.vim
Nikolai Weibull wrote: I am the maintainer of compiler/gcc.vim and I would like to propose the following change to its errorformat: @@ -20,7 +20,8 @@ setlocal errorformat= \\%f\\\,\ line\ %l%*\\D%c%*[^\ ]\ %m, \%D%*\\a[%*\\d]:\ Entering\ directory\ `%f', \%X%*\\a[%*\\d]:\ Leaving\ directory\ `%f', - \%DMaking\ %*\\a\ in\ %f + \%DMaking\ %*\\a\ in\ %f, + \%-G%.%# let cpo = s:cpo_save unlet s:cpo_save The reason for this change is that I find it tiresome that whenever a successful build it built, I have to press enter twice to first get through the shell output is finished, please hit Enter prompt and then Hi, I'm gcc command-line number one that successfully compiled file so and so, and hey, there are 18 more of these commands waiting for you to look through, so please begin by hitting Enter. I'm not quite sure that it may help, but do you know that you may mark line as been general information line? Specially for compiler version strings or other headers that can be skipped. See :help efm-ignore So the addition of %-G%.%# to exclude anything but the defined formats from the listing saves us the trouble of seeing useless compiler command-lines in the list of changes. However, this is a rather drastic measure, and may cause messages that people rely on to go missing. If so, then this patch is perhaps not for public consumption. We do have the chance to add these messages to the errorformat, however, so if someone has any suggestions, please do pass them on. Any comments? Thanks. nikolai
Re: [PATCH] Ask and you shall...em, find?
A.J.Mechelynck wrote: I prefer answers given on the command-line (with more if necessary) to appear in the default colors with the following exceptions: - It's OK for titles (as in the listing of autocommands) to appear in another colour; - It's OK for the xxx of :highlight display to appear in the concerned highlight group's colours. - It's OK for the More? prompt, the Hit-Enter prompt and the scroll menu (which are not part of the text) to appear in a distinct colour. So I agree with Bram that no special highlighting is needed for the reply to the :pwd command (and friends). Even if the netrw directory listing has subdirectories in a different colour (which is commendable), I don't want that colour to carry over into the command-line output of :pwd. Best regards, Tony. If color would be set using highlighting group, would not it be possible to turn in on and off according to your preferences?
Re: [PATCH] Ask and you shall...em, find?
Ilya wrote: A.J.Mechelynck wrote: I prefer answers given on the command-line (with more if necessary) to appear in the default colors with the following exceptions: - It's OK for titles (as in the listing of autocommands) to appear in another colour; - It's OK for the xxx of :highlight display to appear in the concerned highlight group's colours. - It's OK for the More? prompt, the Hit-Enter prompt and the scroll menu (which are not part of the text) to appear in a distinct colour. So I agree with Bram that no special highlighting is needed for the reply to the :pwd command (and friends). Even if the netrw directory listing has subdirectories in a different colour (which is commendable), I don't want that colour to carry over into the command-line output of :pwd. Best regards, Tony. If color would be set using highlighting group, would not it be possible to turn in on and off according to your preferences? Maybe it would be good to use some special highlighting group for command line results. Say CmdDirectory, this way one could adjust it without affecting directory highlighting in other places. Myself, I agree with Bram, highlighting pwd results is an overkill. pwd prints nothing but directory name, so there is nothing there to highlight.
Re: tab split scrolling problem
[EMAIL PROTECTED] wrote: All, I mentioned this problem once on the list before; however, the issue wasn't reproducible. Now I found a way to consistently reproduce it. 1. Open a new plain vim in a terminal. 2. :h to open a help window. 3. :wincmd o to close all other windows except the help window. 4. G to go to the last line. 5. c-e a few times (around 5) to scroll down. 6. :tab split to open a new tab. 7. :tabclose to close the new tab and return to the previous. After all of this, the space generated by scrolling (via c-e) disappears. --Matt Reproduced as described on VIM - Vi IMproved 7.0 (2006 May 7, compiled Jun 24 2006 14:17:06) MS-Windows 32 bit GUI version with OLE support Included patches: 1-35
Make_mvc.mak cosmetic patch
Hello. In Make_mvc.make there is such a sequence of characters that is understood ok by make but, because of a rough syntax definition, vim treats this sequence as a start of a character literal and highlights half of the file as a string. Fixing this issue inside syntax definition is not that easy, but Make_mvc.mak could be fixed just by adding a comment with additional in it. *** Make_mvc.mak26 Apr 2006 23:50:26 - 1.33 --- Make_mvc.mak24 May 2006 22:26:41 - *** *** 960,966 # $CFLAGS may contain backslashes and double quotes, escape them both. E0_CFLAGS = $(CFLAGS:\=\\) ! E_CFLAGS = $(E0_CFLAGS:=\) $(PATHDEF_SRC): auto @echo creating $(PATHDEF_SRC) --- 960,966 # $CFLAGS may contain backslashes and double quotes, escape them both. E0_CFLAGS = $(CFLAGS:\=\\) ! E_CFLAGS = $(E0_CFLAGS:=\) # $(PATHDEF_SRC): auto @echo creating $(PATHDEF_SRC)
Re: A patch to allow tabline wrapping
Bram Moolenaar wrote: In my opinion the tabline should be one line. When it wraps the UI looks ugly. Esp. if the currently selected tab page is in the first line. Maybe if lines would swap, so that line with selected tab would alway be the lowest one it would look nicer?
Re: New feature: bind layout of windows to keys?
Eric Arnold wrote:
I found that the contents of a particular ordinal tab number was too
fluid to be of much use to me, so I concentrated on making relative
navigation easier, but I could be alone in that.
The way it stands, you can make a macro sequence from inside the
script using:
{m}isc menu - {ma}cro keys
... from key: S-F1
... to keys: :1 tabnextCR
using the (: ex command passthrough).
SImilarly, outside the script,
nnoremap S-F1 :1 tabnextCR
accomplishes the same thing.
IIUC, gt is the same as S-F1 after :nnoremap S-F1 :1 tabnextCT
Re: New feature: bind layout of windows to keys?
Markus Mottl wrote: Hi, I'm new to the developer list so I don't know whether this has already been discussed here. One thing I encounter frequently is that I have tons of open buffers, especially also from different projects, and I would like to switch between sets of windows very quickly. It would be great if Vim had a feature that allowed me to bind the current layout of windows (buffers contained, positions + dimensions, etc.) to a key. Jumping between projects would then be really easy. One can, of course, use several terminals and start multiple Vim-instances in them, but this is inconvenient, because one cannot easily share data between them (registers, etc.). It seems to me that this feature should be fairly easy to implement. Any suggestions on how to approach this problem? Regards, Markus There is tabs in vim 7.0. They are almost exactly what you are talking about, except that, IIUC, there is no binding to a key. But it is possible, that some scripts could help. :help tabpage.txt
Re: New feature: bind layout of windows to keys?
Yakov Lerner wrote: On 6/8/06, Markus Mottl [EMAIL PROTECTED] wrote: Hi, I'm new to the developer list so I don't know whether this has already been discussed here. One thing I encounter frequently is that I have tons of open buffers, especially also from different projects, and I would like to switch between sets of windows very quickly. It would be great if Vim had a feature that allowed me to bind the current layout of windows (buffers contained, positions + dimensions, etc.) to a key. Jumping between projects would then be really easy. One can, of course, use several terminals and start multiple Vim-instances in them, but this is inconvenient, because one cannot easily share data between them (registers, etc.). It seems to me that this feature should be fairly easy to implement. Any suggestions on how to approach this problem? Vim has mechanism of mapping keys to user-defined commends/scripts/functions. If you can write vim function(s) that, say, delete current windows and then re-create desirable windows layout (using sequence of vim commands) then it's definitely possible to bind call to such a function to the key. You'll probably need one window-creating function per project. Only you know your window layout, so only you can write such function. Once you wrote the function, we'll help you to map it to the keys yuo select. I don't think vim is missing any elemental functionality needed for such scripts yuo describe. For more info: :help vim-script-info :help key-mapping Yakov There is a concept of sessions in vim (:help session) - close to what you are describing, but I doubt it is the very best way to work with several project at the same time.
Re: matchparen bug?
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 $iDown do you have the cursor after the parentheses, with the parentheses highlighted? Yes, I do. And after doing Down I have cursor after 'r' in 'another'. HTH --Benji Fisher
Re: matchparen bug?
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 $iDownDown 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. $iDownDown and cursor is to the left of 'o' in 'onmifunc'.
Re: matchparen bug?
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'm having VIM - Vi IMproved 7.0 (2006 May 7, compiled May 25 2006 04:17:33) MS-Windows 32 bit GUI version with OLE support Included patches: 1-17 that I've compiled myself from current CVS version. Matchparen.vim is dated 2006 May 11.
Redraw bug on WinXP with non-GUI tab line.
Hello. I've found bug in vim version VIM - Vi IMproved 7.0 (2006 May 7, compiled May 25 2006 04:17:33) MS-Windows 32 bit GUI version with OLE support Included patches: 1-17 In case incremental search is on, tab line some times is not visible. Steps to reproduce: gvim -u NONE -U NONE :e 1.txt :set is :tab sp /s after hitting 's' text is scrolled to a line containing 'six1' and tabline is empty - cleared with background color. 1 2 3 4 5 6 7 8 9 one1 10 11 12 13 14 15 16 17 18 19 two1 20 21 22 23 24 25 26 27 28 29 three1 30 31 32 33 34 35 36 37 38 39 four1 40 41 42 43 44 45 46 47 48 49 five1 50 51 52 53 54 55 56 57 58 59 six1 60 61 62 63 64 65 66 67 68 69 seven1 70 71 72 73 74 75 76 77 78 79 eight1 80 81 82 83 84 85 86 87 88 89 nine1 90 91 92 93 94 95 96 97 98 99 ten1 1 2 3 4 5 6 7 8 9 one2 10 11 12 13 14 15 16 17 18 19 two2 20 21 22 23 24 25 26 27 28 29 three2 30 31 32 33 34 35 36 37 38 39 four2 40 41 42 43 44 45 46 47 48 49 five2 50 51 52 53 54 55 56 57 58 59 six2 60 61 62 63 64 65 66 67 68 69 seven2 70 71 72 73 74 75 76 77 78 79 eight2 80 81 82 83 84 85 86 87 88 89 nine2 90 91 92 93 94 95 96 97 98 99 ten2
Re: Runtime error in explorer.exe when right clicking with vim70f gvimext.dll installed
Mathias Michaelis wrote:
Hello Vim List
I have a similar problem with the final vim 7.0, if I try to compile
it with Microsoft Visual Studio 2005 Express Edition. I don't get a
runtime error, but simply get no Edit with vim ... context menu
entries when I right-click on any file.
Solution to this problem partly depends on a Windows version you have.
When I right click on a file in explorer I get an MSVC Runtime error
dialog:
msvcr80.dll is the problem, but it isn't that the dll is missing,
gvimext.dll loads it from c:\windows\system32. The problem is that
gvimext.dll is loading the dll incorrectly (according to the error
dialog). Obviously the source for gvimext.dll hasn't changed in a
while, but I believe this means that the gvimext.dll can't be built
against VC 8.0 until this problem is resolved. :/
Starting from Windows XP SP2 and Windows 2003, msvcr80.dll should be
loaded from C:\WINDOWS\WinSxS\directory for the correct version of
MSVCR 8.0\msvcr80.dll. At least runtime linker now uses this
approach. This is part of Windows Side by Side Components subsystem.
Try copying src\GvimExt\gvimext.dll.manifest to wherever you've placed
gvimext.dll.
This would not work - DLLs does not use manifest files. For a DLL
manifest should be embedded as a resource inside the DLL itself.
This was the first thing I tried. Then I checked with Dependency
Walker and saw that MSVCR80.DLL was now found. But in spite of
that: I got no context menus.
This also happened to me - Dependency Walker reported that DLL could be
found, but runtime linker fails to load the DLL. Maybe, Dependency
Walker does not load a DLL, just checks that it could be found using
algorithm, that is outdated.
Then I tried
mt -outputresource:gvimext.dll -manifest gvimext.dll.manifest
to include the dll into the resources of gvimext.dll. That helped
nothing.
To include the manifest as a resource into the dll? I don't know
exactly why this was not working for you - maybe your manifest was wrong
or maybe it was included with wrong resource id.
Then I tried to add a file/file session to gvimext.dll.manifest:
file name=gvimext.dll
comClass
description=VIM Editor Context Menu Handler
clsid={51EEE242-AD87-11d3-9C1E-0090278BBD99}
threadingModel=Apartment/
/file
Helped nothing, independent of running mt.exe or not.
I am searching for solutions for days now, browsed all the msdn
library, but found nothing: gvimext.dll doesn't work when linked
against MSVCR80.DLL with Visual Studio 2005 Express Edition.
This issue is explained in MSDN in section about SxS - Side by Side
Components. I've attached patch against current GvimExt/gvimext.rc that
would make resource compiler add manifest inside generated DLL - this is
what is required to make it run on WinXP SP2 and Win2k3. And you'll
have to put these two manifests in GvimExt directory, resource compiler
would embed one of them depending on build type.
The only workaround is: I have to link gvimext.dll statically
against the C runtime library. Then, gvimext.dll needs about five
times more space on disk, but like that the context menu entries
appear although I hardly can't believe it any more %-]
Thanks in advance for any suggestions or hints!
With best regards
Mathias
In case you compile and link gvimext.dll on Windows with installed
Visual Studio 2005, then it automatically links DLL with the most recent
version of MSVCR - 8.0. This version is installed during VS 2005
installation. So, you would not be able to run this DLL on any other
version of Windows, without installing new version of MSVCR. There is a
redistributable for this, on comes with VS 2005 itself. VS 2005 even
knows when it is required and can automatically (at least sometimes)
merge this redistributable when you are creating an installation inside
VS 2005.
?xml version='1.0' encoding='UTF-8' standalone='yes'?
assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'
dependency
dependentAssembly
assemblyIdentity type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /
/dependentAssembly
/dependency
/assembly
?xml version='1.0' encoding='UTF-8' standalone='yes'?
assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'
dependency
dependentAssembly
assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /
/dependentAssembly
/dependency
/assembly
Index: gvimext.rc
===
RCS file: /cvsroot/vim/vim7/src/GvimExt/gvimext.rc,v
retrieving revision 1.2
diff -c -r1.2 gvimext.rc
*** gvimext.rc 6 Mar 2006 23:16:53 - 1.2
--- gvimext.rc 21 Mar 2006 22:49:44 -
***
*** 2,7
--- 2,14
//
#include resource.h
+ #include winver.h
+ #if
Re: Using py commands to evaluate text for balloon commands..
Yakov Lerner wrote: [...] Note that :py commands are not available in the sandbox. I dont know whether Balloon function is executed in the sandbox. Maybe it is not (then :py is available in the Balloon func), maybe it is (then :py is not available in the Balloon func). If you find out, I'm interested to hear your result. [...] Sandbox and balloon function issue was discussed ~5 month ago and vim was patched allowing bexpr to run non-sandbox commands _if_ it wasn't set in a modeline (this is so that bexpr could potentially get values from an external debugger or somewhere via Python/Perl extensions).
page scrolling
Hello, please, point me to the command, which allow to scroll page line by line, like in mc viewer (F3) with arrow keys Thank you -- regards, Hegai Ilya
Re: new + TabEnter is crashing
Eric Arnold wrote:
BTW, I can't get WinDbg to recognize the .pdb files, although I've set
the Symbol path to the directory containing them. Is there some trick
to this?
IIRU, you should set Symbol path one directory higher. At least this is
true for Windows symbols. Thous are extracted to
C:\Windows\Symbols\{dll,exe,drv,sys,...} and you should set your Symbol
path to point to C:\Windows\Symbols.
Re: new + TabEnter is crashing
Eric Arnold wrote:
BTW, I can't get WinDbg to recognize the .pdb files, although I've set
the Symbol path to the directory containing them. Is there some trick
to this?
IIRU, you should set Symbol path one directory higher. At least this is
true for Windows symbols. Thous are extracted to
C:\Windows\Symbols\{dll,exe,drv,sys,...} and you should set your Symbol
path to point to C:\Windows\Symbols.
Re: some problem with vim7f Beta
Linsong wrote: Martin Stubenschrott wrote: But I am still not very clear why the first entry in the menu is not highlighted? Is it not reasonable? I don't get any point that highlighting the first entry will make the behavior unreasonable. I think there shoud be an very good reason and I really want to know. Anyone can give some hints? :) I think, that you are saying that you want to highlight entry that is not inserted into buffer. And Bram and others, assume that if entry is highlighted than it means that it is inserted. That's why C-N highlights entry - because it inserts it into buffer.
Re: Code completion and entries with duplicate 'word' attributes.
Bram Moolenaar wrote: Since we are talking about completion, there is only one word to be completed toLowerCase. That it can have different arguments doesn't matter for inserting toLowerCase. You could have a function name ten times and need to type CTRL-N ten times to get to another word. I suggest you put alternate function arguments together with one word. Thus toLowerCase would have a menu item and info that shows both possible forms of arguments. I think it would be useful, if info window would allow more than one item of information associated with a word completion. And it would be possible to switch all of the info items with some additional pair of keys. Visual Studio uses such a scheme (though it uses tool tips instead of an info window) and some other IDEs. It would be cool, if such possibility would not be coded inside Vim core, but if it would be possible to implement it using scripts, by means of some events, that would be fired during completion process, for example. This way, it is possible that script authors would invent some other ways of representation of completion information.
