Progressive quickfix buffer / background compilations
I am trying to set up gvim 7 on Linux to function the way emacs does when you compile a program (M-x compile). That is, I would like: - the window to split, creating a compilation buffer (like :copen / :cwin) - vim to execute the compilation in a sub-process - vim to not bother me with a hit-enter prompt - vim to capture the output of the compilation so that it does not interrupt my editing by spewing all over the screen (I can do this by setting shellpipe but it still does a hit-enter prompt) - vim to update the quickfix buffer as it receives each line from the compile process output I can get *close* to this behaviour using copen, setting the shellpipe command and using the vim server and a custom script, similar to this post: http://tech.groups.yahoo.com/group/vim/message/59520 This solution is a bit messy and has problems. The main thing it lacks is progressively updating the quickfix buffer as the compilation progresses. I was wondering if there were any other people here who had (perhaps more recently) tried making this work. Also, if people are interested in making this work, I am prepared to fiddle for hours to get it and discuss options on this list until it does work. ;) Maybe even modify some vim source code. I think my best bet at making this work just the way I want it is to specify a shellpipe to pipe all output to my own script, set some option to rid myself of the hit-enter prompt, in my own script fork and return (so I can keep editing) but in the child process, eat up stdin and write it to vim's make errorfile, periodically sending commands to the vim server to refresh the quickfix buffer from disk. I could probably manage that, except that - I can't get rid of the hit-enter prompt (gah!) - I don't understand (yet) the logic of reloading the quickfix buffer. It seems to only reload after a :make. autoread doesn't seem to work on it, for instance. Still playing with this. Any hints or pointers would be welcome. -- Greg McIntyre
Re: The meaning of nothing... ?
On 9/29/06, Meino Christian Cramer [EMAIL PROTECTED] wrote: Hi, to get all the keys of my keyboard working with vim I looked through my ~/.vimrc and found a setting (nottybuiltin), which I do revert and now a few addtional keys (C-F1 for example) do work correctly. So it seems, that the xterm256 definition, which I use, isn't completly defined in my terminfo database. Can I dump (or whatever the correct nameing is) the xterm256 settings vim is using internally in a form which I can use to correct my (buggy?) terminfo database ? The closest form to what you ask is ':set terminfo '. It does not dump terminal defs in terminfo format, no, but it does show it in some format. Yakov
Re: splitting $HOME/.vimrc
you can run normal commands with
:normal
for example,
:normal dd
will delete a whole line
On Friday 29 September 2006 11:22, Meino Christian Cramer wrote:
From: A.J.Mechelynck [EMAIL PROTECTED]
Subject: Re: splitting $HOME/.vimrc
Date: Fri, 29 Sep 2006 05:04:30 +0200
Meino Christian Cramer wrote:
Hi,
for my zsh I split the .zshrc in several files, which contain only
related things. For example all bindkey-related things go into
.zsh.bindkey.
.zshrc only sources those parts if available. Make things more
readable.
I would like to do the same thing with my $HOME/.vimrc.
I looked into
:he source
but source seems to work for ex commands only, or ?
Is there a way, to source several files as startup files from
within $HOME/.vimrc, without a too great performance penalty on
startup time ?
Keep hacking!
mcc
Your vimrc is supposed to consist of ex-commands only (ex-commands are
the commands you can type in Normal mode by prefixing them with a colon;
in a script such as the vimrc, the colon is not necessary). So you should
be able to dissect your vimrc into, let's say,
if has('unix')
language messages C
else
language messages en
endif
runtime vimrc_example.vim
source ~/rc1.vim
source ~/rc2.vim
source ~/rc3.vim
An alternative would be to create user-plugins, scripts which you would
place in ~/.vim/plugin/ (for Unix) or ~/vimfiles/plugin/ (for Windows).
They would then be sourced automagically in (probably) alphabetical
order, just before the global plugins (i.e., after your ~/.vimrc): see
the output of the :scriptnames command.
(and if you don't yet have the required directory, create it with:
on Linux:
mkdir -p ~/.vim/plugin
on Windows:
cd %HOME%
md vimfiles
cd vimfiles
md plugin
Best regards,
Tony.
Hi Tony, :)
thank you for your helpful reply !
Initially I thought, ex-commands were only a small subset of all
commands, which can be used after :.
But...
If _all_ commands, which are valid after :, are ex-commands...the
situation is quite simple.
By the way: I am using Linux. Since kernel 1.1.54 my room has no
windows anymore ;)
Keep hacking!
mcc
--
[EMAIL PROTECTED]
Re: When I open foo.zcml I would like xml type syntax
On Fri, Sep 29, 2006 at 10:35:04AM +0200, KLEIN St?phane wrote: Hi, How can I configure vim to use XML syntax when I open *.zcml file ? See :h autocmd put this into a a file which is sourced on startup (eg .vimrc or a plugin-file) autocmd BufRead,BufNewFile *.zcml :set ft=xml Marc
Re: Progressive quickfix buffer / background compilations
Have a look at http://www.vim.org/scripts/script.php?script_id=1582 It's writne by me, (I don't know any perl so tried achieving the same using python) I saw you've already found the script by Luc, (link to his work is on the page, too) It's not perfect.. but much better (You'll see the commands to load the output into quickfixcycle there) You probably want to have a look at cf cg and cl Concerning opening quickfix.. I found it beeing most convinient to map :cope to a nice mapping. I'm using noremap m-s-om-s-q :c-uexec 'cope '.lines/3cr Concerning hitting-enter.. :silent! cmd might help HTH a little bit. Marc Weber
Using vimserver with multiple clearcase views
Hello Folks, I want to be able to use multiple clearcase views with vim (with vim in the vimserver model). Does any one have any suggestions to work with these ? The issue that I am finding is that I start a vimserver outside a clearcase view - Then I try to invoke vim by using the following command gvim --servername GVIMSERVER --remote ./lcdc_stn_gs_e.vhd I get the following message within the vim window - E344: Can't find directory /vobs/omap40_design_gs60/modules/lcdc_core/hdl/rtl in cdpath E472: Command failed` Now if I try to start the vimserver while in a view, no matter which view I try to invoke gvim --servername GVIMSERVER --remote from, it always picks up the view from which gvim was started initially. Any of you folks have good tips/suggestions about working with clearcase in a server/client mode ? Thanks Regards, Vikas
linebreak does not work with list
:help linebreak documents that it is not used when...'list' is on but this means that toggling list shifts the text. I noticed this is on the ToDo: 7 Make 'list' and 'linebreak' work together. Is this a difficult fix? -- Steve Hall [ digitect dancingpaper com ]
Unicode chars NEL, FF, LS, PS
Does anyone here know if Vim respects the following Unicode characters (represents them rather than just indicating literals): http://en.wikipedia.org/wiki/Newline#Unicode I'm not on a Unicode platform at the moment, but I'm wondering if Vim could ever have the listchars to do it like mined: http://towo.net/mined/mined-uni.png -- Steve Hall [ digitect dancingpaper com ]
Autmagically adding new lines when text gets too long
I have set textwidth=80 and would like Vim to automatically break a line (between words) when the line gets too big. However, this isn't working, Vim doesn't seem to be doing anything different. Is there some other option I need to set? Thanks, Jeremy
Re: Autmagically adding new lines when text gets too long
Hi! --- Jeremy Conlin [EMAIL PROTECTED] wrote: I have set textwidth=80 and would like Vim to automatically break a line (between words) when the line gets too big. However, this isn't working, Vim doesn't seem to be doing anything different. Is there some other option I need to set? Just do :set linebreak Where the lines are wrapped is determined by the option 'linebreak'. The default value should be ok. Best wishes, Georg ___ Yahoo! Photos NEW, now offering a quality print service from just 7p a photo http://uk.photos.yahoo.com
Re: Re: Autmagically adding new lines when text gets too long
Hi! --- Jeremy Conlin [EMAIL PROTECTED] wrote: No, linebreak just *displays* a broken line, I want a *real* broken line. I want Vim to insert EOLs for me. I thought that is what textwidth would do. Of course, you still have to set 'textwidth', too. :set textwidth=80 :set linebreak will do, what you want. The option 'linebreak' does not do any wrapping, but just determines where Vim will wrap long lines. These breaks can be soft (if the option 'wrap' is set) or hard (if 'textwidth' or 'wrapmargin' is set). Just read :h linebreak :h textwidth :h wrapmargin :h wrap :h breakat Best wishes, Georg ___ Yahoo! Photos NEW, now offering a quality print service from just 7p a photo http://uk.photos.yahoo.com
Re: Re: Re: Autmagically adding new lines when text gets too long
On 9/29/06, Georg Dahn [EMAIL PROTECTED] wrote: Hi! --- Jeremy Conlin [EMAIL PROTECTED] wrote: No, linebreak just *displays* a broken line, I want a *real* broken line. I want Vim to insert EOLs for me. I thought that is what textwidth would do. Of course, you still have to set 'textwidth', too. :set textwidth=80 :set linebreak will do, what you want. The option 'linebreak' does not do any wrapping, but just determines where Vim will wrap long lines. These breaks can be soft (if the option 'wrap' is set) or hard (if 'textwidth' or 'wrapmargin' is set). Just read :h linebreak :h textwidth :h wrapmargin :h wrap :h breakat Best wishes, Georg You were right (of course). I discovered the reason this was not working for me was because I didn't have the t option in formatoptions. Now that I have included that, it works! Thanks for your patience. Jeremy
Re: Using vimserver with multiple clearcase views
On 9/29/06, Mishra, Vikas [EMAIL PROTECTED] wrote: Hello Folks, I want to be able to use multiple clearcase views with vim (with vim in the vimserver model). Does any one have any suggestions to work with these ? The issue that I am finding is that I start a vimserver outside a clearcase view - Then I try to invoke vim by using the following command gvim --servername GVIMSERVER --remote ./lcdc_stn_gs_e.vhd I get the following message within the vim window - E344: Can't find directory /vobs/omap40_design_gs60/modules/lcdc_core/hdl/rtl in cdpath E472: Command failed` Now if I try to start the vimserver while in a view, no matter which view I try to invoke gvim --servername GVIMSERVER --remote from, it always picks up the view from which gvim was started initially. Any of you folks have good tips/suggestions about working with clearcase in a server/client mode ? When you define new clearcase view, it starts new subshell and only process which are children of this subshell see the files belonging to the view, thanks to the clearcase kernel magic. It follows that server will not see files from this view. (At least, definitely not under same filenames as client vim would see.) If what you want is you use is to edit *many* files from *one* view in one server-gvim, then the solution is to [re]start this gvim under the view shell. But If you want to access files from two different view in one gvim, then ask your clearcase admin how to access /view/user.view pathnames; ask your clearcase admin how to access 2 views without starting subshell. I think the answer for accessing /view filsystem lies in the domain of the clearcase admin. You'll need how to find out how to access clearcase view without starting a subshell. Yakov
Re: linebreak does not work with list
On 9/29/06, Steve Hall [EMAIL PROTECTED] wrote: :help linebreak documents that it is not used when...'list' is on but this means that toggling list shifts the text. I noticed this is on the ToDo: 7 Make 'list' and 'linebreak' work together. Is this a difficult fix? There must have been reason for this (linebreak ... is not used when...'list' is on). Is it because with list on, representation of tabs can be different/incorrect from correct representation, and visual line length will be incorrect ? Yakov
vim + cscope + nuweb
Hi, A question about this combination - I use cscope with vim, normally with C/C++. I have lately been using the literate programming tool 'nuweb' , somewhat similar to CWEB, based on Latex. The nuweb source files I have written have C/C++ code within them. I have a problem referencing cscope tags within vim in this case. It does not seem to know that underscores can be part of the symbol it is looking up. So it looks up a truncated version of the symbol. Using cscope with nuweb outside of vim works fine. So my question is, how can I tell vim that underscores are a valid character in this context? Thanks, Jim
Re: linebreak does not work with list
On 9/29/06, Steve Hall [EMAIL PROTECTED] wrote From: Yakov Lerner, Fri, September 29, 2006 2:24 pm There must have been reason for this (linebreak ... is not used when...'list' is on). Is it because with list on, representation of tabs can be different/incorrect from correct representation, and visual line length will be incorrect ? I'd say this should only be the case if list's tab representation differs (is only one char) from tabstop, but otherwise it shouldn't. That's right wrt visual line lengths. Going back to the fix linebreak when list is on: (a) would it be good enough to fix it for the case when list tab's representation is same as 'nolist' ? (i think this case is very easy to fix ), or (b) you want it fixed for both cases, also when list's tab representation differs (is only one char) from tabstop ? (the (b) case must be more difficult) ? So, did you mean (a) fix or (b) fix ? Yakov
Re: Move cursor in insert mode without breaking history?
On 9/28/06, Karl Guertin [EMAIL PROTECTED] wrote:
I'm trying to get vim to auto-close parenthesis and set it up so that
the closing paren jumps past the end of the inserted one. This mapping
does the trick
A followup. I do have this working
inoremap ()C-R=NoUndoMove(-1)CR
inoremap ) C-R=JumpTo(')').NoUndoMove(1)CR
function JumpTo(char)
undojoin | exe 'normal f'.a:char
return
endf
function NoUndoMove(offset)
call cursor(line('.'),col('.)+a:offset)
endf
Which does the movement without changing the undo stack. Hoorah.
Unfortunately, repeat (.) doesn't seem to repeat the cursor command.
It also doesn't repeat setpos() and setline(). As a result, the parens
move to the beginning of the insert on the repeats. E.g. typing (abc
shows up as (abc|) where | is the cursor position. Repeating the
insert gets me ()abc|. Any tips would be appreciated.
Re: linebreak does not work with list
On 9/29/06, Steve Hall [EMAIL PROTECTED] wrote: From: Yakov Lerner, Fri, September 29, 2006 3:43 pm On 9/29/06, Steve Hall wrote From: Yakov Lerner, Fri, September 29, 2006 2:24 pm There must have been reason for this (linebreak ... is not used when...'list' is on). Is it because with list on, representation of tabs can be different/incorrect from correct representation, and visual line length will be incorrect ? I'd say this should only be the case if list's tab representation differs (is only one char) from tabstop, but otherwise it shouldn't. That's right wrt visual line lengths. Going back to the fix linebreak when list is on: (a) would it be good enough to fix it for the case when list tab's representation is same as 'nolist' ? (i think this case is very easy to fix ), or (b) you want it fixed for both cases, also when list's tab representation differs (is only one char) from tabstop ? (the (b) case must be more difficult) ? So, did you mean (a) fix or (b) fix ? I'm only interested in (a). However, I imagine there would be enough opinions on fixing (b) here to have to provide a new option. :) No no, I don't expect anybody interested in (b). Yakov
Re: The meaning of nothing... ?
Yakov Lerner wrote: On 9/29/06, Meino Christian Cramer [EMAIL PROTECTED] wrote: Hi, to get all the keys of my keyboard working with vim I looked through my ~/.vimrc and found a setting (nottybuiltin), which I do revert and now a few addtional keys (C-F1 for example) do work correctly. So it seems, that the xterm256 definition, which I use, isn't completly defined in my terminfo database. Can I dump (or whatever the correct nameing is) the xterm256 settings vim is using internally in a form which I can use to correct my (buggy?) terminfo database ? The closest form to what you ask is ':set terminfo '. It does not dump terminal defs in terminfo format, no, but it does show it in some format. Yakov E518: Unknown option: terminfo I suppose you mean :set termcap. Best regards, Tony.
Re: linebreak does not work with list
Steve Hall wrote: :help linebreak documents that it is not used when...'list' is on but this means that toggling list shifts the text. I noticed this is on the ToDo: 7 Make 'list' and 'linebreak' work together. Is this a difficult fix? With 'list', tabs can be represented as ^I (if 'listchars' does not include tab:) or as the right number of characters (if it does). With 'linebreak' and 'wrap', virtual spaces are added in the middle of long lines to make them wrap at a 'breakat' character. I suppose the second case has more import than the first, and would require an additional suboption in 'listchars' to optionally represent those virtual spaces as other than spaces. Best regards, Tony.
Re: Autmagically adding new lines when text gets too long
Jeremy Conlin wrote: I have set textwidth=80 and would like Vim to automatically break a line (between words) when the line gets too big. However, this isn't working, Vim doesn't seem to be doing anything different. Is there some other option I need to set? Thanks, Jeremy With 'textwidth' set to 80, Vim should insert a hard line break after the rightmost space as you type the 81st character on a line. You can also use variants of the gq commands: gqq to reformat a line, Visualgq to reformat the Visual area, gqap to regormat a paragraph, gggqG to reformat the whole file. Best regards, Tony.
Re: Unicode chars NEL, FF, LS, PS
Steve Hall wrote: Does anyone here know if Vim respects the following Unicode characters (represents them rather than just indicating literals): http://en.wikipedia.org/wiki/Newline#Unicode I'm not on a Unicode platform at the moment, but I'm wondering if Vim could ever have the listchars to do it like mined: http://towo.net/mined/mined-uni.png Vim is a text editor, not a word processor. It does not necessarily show control characters as a word processor or a printer would. Even on a non-Unicode platform, you should be able to run a +multibyte version of gvim, set 'encoding' to UTF-8 while preserving the locale setting of 'encoding' in 'termencoding', and enter the characters according to :help i_CTRL-V_digit to see what happens. NEL (Next Line, 0x85) is an upper-ASCII control character. I expect Vim to represent it as 85 when 'encoding' is set to UTF-8. This, however, depends on the setting of the 'isprint' option. I don't know what this control character means. FF (Form Feed, 0x0C) is an ASCII control character; it should be represented as ^L in Unicode just as in Latin1. When sent to a printer, it usually causes a page eject. LS (Line Separator, L SEP, U+2028) and PS (Paragraph Separator, P SEP, U+2029) are Format characters according to Unicode http://www.unicode.org/charts/PDF/U2000.pdf . They are followed in the charts by Left-to-Right Embedding, Right-to-Left Embedding, Pop Directional Formatting etc. I don't expect Vim to handle them otherwise than any other character, i.e., fetch a glyph, if any (probably none) from your 'guifont'. In my Gnome2 gvim with 'encoding' set to UTF-8, both U+2028 and U+2029 display as single-width spaces. Best regards, Tony.
Re: linebreak does not work with list
On Fri, 2006-09-29 at 23:36 +0200, A.J.Mechelynck wrote: Steve Hall wrote: :help linebreak documents that it is not used when...'list' is on but this means that toggling list shifts the text. I noticed this is on the ToDo: 7 Make 'list' and 'linebreak' work together. Is this a difficult fix? With 'list', tabs can be represented as ^I (if 'listchars' does not include tab:) or as the right number of characters (if it does). With 'linebreak' and 'wrap', virtual spaces are added in the middle of long lines to make them wrap at a 'breakat' character. I suppose the second case has more import than the first, and would require an additional suboption in 'listchars' to optionally represent those virtual spaces as other than spaces. I don't think that indicating virtual space is important, these is a display device, not text in my file. -- Steve Hall [ digitect dancingpaper com ]
Re: taglist() bugs related to 'tags'
On Wed, 27 Sep 2006 at 9:53pm, Bram Moolenaar wrote:
Hari Krishna Dara wrote:
I am observing that the taglist() function is not sensitive to the
changes in 'tags' value. It also seems to cache the value of 'tags' as
of the time the function is called for the first time. To reproduce the
problem (you need to have patch 96 applied, otherwise there is another
bug in 7.0GA that could mask the bug that the below is trying to show),
- create a directory with at least one file that ctags recognizes. Make
a copy of this directory.
- Run ctags in both directories to create tags file. They will
essentially be identical.
- Start vim/gvim and cd to one of the directories. Have 'tags' set to
./tags.
- Execute taglist() on a tag that you know exists, something like:
:echo taglist('main')
- Now, cd into the other directory, and run the same command. You will
see that the tags are reported from the other directory.
- Change 'tags' to the absolute path to the second directory and run
the
echo command again. You will still observe that taglist() is using
the
previous tags file.
Can anyone confirm that they can reproduce this?
Did you take into account that Vim uses ./tags as the tags file
relative to the current file? Try editing another file after the :cd
command. Or use the value tags, which means the tags file in the
current directory.
Frankly speaking I didn't know that ./tags is relative to the current
file (I was expecting it to be relative to the current directory),
however that makes no difference to this bug.
- when you run taglist() in the above steps, there is no file opened.
- I repeated the experiment with just tags as the value for 'tags'.
- I also tried hardcoding the tags value to the absolution paths of both
tags files, something like: c:/tmp/t1/tags,c:/tmp/t2/tags and later
changing it to something like c:/tmp/t1/tags, but it continues to
show results from both tags files.
Using Vim with patch 7.0.096 it works just fine for me. I can only
explain the behavior when 'tags' is set to ./tags. The result of
taglist() is not cached.
I am using taglist() from lookupfile plugin and find that changing the
tags value for looking up files doesn't have an impact on the results.
While debugging I verified that the right value is getting set to 'tags'
setting, but still it returns results for the prior 'tags' value. I also
couldn't reproduce this in a standalone environment (like calling
taglist() from command-line), I apologize for wasting your time. I need
to spend some more time to isolate the problem.
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Unicode chars NEL, FF, LS, PS
On Sat, 2006-09-30 at 01:14 +0200, A.J.Mechelynck wrote: Steve Hall wrote: Does anyone here know if Vim respects the following Unicode characters (represents them rather than just indicating literals): http://en.wikipedia.org/wiki/Newline#Unicode I'm not on a Unicode platform at the moment, but I'm wondering if Vim could ever have the listchars to do it like mined: http://towo.net/mined/mined-uni.png Vim is a text editor, not a word processor. It does not necessarily show control characters as a word processor or a printer would. However you might alternatively say that these floodgates were opened when list was invented. :) Even on a non-Unicode platform, you should be able to run a +multibyte version of gvim, set 'encoding' to UTF-8 while preserving the locale setting of 'encoding' in 'termencoding', and enter the characters according to :help i_CTRL-V_digit to see what happens. Sometimes there's a font limitation, and I don't always trust what I see. NEL (Next Line, 0x85) is an upper-ASCII control character. I expect Vim to represent it as 85 when 'encoding' is set to UTF-8. This, however, depends on the setting of the 'isprint' option. I don't know what this control character means. FF (Form Feed, 0x0C) is an ASCII control character; it should be represented as ^L in Unicode just as in Latin1. When sent to a printer, it usually causes a page eject. LS (Line Separator, L SEP, U+2028) and PS (Paragraph Separator, P SEP, U+2029) are Format characters according to Unicode http://www.unicode.org/charts/PDF/U2000.pdf . They are followed in the charts by Left-to-Right Embedding, Right-to-Left Embedding, Pop Directional Formatting etc. I don't expect Vim to handle them otherwise than any other character, i.e., fetch a glyph, if any (probably none) from your 'guifont'. In my Gnome2 gvim with 'encoding' set to UTF-8, both U+2028 and U+2029 display as single-width spaces. It would be a lot to ask of any text editor to respect these new Unicode formatting characters. But I do think the authors of the spec intended these to be additions to the traditional CR and LF. I've been involved in a why can't Vim do X, editor Y can do it discussion, so my interest here is not actually using these chars myself. But there are likely some cases where they will be useful, more and more as software adopts Unicode. I'd personally only care that listchars has an option for them, on screen they act the same as any other line ending or tab char. -- Steve Hall [ digitect dancingpaper com ]
Re: Unicode chars NEL, FF, LS, PS
Steve Hall wrote: [...] It would be a lot to ask of any text editor to respect these new Unicode formatting characters. But I do think the authors of the spec intended these to be additions to the traditional CR and LF. I've been involved in a why can't Vim do X, editor Y can do it discussion, so my interest here is not actually using these chars myself. But there are likely some cases where they will be useful, more and more as software adopts Unicode. I'd personally only care that listchars has an option for them, on screen they act the same as any other line ending or tab char. Well, they don't. The only recognised line ending in Vim is the OS-specific one: CR on the Mac, LF under Unix, CR+LF on Windows. IIUC, in Unicode the use of embedded format characters is deprecated in favour of markup, e.g. in HTML span dir=rtl.../span rather than LRE ... PDF, P.../P rather than P-SEP, etc. Best regards, Tony.
Re: The meaning of nothing... ?
From: A.J.Mechelynck [EMAIL PROTECTED] Subject: Re: The meaning of nothing... ? Date: Fri, 29 Sep 2006 22:58:28 +0200 Yakov Lerner wrote: On 9/29/06, Meino Christian Cramer [EMAIL PROTECTED] wrote: Hi, to get all the keys of my keyboard working with vim I looked through my ~/.vimrc and found a setting (nottybuiltin), which I do revert and now a few addtional keys (C-F1 for example) do work correctly. So it seems, that the xterm256 definition, which I use, isn't completly defined in my terminfo database. Can I dump (or whatever the correct nameing is) the xterm256 settings vim is using internally in a form which I can use to correct my (buggy?) terminfo database ? The closest form to what you ask is ':set terminfo '. It does not dump terminal defs in terminfo format, no, but it does show it in some format. Yakov E518: Unknown option: terminfo I suppose you mean :set termcap. Best regards, Tony. Hi Tony, hi Yakov! I looked throught the term/terminfo/termcap/xterm/rxvt/* stuff and have more questions than answers now. Do you know a document or HowTo or something linke that which will give me more closer informations about the term* handling in linux and/or its terminal emulations ? For example: Is it generally impossible to switch the cusor's _shape_ (not only its color!) from bar to block and back inside the console version (gvim started as vim but with --enable-gui compile) of vim with t_SI/t_EI ??? Thank you very much for you help in advance! mcc
Re: The meaning of nothing... ?
Meino Christian Cramer wrote: [...] Hi Tony, hi Yakov! I looked throught the term/terminfo/termcap/xterm/rxvt/* stuff and have more questions than answers now. Do you know a document or HowTo or something linke that which will give me more closer informations about the term* handling in linux and/or its terminal emulations ? For example: Is it generally impossible to switch the cusor's _shape_ (not only its color!) from bar to block and back inside the console version (gvim started as vim but with --enable-gui compile) of vim with t_SI/t_EI ??? Thank you very much for you help in advance! mcc t_SI and t_EI are nonstandard codes added by Vim; IIUC they both default to empty. In the Windows console, the height (but not the width) of the cursor can be set with the 'guicursor' option; in Linux I don't know whether it is possible to change the cursor shape in the console, or how to do it. It will probably vary from terminal to terminal. My Gnome2 gvim, when started as vim, always displays a block cursor in konsole, an underbar cursor in /dev/tty. Best regards, Tony.
taglist
Thanks, Yegappan Lakshmanan Finally taglist worked. I reinstalled it from ports with version 5.6 Then in .vimrc, I put let Tlist_Ctags_Cmd='/usr/local/bin/exctags' THanks taglist plugin problem in freebsd 6.1 From: Vu The Cuong cuongvt at fsoft.com.vn Subject: taglist plugin problem in freebsd 6.1 Newsgroups: gmane.editors.vim Date: 2006-09-28 09:35:54 GMT I'm using vim 7 with taglist and ctags on freebsd 6.1 I opened php file on gvim, typed :Tlist but it raised an error: Taglist: Failed to generate tags for /usr/local/web/test.php The system cannot find the path specified. in .vimrc, I already put: let Tlist_Ctags_Cmd='/usr/bin/ctags' but the above error still displayed. Could anyone tell me how to solve this problem? Thanks in advanced Permalink | Reply | headers Yegappan Lakshmanan | 28 Sep 16:13 Picon Re: taglist plugin problem in freebsd 6.1 From: Yegappan Lakshmanan yegappanl at gmail.com Subject: Re: taglist plugin problem in freebsd 6.1 Newsgroups: gmane.editors.vim Date: 2006-09-28 14:13:20 GMT Hello, On 9/28/06, Vu The Cuong cuongvt at fsoft.com.vn wrote: I'm using vim 7 with taglist and ctags on freebsd 6.1 I opened php file on gvim, typed :Tlist but it raised an error: Taglist: Failed to generate tags for /usr/local/web/test.php The system cannot find the path specified. in .vimrc, I already put: let Tlist_Ctags_Cmd='/usr/bin/ctags' but the above error still displayed. Could anyone tell me how to solve this problem? What is the output of the following command from the shell? $ /usr/bin/ctags --version You can try the steps mentioned in the taglist FAQ: http://www.geocities.com/yegappan/taglist/faq.html - Yegappan
RE: Using vimserver with multiple clearcase views
Hello Yakov,
On 9/29/2006 11:33:42 PM Yakov Lerner wrote:
When you define new clearcase view, it starts new subshell and only
process which are children of this subshell see the files belonging to
the view, thanks to the clearcase kernel magic.
I knew that already. But was hoping that there would be some way of
working around it.
It follows that server will not see files from this view.
(At least, definitely not under same filenames as client vim would
see.)
If what you want is you use is to edit *many* files from *one* view in
one server-gvim, then the solution is to [re]start this gvim under
the view shell.
I knew how I used to work around it when I used Emacs. I would start a
Emacs server out of any view. Then I would start the emacs client using
emacsclient ${CLEARCASE_ROOT}/${PWD}/filename
This would always open up the file from the right view, since the
complete path was specificed. And I was hoping that the same would work
in vim as well. Looks like it won't.
But If you want to access files from two different view in one gvim,
then ask your clearcase admin how to access /view/user.view
pathnames; ask your clearcase admin how to access 2 views without
starting subshell. I think the answer for accessing /view filsystem
lies in the domain of the clearcase admin.
You'll need how to find out how to access clearcase view without
starting a subshell.
I think I will stick to the solution of starting multiple gvim windows.
However I would have really loved to share the registers/clipboard etc.
Thanks for the help Anyway.
Regards,
Vikas
Yakov
Re: vim + cscope + nuweb
[EMAIL PROTECTED] wrote: Jim Washburn [EMAIL PROTECTED] 写于 2006-09-30 02:58:59: Hi, A question about this combination - I use cscope with vim, normally with C/C++. I have lately been using the literate programming tool 'nuweb' , somewhat similar to CWEB, based on Latex. The nuweb source files I have written have C/C++ code within them. I have a problem referencing cscope tags within vim in this case. It does not seem to know that underscores can be part of the symbol it is looking up. So it looks up a truncated version of the symbol. Using cscope with nuweb outside of vim works fine. So my question is, how can I tell vim that underscores are a valid character in this context? Thanks, Jim :verbose set isk? gives iskeyword=@,48-57,192-255 I guess that :set isk+=_ will work. Yes it does! Thanks all, this is great. -Jim HTH -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: no winclose event
On Wed, 27 Sep 2006 at 10:07am, Charles E Campbell Jr wrote:
Bram Moolenaar wrote:
Charles Campbell wrote:
Just a suggestion -- I'd appreciate a WinClose event. BufWinLeave would
almost do, but if two or more windows are open on the same buffer, then
no event. WinLeave fires whenever one changes windows, which isn't
what I want, either. Unless I'm misunderstanding the help for these two
events.
What would this event be used for?
The WinResized event has also been suggested. It could be used to
update the Window layout. It will also be triggered when a window is
closed, since another window will get bigger then. Would it be
sufficient to only have a WinResized event? Would these events also be
triggered when closing the last window of a tab page?
As an example: I have debugging output in a left hand window (Decho.vim
produces this sort of output);
when I hit f9 on a function name, a vertically split window shows up
on the right and tags to the
named function. However, if that window already exists, I just want to
re-use it, not split and create another
one. To do that correctly, I need that window, when it is actually
closed, to perform some cleanup (ie. make a change
in a script variable). I want to allow other vertical windows, so there
isn't necessarily a fixed number of vertically
split panes. Actually, the script also allows s-f9 to create a left
hand source window: [leftsource|debugging|rightsource].
The leftsource and right source windows may well be open to the same
source file. Consequently the various buffer
closing events aren't adequate. BufWinLeave almost does the trick, but
there's that not when a buffer is still visible
in another window caveat associated with it. That's what I've been
using, but it really isn't adequate.
A WinResized might easily occur when that window wasn't closed, too.
Regards,
Chip Campbell
FYI, the last I needed this event, I wrote a function to do this. It is
part of genutils.vim as NotifyWinClose(). Here is the implementation
(written as a generalization), it is kind of heuristic (see
CheckWindowClose). I will be happy to see a WinClose event though.
let s:notifyWindow = {}
function! genutils#AddNotifyWindowClose(windowTitle, functionName)
let bufName = a:windowTitle
let s:notifyWindow[bufName] = a:functionName
let g:notifyWindow = s:notifyWindow Debug.
Start listening to events.
aug NotifyWindowClose
au!
au WinEnter * :call genutils#CheckWindowClose()
au BufEnter * :call genutils#CheckWindowClose()
aug END
endfunction
function! genutils#RemoveNotifyWindowClose(windowTitle)
let bufName = a:windowTitle
if has_key(s:notifyWindow, bufName)
call remove(s:notifyWindow, bufName)
if len(s:notifyWindow) == 0
unlet g:notifyWindow Debug.
aug NotifyWindowClose
au!
aug END
endif
endif
endfunction
function! genutils#CheckWindowClose()
if !exists('s:notifyWindow')
return
endif
Now iterate over all the registered window titles and see which one's are
closed.
for nextWin in keys(s:notifyWindow)
if bufwinnr(s:FindBufferForName(nextWin)) == -1
let funcName = s:notifyWindow[nextWin]
Remove this entry as these are going to be processed. The caller can
add
them back if needed.
unlet s:notifyWindow[nextWin]
call input(cmd: . cmd)
call call(funcName, [nextWin])
endif
endfor
endfunction
Here is a test case that shows how to use it:
function! NotifyWindowCloseF(title)
call input(a:title . closed)
endfunction
function! RunNotifyWindowCloseTest()
call input(Creating three windows, 'ABC', 'XYZ' and 'b':)
split ABC
split X Y Z
split b
redraw
call genutils#AddNotifyWindowClose(ABC, NotifyWindowCloseF)
call genutils#AddNotifyWindowClose(X Y Z, NotifyWindowCloseF)
call input(notifyWindow: . string(s:notifyWindow))
au NotifyWindowClose WinEnter
call input(Added notifications for 'ABC' and 'XYZ'\n.
\ Now closing the windows, you should see ONLY two notifications:)
quit
quit
quit
endfunction
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: About Unicode CJK Unified Extension B
Christian MICHON wrote: On 3/6/06, Bram Moolenaar [EMAIL PROTECTED] wrote: GTK2 does everything with UTF-8, thus it should work as it is. I know this is a bit late, but I tried today to make a custom gtk2 gvim build without multibyte, and I apparently cannot unless I change heavily the code around the utf8 stuff... The problem I face is that all my previous builds were gtk-1.2.10 without multibyte, and when I do cut and paste from gvim 7 to one of those gtk1 build, I get nasty [EMAIL PROTECTED]@ chains embedded in whatever I copy. Is there a fix or this is the expected gtk2 behaviour ? GTK2 gvim does all its I/O in UTF-8. Therefore, IIUC, you cannot have both +gui_gtk2 and -multibyte. You might try setting 'encoding' to latin1 in the GTK2 build to see if it makes a difference. Of course, there's no way you can paste codepoints U+00FF into an 8-bit build of Vim, except as multi-byte gibberish. The long-term fix, of course, is to stop using those earlier -multibyte builds. 8-bit _files_ should be compatible between + and - multibyte builds anyway. Best regards, Tony.
Re: 'at' tag selection and xxx/ tags
Eric Van Dewoestine wrote: Is there a particular reason why xxx/ tags are skipped when using at (:h at)? The tag-blocks documentation notes that this is by design but offers no reasoning behind it. For html where the only self closing tags are usually p/ or br/, I could see how this behavior might be justified. However given a larger xml tag: sometag attr1=one attr2=two attr3=three attr4=four/ It would be very helpful if at could be used for selection. Thoughts? at and it skip not only xxx/ self-closing tags, they also skip p and li when they don't have a corresponding /p or /li (p/ is invalid in HTML), meta ... and br even when they aren't ended by /, etc. The idea is that at a tag block needs means to define where a block begins and ends, i.e., a begin tag and an end tag. A self-closing tag has by definition no block of text, no content that it could select. With the cursor within a self-closing tag such as, let's say, meta http-equiv=Content-Type content=text/html; charset=utf-8 /, which is typical for HTML and not trivially short, you could select the tag itself with a Outside the span of any tag, you can find the next tag with / The only problem is having at select e.g. from within an HTML paragraph, leftwards to and including the p tag, and rightwards to where a /p tag ought to be but is missing, e.g. just before the p tag for the next paragraph, or just before a closing tag for an enclosing block-level tag such as /div. Such missing closing tags are allowed in HTML but not in XHTML; but having at and it work like that would require a detailed knowledge of HTML syntax, and I think it is too complex a task for a simple command like it or at . IMHO it is the trend of the future, and therefore good form to include /p at the end of paragraphs, /li at the end of bulleted or numbered list items, /td at the end of table cells, etc., and / at the end of unpaired tags. Doing so also solves the problem mentioned in the above paragraph. Best regards, Tony.
