Thanks David, an innovative solution.
I'm not quite sure what I'm doing wrong but the function isn't doing
anything for me though.
It prints out a decrementing status of how many lines are left to format,
so it seems to be working, but nothing gets formatted.
I suspected it was because I had tw=0 but setting it to 60 didn't help.

Any easy ideas?   Otherwise, the synmaxcol suggestion may well be
sufficient.

(I could send you debug output - scriptnames, or other things - but I
don't want to waste you time unless you're keen.)

Thanks very much anyway,
John


On Tue, 02 Dec 2008 06:44:33 +1100, David Fishburn
<dfishburn.vim@...> wrote:

>
> This is a simple work around that seems to keep things moving for me.
> I define the following in my vimrc.
>
> function! Format_SGML() range
>     " Add a new line to the bottom of the mark to be removed later
>     call cursor(a:lastline,1)
>     put =''
>     silent! exec "ma z"
>     " Add a new line above the mark to be removed later
>     call cursor(a:firstline,1)
>     put! = ''
>     silent! exec "ma y"
>
>     " Record current filetype
>     let save_ft = &filetype
>
>     if save_ft != 'xml'
>         " Change the filetype so we can format the selection
>         setlocal filetype=xml
>     endif
>
>     " Put each tag on a newline
>     exec line("'y").','.line("'z").'s/>\s*</>\r</ge'
>     " Reformat using Vim's indenter
>     call cursor(line("'y"),1)
>     exec 'normal! '.(line("'z")-line("'y")+1).'=='
>
>     if save_ft != 'xml'
>         " Restore the filetype
>         exec 'setlocal filetype='.save_ft
>     endif
>
>     " Delete the additional lines added
>     silent! exe "norm! 'ydd'zdd"
> endfunction
> command! -range=% -nargs=0 FormatSGML <line1>,<line2>call Format_SGML()
>
> Then each time I open the file I run:
> :FormatSGML
>
> It seems when the lines are shorter, the highlighting is quick.
>
> HTH,
> Dave
>
>
> On 12/1/08, Gene Kwiecinski <gkwiecinski@...> wrote:
>>
>>> was so slow.  Disabling syntax highlighting proved to solve the problem
>> -
>>> but I was wondering, has anyone else hit this problem, and perhaps
>> created
>>> a reduced functionality xml syntax highlighter - so I still get
>> something
>>> useful, but maybe not quite as complex?
>>
>> One person's opinion of what constitutes "stripped down" would likely
>> differ from someone else's opinion, which is the problem.  Eg, you might
>> be happy with just tagstoff being one color, and textstoff being a
>> different color.  Someone else might want attributes to be a 3rd color.
>> Someone else would make comments a different color.  Before you know it,
>> you'd have a "stripped down" syntax file that's maybe 80% of the
>> original, not saving much.
>>
>> <shrug/>
>>
>> >
>>
>
> >


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Mon, Dec 1, 2008 at 1:10 PM, smu johnson wrote:
> Dear faithful vim users,
>
> I was wondering how some of guy friendly folks have gone about toggling the
> fo / formatoptions flags.  I haven't been able to find anything in the man
> page because it lacks common applications for the advice it gives.
>
> I'm basically trying to bind a key to toggle the auto-comment ability found
> in it.  Any thoughts?  Thanks in advance.

I'd do something like this:

if &fo =~ 'r' && &fo =~ 'o'
  set fo-= fo-=r
else
  set fo+=ro
endif

That is, if 'formatoptions' contains both 'o' and 'r', remove those
flags, otherwise add those flags.

see...
:help expr-option
:help :set+=
:help :set-=

~Matt

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Thanks very much Erik, that seems to work very well and is probably a good
trade-off.

John

On Tue, 02 Dec 2008 06:45:55 +1100, Erik Falor <ewfalor@...> wrote:

>
> On Tue, Dec 02, 2008 at 05:44:03AM +1100, John Orr wrote:
>> has anyone else hit this problem, and perhaps created
>> a reduced functionality xml syntax highlighter - so I still get
>> something
>> useful, but maybe not quite as complex?
>>
>
> I personally run into this most frequently when editing an XML file
> with really long lines.
>
> I just adjust 'synmaxcol' to something like 128 and Vim speeds right
> back up.  The trade-off being that only the first 128 characters in a
> line are highlighted.
>
> Read
> :help 'synmaxcol'
> for more info.
>


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Matt Wozniski wrote:
> if &fo =~ 'r' && &fo =~ 'o'
>  set fo-= fo-=r
> else
>  set fo+=ro
> endif

Matt's solution is good, but I think he missed a "o" in his
transcription of the "-=" bits:

    set fo-=o fo-=r
            ^

The whole shebang should be mappable if needed.

-tim




--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

I may have worked out the problem, perhaps - and it's the xml files I'm
looking at.

The dtd/schema is poor - with lots of attributes which should be elements
- so each element gets very long, and perhaps Vim keeps it together??

Anyway - synmaxcol is working well.

Thanks,
John

On Tue, 02 Dec 2008 07:12:35 +1100, John Orr <johno@...>
wrote:

>
> Thanks David, an innovative solution.
> I'm not quite sure what I'm doing wrong but the function isn't doing
> anything for me though.
> It prints out a decrementing status of how many lines are left to format,
> so it seems to be working, but nothing gets formatted.
> I suspected it was because I had tw=0 but setting it to 60 didn't help.
>
> Any easy ideas?   Otherwise, the synmaxcol suggestion may well be
> sufficient.
>
> (I could send you debug output - scriptnames, or other things - but I
> don't want to waste you time unless you're keen.)
>
> Thanks very much anyway,
> John
>
>
> On Tue, 02 Dec 2008 06:44:33 +1100, David Fishburn
> <dfishburn.vim@...> wrote:
>
>>
>> This is a simple work around that seems to keep things moving for me.
>> I define the following in my vimrc.
>>
>> function! Format_SGML() range
>>     " Add a new line to the bottom of the mark to be removed later
>>     call cursor(a:lastline,1)
>>     put =''
>>     silent! exec "ma z"
>>     " Add a new line above the mark to be removed later
>>     call cursor(a:firstline,1)
>>     put! = ''
>>     silent! exec "ma y"
>>
>>     " Record current filetype
>>     let save_ft = &filetype
>>
>>     if save_ft != 'xml'
>>         " Change the filetype so we can format the selection
>>         setlocal filetype=xml
>>     endif
>>
>>     " Put each tag on a newline
>>     exec line("'y").','.line("'z").'s/>\s*</>\r</ge'
>>     " Reformat using Vim's indenter
>>     call cursor(line("'y"),1)
>>     exec 'normal! '.(line("'z")-line("'y")+1).'=='
>>
>>     if save_ft != 'xml'
>>         " Restore the filetype
>>         exec 'setlocal filetype='.save_ft
>>     endif
>>
>>     " Delete the additional lines added
>>     silent! exe "norm! 'ydd'zdd"
>> endfunction
>> command! -range=% -nargs=0 FormatSGML <line1>,<line2>call Format_SGML()
>>
>> Then each time I open the file I run:
>> :FormatSGML
>>
>> It seems when the lines are shorter, the highlighting is quick.
>>
>> HTH,
>> Dave
>>
>>
>> On 12/1/08, Gene Kwiecinski <gkwiecinski@...> wrote:
>>>
>>>> was so slow.  Disabling syntax highlighting proved to solve the
>>>> problem
>>> -
>>>> but I was wondering, has anyone else hit this problem, and perhaps
>>> created
>>>> a reduced functionality xml syntax highlighter - so I still get
>>> something
>>>> useful, but maybe not quite as complex?
>>>
>>> One person's opinion of what constitutes "stripped down" would likely
>>> differ from someone else's opinion, which is the problem.  Eg, you
>>> might
>>> be happy with just tagstoff being one color, and textstoff being a
>>> different color.  Someone else might want attributes to be a 3rd color.
>>> Someone else would make comments a different color.  Before you know
>>> it,
>>> you'd have a "stripped down" syntax file that's maybe 80% of the
>>> original, not saving much.
>>>
>>> <shrug/>
>>>
>>> >
>>>
>>
>> >
>
>
> >



--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Mon, Dec 1, 2008 at 3:19 PM, Tim Chase wrote:
> Matt's solution is good, but I think he missed a "o" in his
> transcription of the "-=" bits:
>
>   set fo-=o fo-=r
>           ^

Good catch, it was a typo.  :)

Thanks Tim.

~Matt

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

anhnmncb wrote:
> On 2008-11-30, anhnmncb wrote:
>
>> As title, I want to make a function for foldtext like this:
>>
>> function MY_TeX_BiBFoldText()
>>   let line = getline(v:foldstart, v:foldend)
>>   let matchlinea = match(line, '^\s*author.*{.*}.*') + 1
>>   let matchlinet = match(line, '^\s*title.*{.*}.*') + 1
>>   let matcha = substitute(getline(matchlinea), '^.*{\(.*\)}*.*$', '\1', 'g')
>>   let matcht = substitute(getline(matchlinet), '^.*{\(.*\)}*.*$', '\1', 'g')
>>   let matched = "title: " . matcht . "   author: " . matcha
>>   return v:folddashes . matched
>> endfunction
>>
>> So the folding will show the string "matched", but I find that v:foldstart
and
>> v:foldend have the same value in foldings, so all my foldings show the same
>> string, why?
>>
>>
> Isn't my description clear? If so, let me know please.
>
>
Hello!

I've not messed with the foldtext option before; I suspect its one of
the less common things people do, so your target audience is small.
Also, I've moved recently to a new email delivery mechanism (even though
my email address itself hasn't changed), and its flagging your email as
spam:


Content analysis details:   (5.9 points, 3.5 required)

  pts rule name              description
---- ---------------------- --------------------------------------------------
  0.1 RDNS_NONE              Delivered to trusted network by a host with no rDNS
  3.2 FROM_LOCAL_NOVOWEL     From: localpart has series of non-vowel letters
  2.6 RCVD_NUMERIC_HELO      Received: contains an IP address used for HELO

The biggest item on the above list is your false "name".  Rather discourages one
from looking at your email, you know.

Now, on to your problem -- I instrumented your function with Decho.vim calls
(Dfunc, Decho, Dret).  Since the foldtext option says its a no-no to change
windows, I used DechoMsgOn which sends Decho output via echomsg.

You can get the Decho plugin from:

	 http://vim.sourceforge.net/scripts/script.php?script_id=120
-or-
	 http://mysite.verizon.net/astronaut/vim/index.html#DECHO
	 (this latter one is always the most up-to-date)

Here's the modified function/script:

DechoMsgOn
function! MY_TeX_BiBFoldText()
    call Dfunc("My_TeX_BiBFoldText() v:fold[".v:foldstart.",".v:foldend."]")
    let line       = getline(v:foldstart, v:foldend)
    let matchlinea = match(line, '^\s*author.*{.*}.*') + 1
    let matchlinet = match(line, '^\s*title.*{.*}.*') + 1
    call Decho("matchlinea=".matchlinea." matchlinet=".matchlinet)
    let matcha     = substitute(getline(matchlinea), '^.*{\(.*\)}*.*$', '\1',
'g')
    let matcht     = substitute(getline(matchlinet), '^.*{\(.*\)}*.*$', '\1',
'g')
    let matched    = "title: " . matcht . "   author: " . matcha
    call Dret("My_TeX_BiBFoldText ".v:folddashes . matched)
    return v:folddashes . matched
endfunction
set foldtext=MY_TeX_BiBFoldText()

With it, you'll see that v:foldstart and v:foldend do differ when
MY_TeX_BiBFoldText() is called for each fold.  An example of one of the calls
(gotten by typing :mess):

My_TeX_BiBFoldText() v:fold[30,35] {
|matchlinea=0 matchlinet=0
|return My_TeX_BiBFoldText -title:    author:  }

The problem here is that your two match() calls which look for author and title
don't match.  None of my bib entries that I used for this test have {}s for
author=... or title=... , so that's the proximate cause for me.  You'd need to
share some of your bib files for a better test, or better: get Decho.vim and try
debugging this one yourself.

Regards,
Chip Campbell




--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

This is something that partly is provided by vim by folding. But I don't want the folding texts...

What I want is to watch a file in two views where the second one is a filtered view of the first one.

Can anyone please help me. I'm not a very advanced user

Q. I would like to have a dual view of my file with many thousand lines.

A. I could do this with a vertical split.

Q. Then I would like to two windows to be synchronized.

A. I could do this with the :scrollbind command

So far everything is good... But then:

Q. I want to filter the view to only show text matching my regex

A. There's a VIM-tip's for that:

:set fold

:set foldexpr=getline(v:lnum)!~@/
:nnoremap <F8> :set foldmethod=expr<CR><Bar>zM

The problem is that I cant get rid of the text: "+--27 lines: xxx-----------------"

I would like a list of all lines containing my regex and nothing else. The output I would like is similar to the output generated by this command:

:g!/MyRegEx/d

but I don't want to delete the text since I want to edit the complete file (but in a filtered view)

The second problem I get is that I want to :scrollbind to completely sync the lines between the current cursor line in my filtered window with the line i my unfiltered windows so that I could see the surrounding text

Example:

Windows 1 (original)
========   
1 Line 1   
2 Line 2   
3 Line 3 foo
4 Line 4   
5 Line 5   
6 Line 6 foo
7 Line 7

Windows 2 (filtered on /foo/)
========
3 Line 3 foo
6 Line 6 foo

worker wrote:
>     I can't get to automatically do the syntax highlighting
> for vb script. It can do all other program file types, just
> not vb script.
> I've already put syntax enable and syntax on in the vimrc
> file and it works for all other filetypes except vb.

Following is how you could associate two file extensions with two different
filetypes, in file $HOME/vimfiles/filetype.vim:

---start---
if exists("did_load_filetypes")
   finish
endif
augroup filetypedetect
   au! BufNewFile,BufRead *.cls setf vb
   au! BufNewFile,BufRead *.csv setf csv
augroup END
---end---

You should be able to adapt this (removing the csv line) for your purpose.

John


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Sun, Nov 30, 2008 at 3:52 AM, anhnmncb wrote:
>
> As title, I want to make a function for foldtext like this:

Looks to me like your function is confused...

> function MY_TeX_BiBFoldText()

You get a List containing the text of all lines in the fold:

>  let line = getline(v:foldstart, v:foldend)

Then you find the offsets in that list of the matching lines:

>  let matchlinea = match(line, '^\s*author.*{.*}.*') + 1
>  let matchlinet = match(line, '^\s*title.*{.*}.*') + 1

Then you use those offsets as line numbers, instead of offsets into a
list.  Why are you using getline(match()+1) here, instead of
line[match()] ?

>  let matcha = substitute(getline(matchlinea), '^.*{\(.*\)}*.*$', '\1', 'g')
>  let matcht = substitute(getline(matchlinet), '^.*{\(.*\)}*.*$', '\1', 'g')

Seems to me that those lines should be:

let matchlinea = match(line, '^\s*author.*{.*}.*')
let matchlinet = match(line, '^\s*title.*{.*}.*')
let matcha = substitute(line[matchlinea], '^.*{\(.*\)}*.*$', '\1', 'g')
let matcht = substitute(line[matchlinet], '^.*{\(.*\)}*.*$', '\1', 'g')

>  let matched = "title: " . matcht . "   author: " . matcha
>  return v:folddashes . matched
> endfunction

Try that, see if it helps.

~Matt

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Dec 1, 5:18 pm, Tony Mechelynck <antoine.mechely...@...>
wrote:
> On 01/12/08 15:34, Timothy Madden wrote:
[...]
> > Could someone create a :command that would check the current selection or
> > the next 36 chararcters after the cursor to be hexadecimal digits
> > including minus
> > sign (anywhere in between) and then replace this text with the output
> > from a command
> > line executable (bin/GUIDGEN.exe) ?
>
> > Is there a script for this already ?
>
> > I do not know vim language, I am still learning the commands
[...]
> Easy
>
>         :s/\%#[-[:xdigit:]]\{36}/\=`GUIDGEN`
>
> Explanation:
>
>         :s      substitute on current line
>         /       replace what?
>         \%#     zero-width, current cursor position
>         [       start collection
>         -       dash
>         [:xdigit:]      (inside collection) hex digit
>         ]       end collection
>         \{36}   repeat 36 times (i.e., multiply previous atom by 36)
>         /       replace by what?
>         \=      expression
>         `GUIDGEN`       the stdout of program GUIDGEN which is the PATH
>         (no flags)      do it just once


My vim says Invalid expression `wine GUIDGEN.exe` after I
type :Guidgen,
which I defined like this in ~/.vimrc:

command Guidgen :s$\%#[-[:xdigit:]]\{36}$\=`wine GUIDGEN.exe`

I have vim7.2 on Slackware.

I used $ instead of / in the search command because the path to
GUIDGEN
might someday contain a literal /.

I would also like to skip the first line of output
(reading Z:\home\adrian\GUIDGEN.exe) and then ignore the braces
around
the generated GUID, if possible

Thank you,
Timothy Madden

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

> If you want to changes this, remove these lines from gitcommit.vim (my version
> is from 2008 Apr 09).
>
>     hi def link gitcommitSummary                Keyword
>     hi def link gitcommitBlank          Error

Great, thank you. Btw, since when second line in git should be empty?
I thought long description starts on the second line, actually. And,
btw, the red color there - it's not the second line. It's the same
first line, vim just automatically moved it to the next line, but
there's no \n symbols there.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Please offer an opinion on two dodgy tips that deal with Ruby:
  http://vim.wikia.com/wiki/Beautify_Ruby_code
  http://vim.wikia.com/wiki/Highlighting_source_between_matching_curly_braces

The beautify tip has a long Ruby script that is out of date. A Google search for
"beautify ruby" finds the current version of the script, at the site mentioned
in
the tip (so we do not need the script in the tip?). The tip also has an eloquent
"dodgy" statement asking why the Ruby plugins distributed with Vim are not
adequate.

The braces tip has some comments again complaining about the inexplicable nature
of
the tip. Note the link to duplicate tip 6 which covers Vim's handling of braces.

I see zero prospect of tips like these ever being cleaned up, and am inclined
towards deleting them (that is, flag as candidate for deletion, then wait a
month or
more for discussion).

Can anyone familiar with Ruby comment on whether either of these tips has some
merit. Any comments?

John


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Mon, Dec 1, 2008 at 6:48 PM, snitko wrote:
>
> Great, thank you. Btw, since when second line in git should be empty?

See man git-commit

DISCUSSION
        Though not required, it´s a good idea to begin the commit message with
        a single short (less than 50 character) line summarizing the change,
        followed by a blank line and then a more thorough description.

Also, check out the gitcommit.vim author's blog post about the
rationale for this syntax file:

http://www.tpope.net/node/106

> I thought long description starts on the second line, actually. And,
> btw, the red color there - it's not the second line. It's the same
> first line, vim just automatically moved it to the next line, but
> there's no \n symbols there.

No, if it's highlighted in red, there must be a newline there.  Vim
probably added it for you, thanks to 'textwidth' and 'formatoptions' -
the textwidth used for gitcommit is 72, which so vim would have
automatically wrapped that line - the last 'e' in "white" would be the
71st character on the line.

~Matt

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Charles Campbell (2008-12-01 15:43 -0500) wrote:

> anhnmncb wrote:
>> On 2008-11-30, anhnmncb wrote:
>>
>>> As title, I want to make a function for foldtext like this:
>>>
>>> function MY_TeX_BiBFoldText()
>>>   let line = getline(v:foldstart, v:foldend)
>>>   let matchlinea = match(line, '^\s*author.*{.*}.*') + 1
>>>   let matchlinet = match(line, '^\s*title.*{.*}.*') + 1
>>>   let matcha = substitute(getline(matchlinea), '^.*{\(.*\)}*.*$', '\1', 'g')
>>>   let matcht = substitute(getline(matchlinet), '^.*{\(.*\)}*.*$', '\1', 'g')
>>>   let matched = "title: " . matcht . "   author: " . matcha
>>>   return v:folddashes . matched
>>> endfunction
>>>
>>> So the folding will show the string "matched", but I find that v:foldstart
and
>>> v:foldend have the same value in foldings, so all my foldings show the same
>>> string, why?
>>>
>>>
>> Isn't my description clear? If so, let me know please.
>>
>>
> Hello!
>
> I've not messed with the foldtext option before; I suspect its one of
> the less common things people do, so your target audience is small.
> Also, I've moved recently to a new email delivery mechanism (even though
> my email address itself hasn't changed), and its flagging your email as
> spam:
>
>
> Content analysis details:   (5.9 points, 3.5 required)
>
>  pts rule name              description
> ---- ---------------------- --------------------------------------------------
>  0.1 RDNS_NONE              Delivered to trusted network by a host with no
rDNS
>  3.2 FROM_LOCAL_NOVOWEL     From: localpart has series of non-vowel letters
>  2.6 RCVD_NUMERIC_HELO      Received: contains an IP address used for HELO
>
> The biggest item on the above list is your false "name".  Rather discourages
one from looking at your email, you know.
>
> Now, on to your problem -- I instrumented your function with Decho.vim calls
(Dfunc, Decho, Dret).  Since the foldtext option says its a no-no to change
windows, I used DechoMsgOn which sends Decho output via echomsg.
>
> You can get the Decho plugin from:
>
>  http://vim.sourceforge.net/scripts/script.php?script_id=120
> -or-
>  http://mysite.verizon.net/astronaut/vim/index.html#DECHO
>  (this latter one is always the most up-to-date)
>
> Here's the modified function/script:
>
> DechoMsgOn
> function! MY_TeX_BiBFoldText()
>    call Dfunc("My_TeX_BiBFoldText() v:fold[".v:foldstart.",".v:foldend."]")
>    let line       = getline(v:foldstart, v:foldend)
>    let matchlinea = match(line, '^\s*author.*{.*}.*') + 1
>    let matchlinet = match(line, '^\s*title.*{.*}.*') + 1
>    call Decho("matchlinea=".matchlinea." matchlinet=".matchlinet)
>    let matcha     = substitute(getline(matchlinea), '^.*{\(.*\)}*.*$', '\1',
'g')
>    let matcht     = substitute(getline(matchlinet), '^.*{\(.*\)}*.*$', '\1',
'g')
>    let matched    = "title: " . matcht . "   author: " . matcha
>    call Dret("My_TeX_BiBFoldText ".v:folddashes . matched)
>    return v:folddashes . matched
> endfunction
> set foldtext=MY_TeX_BiBFoldText()
>
> With it, you'll see that v:foldstart and v:foldend do differ when
MY_TeX_BiBFoldText() is called for each fold.  An example of one of the calls
(gotten by typing :mess):
>
> My_TeX_BiBFoldText() v:fold[30,35] {
> |matchlinea=0 matchlinet=0
> |return My_TeX_BiBFoldText -title:    author:  }
>
> The problem here is that your two match() calls which look for author and
title don't match.  None of my bib entries that I used for this test have {}s
for author=... or title=... , so that's the proximate cause for me.  You'd need
to share some of your bib files for a better test, or better: get Decho.vim and
try debugging this one yourself.

I use following lines for bib filetype:

   set fdm=syntax
   set foldtext=MY_TeX_BiBFoldText()
   syntax region bibentry start=/^\s*@.*$/ end=/^\s\?}.*\n\s*$/ contained
contains=ALL fold

and the bib example is following:

@ARTICLE{foo1,
     author = {author1},
     title = {This is a long
         title.),
     journal = {journal1},
     year = 1980,
     volume = 18,
     pages = {55--67},
     TypeofLit = {J}
}

@ARTICLE{foo2,
     author = {author2 and author 3},
     title = {title 2},
     journal = {Throbosis Res},
     year = 1982,
     volume = 13,
     pages = {58--67},
     TypeofLit = {J}
}


>
> Regards,
> Chip Campbell
>
>
>
>
>

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Matt Wozniski (2008-12-01 17:10 -0500) wrote:

> On Sun, Nov 30, 2008 at 3:52 AM, anhnmncb wrote:
>>
>> As title, I want to make a function for foldtext like this:
>
> Looks to me like your function is confused...
>
>> function MY_TeX_BiBFoldText()
>
> You get a List containing the text of all lines in the fold:
>
>>  let line = getline(v:foldstart, v:foldend)
>
> Then you find the offsets in that list of the matching lines:
>
>>  let matchlinea = match(line, '^\s*author.*{.*}.*') + 1
>>  let matchlinet = match(line, '^\s*title.*{.*}.*') + 1
>
> Then you use those offsets as line numbers, instead of offsets into a
> list.  Why are you using getline(match()+1) here, instead of
> line[match()] ?
>
>>  let matcha = substitute(getline(matchlinea), '^.*{\(.*\)}*.*$', '\1', 'g')
>>  let matcht = substitute(getline(matchlinet), '^.*{\(.*\)}*.*$', '\1', 'g')
>
> Seems to me that those lines should be:
>
> let matchlinea = match(line, '^\s*author.*{.*}.*')
> let matchlinet = match(line, '^\s*title.*{.*}.*')
> let matcha = substitute(line[matchlinea], '^.*{\(.*\)}*.*$', '\1', 'g')
> let matcht = substitute(line[matchlinet], '^.*{\(.*\)}*.*$', '\1', 'g')
>
>>  let matched = "title: " . matcht . "   author: " . matcha
>>  return v:folddashes . matched
>> endfunction
>
> Try that, see if it helps.

Hello, your version works! thanks :) I should use line[], not getline().

>
> ~Matt
>
>

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On 2008-12-02, anhnmncb wrote:
>
>
> I use following lines for bib filetype:
>
>   set fdm=syntax
>   set foldtext=MY_TeX_BiBFoldText()
>   syntax region bibentry start=/^\s*@.*$/ end=/^\s\?}.*\n\s*$/ contained
contains=ALL fold

From my function and other stuff, you know I'm not a programmer, and not get
familiar with vimscript and regex, anyone can give me an improve version for
my syntax for bib? My version just can fold the bib entry like this:
@article{foo,
     author = {author},
     title = {title},
}

it doesn't support this one:
@article{foo,
     author = {author},
     title = {title},}

And my foldtext can support just one line of title, the splited long line will
not
be regornized, so if title = {a long \n line title}, then the function just
returns "a long", not with the following line.

I know maybe there is already some plugins like latexsuit can do that, but I
don't get along well with them.

Any helpful info will be appreciated.

--
Regards,
anhnmncb


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi,

I am running gvim to display/edit Simplified Chinese text when locale
was set to zh_CN.gbk.  There are many space between Chinese
characters, this looks so urgly.  But this does not happened for other
font-config program such as Xemacs and firefox.  Does anyone know
where can I find help for this issue?

Thanks in advance.

-
narke

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

I am thinking about modifying the jptemplate plugin.  For the plugin
developers,  How do you keep your development plugin seperate from
your normal vim configuration?

Thank you for your time.
Michael

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

This is an idea, so I do not know how well it will work.  Have you try
to use syntax highlighting?  Make the text you do not want the same
color as the background.

On Mon, Dec 1, 2008 at 3:48 PM, Pär Adeen <par_adeen@...> wrote:
> This is something that partly is provided by vim by folding. But I don't
> want the folding texts...
>
> What I want is to watch a file in two views where the second one is a
> filtered view of the first one.
>
> Can anyone please help me. I'm not a very advanced user
>
>
>
> Q. I would like to have a dual view of my file with many thousand lines.
>
> A. I could do this with a vertical split.
>
>
>
> Q. Then I would like to two windows to be synchronized.
>
> A. I could do this with the :scrollbind command
>
>
>
> So far everything is good... But then:
>
>
>
> Q. I want to filter the view to only show text matching my regex
>
> A. There's a VIM-tip's for that:
>
> :set fold
>
> :set foldexpr=getline(v:lnum)!~@/
> :nnoremap <F8> :set foldmethod=expr<CR><Bar>zM
>
>
>
> The problem is that I cant get rid of the text: "+--27 lines:
> xxx-----------------"
>
> I would like a list of all lines containing my regex and nothing else. The
> output I would like is similar to the output generated by this command:
>
> :g!/MyRegEx/d
>
> but I don't want to delete the text since I want to edit the complete file
> (but in a filtered view)
>
>
>
> The second problem I get is that I want to :scrollbind to completely sync
> the lines between the current cursor line in my filtered window with the
> line i my unfiltered windows so that I could see the surrounding text
>
>
>
> Example:
>
>
>
> Windows 1 (original)
> ========
> 1 Line 1
> 2 Line 2
> 3 Line 3 foo
> 4 Line 4
> 5 Line 5
> 6 Line 6 foo
> 7 Line 7
>
>
>
> Windows 2 (filtered on /foo/)
> ========
> 3 Line 3 foo
> 6 Line 6 foo
>
> ________________________________
> Beställ bläck före 19 för leverans nästa vardag inkClub
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Thanks, But this will not help since the file could be almost 1MB and
there could be many lines between the hits.
I don't think this use-case is unique. To filter out irrelevant data
and only work with the relevant data. That's what many script-
languages like perl etc. was developed for...

If vim can't do this, we will probably build a special editor for
this. But hey... I'm the only vim-user at the company and this is a
chance to get other to use/like vim as well.


On 2 Dec, 04:05, "Michael Phillips" <linux...@...> wrote:
> This is an idea, so I do not know how well it will work.  Have you try
> to use syntax highlighting?  Make the text you do not want the same
> color as the background.
>
>
>
> On Mon, Dec 1, 2008 at 3:48 PM, PärAdeen<par_ad...@...> wrote:
> > This is something that partly is provided by vim by folding. But I don't
> > want the folding texts...
>
> > What I want is to watch a file in two views where the second one is a
> > filtered view of the first one.
>
> > Can anyone please help me. I'm not a very advanced user
>
> > Q. I would like to have a dual view of my file with many thousand lines.
>
> > A. I could do this with a vertical split.
>
> > Q. Then I would like to two windows to be synchronized.
>
> > A. I could do this with the :scrollbind command
>
> > So far everything is good... But then:
>
> > Q. I want to filter the view to only show text matching my regex
>
> > A. There's a VIM-tip's for that:
>
> > :set fold
>
> > :set foldexpr=getline(v:lnum)!~@/
> > :nnoremap <F8> :set foldmethod=expr<CR><Bar>zM
>
> > The problem is that I cant get rid of the text: "+--27 lines:
> > xxx-----------------"
>
> > I would like a list of all lines containing my regex and nothing else. The
> > output I would like is similar to the output generated by this command:
>
> > :g!/MyRegEx/d
>
> > but I don't want to delete the text since I want to edit the complete file
> > (but in a filtered view)
>
> > The second problem I get is that I want to :scrollbind to completely sync
> > the lines between the current cursor line in my filtered window with the
> > line i my unfiltered windows so that I could see the surrounding text
>
> > Example:
>
> > Windows 1 (original)
> > ========
> > 1 Line 1
> > 2 Line 2
> > 3 Line 3 foo
> > 4 Line 4
> > 5 Line 5
> > 6 Line 6 foo
> > 7 Line 7
>
> > Windows 2 (filtered on /foo/)
> > ========
> > 3 Line 3 foo
> > 6 Line 6 foo
>
> > ________________________________
> > Beställ bläck före 19 för leverans nästa vardag inkClub- Dölj citerad text -
>
> - Visa citerad text -
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi again. The example should be:

Windows 1 (original)========
1 Line 1
2 Line 2
3 Line 3 foo
4 Line 4
5 Line 5
6 Line 6 foo
7 Line 7


Windows 2 (filtered on /foo/)========
3 Line 3 foo
6 Line 6 foo

BR


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Tim Chase (2008-12-01 14:19 -0600) wrote:

> Matt Wozniski wrote:
>> if &fo =~ 'r' && &fo =~ 'o'
>>  set fo-= fo-=r
>> else
>>  set fo+=ro
>> endif
>
> Matt's solution is good, but I think he missed a "o" in his
> transcription of the "-=" bits:
>
>    set fo-=o fo-=r
>            ^

Also, sometimes it may be better to use "setlocal" instead of "set". The
"set" command keeps changing the default value of 'fo'.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Matt Wozniski (2008-12-01 20:10 -0500) wrote:

> On Mon, Dec 1, 2008 at 6:48 PM, snitko wrote:
>> Great, thank you. Btw, since when second line in git should be empty?

This may not be a "should" statement but in the git.git repository Linus
Torvalds had this practice since the day one (2005-04-07).

> See man git-commit
>
> DISCUSSION
>        Though not required, it´s a good idea to begin the commit
>        message with a single short (less than 50 character) line
>        summarizing the change, followed by a blank line and then a
>        more thorough description.

And a real-life example from git.git and linux-2.6.git repositories:

     http://git.kernel.org/?p=git/git.git;a=log
     http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=log

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi,

Timothy Madden wrote:
>
> My vim says Invalid expression `wine GUIDGEN.exe` after I
> type :Guidgen,
> which I defined like this in ~/.vimrc:
>
> command Guidgen :s$\%#[-[:xdigit:]]\{36}$\=`wine GUIDGEN.exe`
>
> I have vim7.2 on Slackware.

you might try

   command Guidgen :s$\%#[-[:xdigit:]]\{36}$\=system('GUIDGEN.exe')

instead.

Regards,
Jürgen

--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us.     (Calvin)

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi

I'm using vim 7.2.60 on linux.
When I run ":e <directory name>" to show a directory list, some of
the filenames and directorynames in the list have "e" at the
beginning of their names, and hitting "Enter" key on a directory name
with "e" at the top in the list won't go down under the directory.
Similarly hitting "Enter" on a filename with "e" at the top in the
list opens a new file. It looks like "e" is added to the names
between "../" or "./" and just before a name beginning with an
uppercase letter in the list. For example, ":e ." shows the following:

...
xsession-errors
.xwm.msgs
.zphotorc
e../
e.Eterm/
e.Tgif/
e.Trash/
e.Wnn7/
e.adobe/
...
ework/
e.bash_profile~
e.bashrc~
e.mew.el~
e.mytips~
e.signature.alist~
Xrootenv.0

Pressing "s" for sort once and twice "e"s at the beginning of their
names disappear, but doing it three times "e"s appear at the top of
their names again.

Would someone please help me solve this strange listing problem?
Thanks in advance.
--Yasufumi

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hello everyone. I'm gonna paste an example of what i want to do. Let's
imagine that I have this code:

<p id="already_registered">

And i wanna copy id="already_registered" in a register, for example
the register "P". How can i do that, and how can i paste it back
later?

Thanks in advance.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

2008/12/2 Shade <celebdel@...>:
>
> Hello everyone. I'm gonna paste an example of what i want to do. Let's
> imagine that I have this code:
>
> <p id="already_registered">
>
> And i wanna copy id="already_registered" in a register, for example
> the register "P". How can i do that, and how can i paste it back
> later?

In what situation?  A script?  In normal mode?

I'm sure there are better ways of doing this, but one that springs to
mind for scripts is:

let ml = matchlist(getline('.'), '<p \(id="[^"]*"\)>')
let @P = ml[1]

Of course, you may need to bulk it out to check that the regexp
actually matches etc

For pasting, either use setline() or :put

:help matchlist()
:help match()
:help let-@
:help setline()
:help :put

Hope that helps,

Al

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi Michael:

The default way is put everything {autoload/plugin/ftplugin} into a new
directory, then set runtimepath+=dir in your .vimrc

Howoever I even consider this to be too cumbersome. Have look at my new
project:

git://mawercer.de/theonevimlib

Marc

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---