Re: vim + cscope + nuweb

2006-09-29 Thread Jim Washburn


[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: Using vimserver with multiple clearcase views

2006-09-29 Thread Mishra, Vikas
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}/

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



taglist

2006-09-29 Thread Vu The Cuong
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  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  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  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: The meaning of nothing... ?

2006-09-29 Thread A.J.Mechelynck

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.


Re: The meaning of nothing... ?

2006-09-29 Thread Meino Christian Cramer
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 ( 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: Unicode chars NEL, FF, LS, PS

2006-09-29 Thread A.J.Mechelynck

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 
... rather than LRE ... PDF, ... rather than 
P-SEP, etc.



Best regards,
Tony.


vim@vim.org

2006-09-29 Thread A.J.Mechelynck

Steve Hall wrote:

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".




Well, 'listchars' eol: extends: precedes: and even the second character in 
tab: are not "text in my file" either. I can imagine someone willing to use 
'linebreak' only if he can show these virtual spaces as blue dots or 
underscores to distinguish them from real "text in my file" spaces. After all, 
the whole purpose of 'list' and 'listchars' is to see exactly what is "text in 
my file" and what isn't, to the point of seeing how many spaces are at the end 
of a line, or whether some blank expanse is a hard tab or a string of spaces.



Best regards,
Tony.


Re: Unicode chars NEL, FF, LS, PS

2006-09-29 Thread Steve Hall
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: taglist() bugs related to 'tags'

2006-09-29 Thread Hari Krishna Dara

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 


vim@vim.org

2006-09-29 Thread Steve Hall
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: vim + cscope + nuweb

2006-09-29 Thread A.J.Mechelynck

Jim Washburn wrote:


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


What is your 'iskeyword' setting?

:verbose set isk?


Best regards,
Tony.


Re: Unicode chars NEL, FF, LS, PS

2006-09-29 Thread A.J.Mechelynck

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: Autmagically adding new lines when text gets too long

2006-09-29 Thread A.J.Mechelynck

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, 
gq to reformat the Visual area, gqap to regormat a paragraph, gggqG to 
reformat the whole file.



Best regards,
Tony.


vim@vim.org

2006-09-29 Thread A.J.Mechelynck

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: The meaning of nothing... ?

2006-09-29 Thread A.J.Mechelynck

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 ( 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.


vim@vim.org

2006-09-29 Thread Yakov Lerner

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: Move cursor in insert mode without breaking history?

2006-09-29 Thread Karl Guertin

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 ()=NoUndoMove(-1)
inoremap ) =JumpTo(')').NoUndoMove(1)

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.


vim@vim.org

2006-09-29 Thread Steve Hall
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. :)


-- 
Steve Hall  [ digitect dancingpaper com ]



vim@vim.org

2006-09-29 Thread Yakov Lerner

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


vim + cscope + nuweb

2006-09-29 Thread Jim Washburn


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








vim@vim.org

2006-09-29 Thread Steve Hall
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.


-- 
Steve Hall  [ digitect dancingpaper com ]



vim@vim.org

2006-09-29 Thread Yakov Lerner

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


Re: Using vimserver with multiple clearcase views

2006-09-29 Thread Yakov Lerner

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: Re: Re: Autmagically adding new lines when text gets too long

2006-09-29 Thread Jeremy Conlin

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 s 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: Re: Autmagically adding new lines when text gets too long

2006-09-29 Thread Georg Dahn
Hi!

--- Jeremy Conlin <[EMAIL PROTECTED]> wrote:
> No, linebreak just *displays* a broken line, I want a *real* broken
> line.  I want Vim to insert s 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: Autmagically adding new lines when text gets too long

2006-09-29 Thread Georg Dahn
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: Unicode chars NEL, FF, LS, PS

2006-09-29 Thread Pádraig Brady
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
> 
> 

On [g]vim-7.0.17 on ubuntu-5.10 those "newline" chars
are not treated specially.

For LS and PS is displays then as a single space.
For NEL it shows <85>
For FF it shows ^L

listchars doesn't support these either.

I notice gedit displays newlines for PS and LS.

Pádraig.


Autmagically adding new lines when text gets too long

2006-09-29 Thread Jeremy Conlin

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


Unicode chars NEL, FF, LS, PS

2006-09-29 Thread Steve Hall

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 ]



vim@vim.org

2006-09-29 Thread Steve Hall

: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 ]



Using vimserver with multiple clearcase views

2006-09-29 Thread Mishra, Vikas
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


Re: When I open foo.zcml I would like xml type syntax

2006-09-29 Thread KLEIN Stéphane

2006/9/29, Marc Weber <[EMAIL PROTECTED]>:

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


Thanks, it's working.


Re: Progressive quickfix buffer / background compilations

2006-09-29 Thread Marc Weber
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  :exec 'cope '.&lines/3

Concerning hitting-enter.. :silent!  might help

HTH a little bit.
Marc Weber


Re: When I open foo.zcml I would like xml type syntax

2006-09-29 Thread Marc Weber
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


When I open foo.zcml I would like xml type syntax

2006-09-29 Thread KLEIN Stéphane

Hi,

How can I configure vim to use XML syntax when I open *.zcml file ?

Thanks,
Stephane


Re: splitting $HOME/.vimrc

2006-09-29 Thread moonykily
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: The meaning of nothing... ?

2006-09-29 Thread Yakov Lerner

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 ( 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: Spell and Perl source highlighting

2006-09-29 Thread Bill Moseley
On Fri, Sep 29, 2006 at 10:02:04AM +1000, Peter Hodge wrote:
> > Finally, when spell check is enabled and syntax highlighting is also
> > enabled, there vim is highlighting some text in a way that the
> > foreground and background colors are the same -- so the text vanishes
> > from view.  Maybe the solution is to not have syntax and spell
> > highlighting enabled at the same time?


>   :highlight SpellBad ctermbg=Red ctermfg=Blue cterm=Underline

I ended up using ctermbg=None ctermfg=None cterm=Underline

That seem to not interfere as much with the Perl syntax highlighting.

Thanks for the tip.

-- 
Bill Moseley
[EMAIL PROTECTED]