thanks,  I was looking for this.
vipin

--------------------------------------------------------------------------------\
--------------------------------------
Information transmitted by this E-MAIL is proprietary to Wipro and/or its
Customers and
is intended for use only by the individual or entity to which it is
addressed, and may contain information that is privileged, confidential or
exempt from disclosure under applicable law. If you are not the intended
recipient or it appears that this mail has been forwarded to you without
proper authority, you are notified that any use or dissemination of this
information in any manner is strictly prohibited. In such cases, please
notify us immediately at mailto:mailadmin@... and delete this mail
from your records.
--------------------------------------------------------------------------------\
--------------------------------------

On Mon, Oct 01, 2001 at 10:48:31AM +0530, vipin aravind wrote:
> hi guys,
>    I am using the  following fold method from :h  fold
> syn region myFold start="{" end="}" transparent fold
> syn sync fromstart
> set foldmethod=syntax
>
> when I open a file I can see the folds.
> I do
> /foo.
> fold which contains this string opens.
> I  type  'n'  to get to next search.
>
> when I move out of the previous  fold  which  was opened ,   I had like
> that to be closed  agaim.

you might want to play around with
:set foldopen=all
:set foldclose=all

also see
:he folding


--
Sergio J. Rey http://typhoon.sdsu.edu/rey.html
GPG fingerprint =  16DB 4934 E0F1 B386 AE81  D379 914C 33E5 F690 95DF
Did you check the IGNOREME file?  - anonymous

Hi,

When I'm editing tex or html (or anything that has some formatting and
lots of text), I'd like to have a way to indent and do text wrapping at
the same time. If I try to gqap on a paragraph that contains formatting
information (let's say some itemizing, for instance), then it's just
transformed into a block of text. On the other hand, if I decide to
indent a paragraph (or rather a block) doing a =a{, there is no
readjusting of the text part (no line breaking or joining). Is it
possible to have both ?

Alan Schmitt


--
The hacker: someone who figured things out and made something cool happen.

hi guys,
    I am using the  following fold method from :h  fold
syn region myFold start="{" end="}" transparent fold
syn sync fromstart
set foldmethod=syntax

when I open a file I can see the folds.
I do
/foo.
fold which contains this string opens.
I  type  'n'  to get to next search.

when I move out of the previous  fold  which  was opened ,   I had like
that to be closed  agaim.

How can I accomplish this?
thanks
vipin

--------------------------------------------------------------------------------\
--------------------------------------
Information transmitted by this E-MAIL is proprietary to Wipro and/or its
Customers and
is intended for use only by the individual or entity to which it is
addressed, and may contain information that is privileged, confidential or
exempt from disclosure under applicable law. If you are not the intended
recipient or it appears that this mail has been forwarded to you without
proper authority, you are notified that any use or dissemination of this
information in any manner is strictly prohibited. In such cases, please
notify us immediately at mailto:mailadmin@... and delete this mail
from your records.
--------------------------------------------------------------------------------\
--------------------------------------

On Sun, 30 Sep 2001, Paul Tremblay wrote:
> Whenever I start adding words in the middle of a paragraph, the
> lines start scattering like loose change, as I lose the paragraph
> formating. To reformat the paragrah, I switch to normal mode and
> type gqip (reformat inner paragraph). However, the cursor then
> ends up at the bottom of the paragrah. That means I have to move
> the cursor back up to where I was editing.

I'm not sure why you are needing to reformat before you are done
editing the paragraph?  Have you played with these?
:h wrap
:h linebreak
:h formatoptions

Alan

* Paul Tremblay <phthenry@...> [011001 01:42]:
> Whenever I start adding words in the middle of a paragraph, the
> lines start scattering like loose change, as I lose the paragraph
> formating. To reformat the paragrah, I switch to normal mode and
> type gqip (reformat inner paragraph). However, the cursor then
> ends up at the bottom of the paragrah. That means I have to move
> the cursor back up to where I was editing.  This makes it very
> difficult to use vim for my purposes. Is there any way to make
> lines wrap, even when you start editing the middle of a paragraph?

No. Feature.  You *dont* Vim to keep updating every paragraph
whenver you type something - especially not on huge paragraphs.
trust me on that!  :-)  (a hello to all W*rd users out there!)

> As a workaround, I suppose I could map a ctr key to exectue the
> command gqip; but that would still mean I lose the cursor position.
> Any suggestions?

Workaround:  Use a mapping which inserts a word
which you probably dont use in your texts at all
and have Vim jump back to it after the reformatting:

   imap <C-J> foo <esc>gqip?foo<cr>ce

Won't that do?

Sven

--
Sven Guckes       guckes@...
Addicted to Vim  --  101 reasons
http://www.vim.org/addicted.html
Got more reasons?     Send them!

I  use vim to edit text I've written. (I then format it in
lyx.)

Whenever I start adding words in the middle of a paragraph, the
lines start scattering like loose change, as I lose the paragraph
formating. To reformat the paragrah, I switch to normal mode and
type gqip (reformat inner paragraph). However, the cursor then
ends up at the bottom of the paragrah. That means I have to move
the cursor back up to where I was editing.

This makes it very difficult to use vim for my purposes. Is there
any way to make lines wrap, even when you start editing the
middle of a paragraph?

As a workaround, I suppose I could map a ctr key to exectue the
command gqip; but that would still mean I lose the cursor
postion.

Any suggestions?

Thanks

--
************************
*Paul Tremblay         *
*phthenry@...*
************************

I think this is only generic for clearcase.  Do any other systems use
this method of naming files?  Note that the solution below is similar to the
very first autocommand defined in $VIMRUNTIME/filetype.vim :

" Ignored extensions
au BufNewFile,BufRead *.orig,*.bak,*.old,*.new,*.rpmsave,*.rpmnew
	 \ exe "doau filetypedetect BufRead " . expand("<afile>:r")

Also, I hope you did read :help new-filetype as someone else suggested.  The
problem with adding things to $VIMRUNTIME/filetype.vim is that you have to do
it again when you upgrade to Vim 6.1.  (It feels strange to say that, after
predicting an upgrade to 6.0 for so long!)

HTH 			 --Benji Fisher

Dominique Pelle wrote:
>
> Works like a charm!  Exactly what I was looking for:
> short and instructive solution, very useful for all
> clearcase users.
>
> This is so generic that, IMHO, it deserves to be
> included in the default "filetype.vim" shipped with
> the next vim release.
>
> -- Dominique
>
> On Sun, Sep 30, 2001 at 05:48:59PM -0600, Christian J. Robinson
(infynity@...) wrote:
> > There is, try this:
> >
> > augroup clearcase
> >   au! BufRead,BufNewFile *.*@@/* exe "doau filetypedetect BufRead " .
strpart(expand("<afile>"),0,stridx(expand("<afile>"),"@@"))
> > augroup END

Here's an odd one:

On Solaris 2.8 Sparc, compiled with GCC 3.0 (from the latest CVS
sources), I get a seg fault if I type :filetype to display the filetype
settings.

Here's the exact error:
-----
Vim: Caught deadly signal SEGVON  indent:ON

E363: pattern caused out-of-stack errorVim: Finished.

E363: pattern caused out-of-stack error
Segmentation fault (core dumped)
-----

Using exactly the same .vimrc an another Sparc Solaris 2.8 machine,
compiled with the Sun WorkShop 6 compiler, I don't get the seg fault..
Anybody else seen this problem?

:version
VIM - Vi IMproved 6.0 (2001 Sep 26, compiled Sep 29 2001 16:40:07)
Included patches: 2, 1, 3-7
Compiled by miner@hib
Huge version with GTK-GNOME GUI.  Features included (+) or not (-):
+autocmd -balloon_eval +browse ++builtin_terms +byte_offset +cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
+cryptv +cscope +dialog_con_gui +diff +digraphs -ebcdic +emacs_tags +eval
+ex_extra +extra_search +farsi +file_in_path +find_in_path +folding -footer
+fork() +gettext -hangul_input +iconv +insert_expand +jumplist +keymap +langmap
+libcall +linebreak +lispindent +listcmds +localmap +menu +mksession
+modify_fname +mouse +mouseshape +mouse_dec -mouse_gpm -mouse_jsbterm
+mouse_netterm +mouse_xterm +multi_byte +multi_lang -osfiletype +path_extra
-perl +postscript +printer -python +quickfix +rightleft -ruby +scrollbind
+signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary
+tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title
+toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo
+vreplace +wildignore +wildmenu +windows +writebackup +X11 +xfontset +xim
+xterm_clipboard -xterm_save
    system vimrc file: "$VIM/vimrc"
      user vimrc file: "$HOME/.vimrc"
       user exrc file: "$HOME/.exrc"
   system gvimrc file: "$VIM/gvimrc"
     user gvimrc file: "$HOME/.gvimrc"
     system menu file: "$VIMRUNTIME/menu.vim"
   fall-back for $VIM: "/usr/local/gnu/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -I/opt/gnome-1.4
/include/gtk-1.2 -I/opt/gnome-1.4/include/glib-1.2 -I/opt/gnome-1.4/lib/glib/inc
lude -I/opt/gnome-1.4/include -DNEED_GNOMESUPPORT_H -I/opt/gnome-1.4/lib/gnome-l
ibs/include -I/opt/gnome-1.4/include/glib-1.2 -I/opt/gnome-1.4/lib/glib/include
-I/opt/gnome-1.4/include/gtk-1.2   -O2 -fno-strength-reduce -Wall  -I/usr/openwi
n/include
Linking: gcc  -L/usr/openwin/lib -R/usr/openwin/lib  -L/usr/local/lib -o vim   -
L/opt/gnome-1.4/lib -lgtk -lgdk -lgmodule -lglib -ldl -lXext -L/opt/gnome-1.4/li
b -lgnomeui -lart_lgpl -lgdk_imlib -lgtk -lgdk -lgmodule -lXext -lgnome -lgnomes
upport -lesd -lresolv -lrt -laudiofile -lm -ldb -lglib -ldl -lXt -ltermlib


--
.Jonathan J. Miner------------------Division of Information Technology.
|miner@...                 University Of Wisconsin - Madison|
|608/262.9655                               Room 3149 Computer Science|
`---------------------------------------------------------------------'

That gets us out of deciding how to spell Reg[eE]xp?|RE . . .
Of course, then we have to decide what ref $re returns...  :-)
              -- Larry Wall in <199710171838.LAA24968@...>
                                                                  (209)

Works like a charm!  Exactly what I was looking for:
short and instructive solution, very useful for all
clearcase users.

This is so generic that, IMHO, it deserves to be
included in the default "filetype.vim" shipped with
the next vim release.

-- Dominique

On Sun, Sep 30, 2001 at 05:48:59PM -0600, Christian J. Robinson
(infynity@...) wrote:
> There is, try this:
>
> augroup clearcase
>   au! BufRead,BufNewFile *.*@@/* exe "doau filetypedetect BufRead " .
strpart(expand("<afile>"),0,stridx(expand("<afile>"),"@@"))
> augroup END

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Today, Dominique Pelle wrote:

> Hi,
>
> I read ':help new-filetype' section but that does not seem to
> answer my question.
>
> What I'd like to do is tell vim that:
>   - '*.c@@/*'   files have the same filetype as '*.c'   files
>   - '*.cpp@@/*' files have the same filetype as '*.cpp' files
>   - '*.h@@/*'   files have the same filetype as '*.h'   files
>   - '*.s@@/*'   files have the same filetype as '*.s'   files
>
>   - etc, etc.  You get the point there are many file extensions
>
> The only way I see so far is the brute force method, that is
> changing all existing rules for all file extensions.
>
> Whether I change the default $RUNTIME/filetype.vim" or use
> "new-filetype", it is not a very elegant solution.  Something
> tells me that there has to be a more clever way of doing it.

There is, try this:

augroup clearcase
   au! BufRead,BufNewFile *.*@@/* exe "doau filetypedetect BufRead " .
strpart(expand("<afile>"),0,stridx(expand("<afile>"),"@@"))
augroup END


- - Christian

- --
             Life is something none of us get out of alive.
      Christian J. Robinson <infynity@...>  ICQ: 15869262
http://www.infynity.mux.cx/  GPG key: hkp://pgpkeys.mit.edu/0x893B0EAF
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7t69vNCSthIk7Dq8RAiayAJ9kHygTHOk38Fln9PDbZ3FT9XZPjwCdFCnw
6298BnvzrDOjCuUXZbBMVwA=
=rdIE
-----END PGP SIGNATURE-----

Hi,

I read ':help new-filetype' section but that does not seem to
answer my question.

What I'd like to do is tell vim that:
   - '*.c@@/*'   files have the same filetype as '*.c'   files
   - '*.cpp@@/*' files have the same filetype as '*.cpp' files
   - '*.h@@/*'   files have the same filetype as '*.h'   files
   - '*.s@@/*'   files have the same filetype as '*.s'   files

   - etc, etc.  You get the point there are many file extensions

The only way I see so far is the brute force method, that is
changing all existing rules for all file extensions.

Whether I change the default $RUNTIME/filetype.vim" or use
"new-filetype", it is not a very elegant solution.  Something
tells me that there has to be a more clever way of doing it.

-- Dominique

On Mon, Oct 01, 2001 at 12:01:48AM +0200, David Reviejo (dreviejo@...)
wrote:
> * Dominique Pelle <dominique.pelle@...> [010930 23:48]:
> > Vim does not guess the filetype when opening a file using
> > clearcase extended filenames.  For example, vim does not guess
> > that "foo.c@@/main/LATEST" is a C file by default.
> >
> > To fix this, I changed my "$VIMRUNTIME/filetype.vim" to replace...
> >
> >     au BufNewFile,BufRead *.c               setf c
> >
> > ... into...
> >
> >     au BufNewFile,BufRead *.c,*.c@@/*       setf c
> >
> > It works well.  However, I would need to do the same
> > for all other filetypes.
> >
> > I seems to me that there must be a more elegant solution.
>
> See
> :h new-filetype
>
> --
> David

* Dominique Pelle <dominique.pelle@...> [010930 23:48]:
> Vim does not guess the filetype when opening a file using
> clearcase extended filenames.  For example, vim does not guess
> that "foo.c@@/main/LATEST" is a C file by default.
>
> To fix this, I changed my "$VIMRUNTIME/filetype.vim" to replace...
>
>     au BufNewFile,BufRead *.c               setf c
>
> ... into...
>
>     au BufNewFile,BufRead *.c,*.c@@/*       setf c
>
> It works well.  However, I would need to do the same
> for all other filetypes.
>
> I seems to me that there must be a more elegant solution.

See
:h new-filetype

--
David

On Sun, Sep 30, 2001 at 11:14:09PM +0900, Jim Tittsler (jwt@...) wrote:
> I've inherited some very old C code that is riddled with
> conditional compilation directives.  It would be great
> to have an automatic way of hiding the currently unused
> code sections.
>
> Is there a script that will run the C preprocessor, and
> then analyze its output to put fold marks in my original
> file that would hide the *current* unincluded sections?
> Or are there tricks to make effective use of folding
> in this situation?


I had the same kind of code to maintain: many '#ifdef SOME_VAR'
and most of the code being unused (SOME_VAR being undefined).

Vim already recognizes '#if 0' block of code and use a different
syntax highlighting.

I wish there was an easy way to tell vim that SOME_VAR cpp var is
undefined so vim could highlight code within '#ifdef SOME_VAR'
the same way it already does with '#if 0'.

-- Dominique

I believe you also need the ability to be notified of events or actions from
vim so they can be handled as well.  For example, vim could send the event
"reached bottom of file", then the IDE could take the appropriate steps.
Any such interface would require communication in two directions,
eventually.  The typical drill in Java is to send the commands and receive
the events through a network port allowing one to attach to a running
process after it has already begun.  It is a very powerful model that has
proved (to me ;) to be best way to encapsulate a tool and making itself
available to the outside world.  The power of Vim will increase
exponentially once such an interface is implemented (if it isn't already).


----- Original Message -----
From: "Tomas Zellerin" <zellerin@...>
To: <vim@...>
Sent: Sunday, September 30, 2001 11:21 AM
Subject: Re: Vim IDE


> On Fri, Sep 28, 2001 at 11:02:20AM +0200, Marc CHANTREUX wrote:
> > On Fri, Sep 28, 2001 at 10:39:16AM +0200, Bram Moolenaar wrote:
> > > It requires a bit more than that.  You need to have the debugger tell
> > > Vim what source code to display.  You need to have some commands in
Vim
> > > to define breakpoints and pass them to the debugger.
> > >
> > > The Sun Workshop interface does this.  Most of the clever logic is in
> > > the Workshop program.  This also allows quitting Vim and restarting
it,
> > > and still display all the breakpoints.
> >
> > so is it possible to program a vim plugin in C without knowing  the
> > vim internals ? an API or something like that ?
>
> I would say all you need is the ability of vim to accept remote commands
> (and its ability to write into a file, of course).
>

Hi,

When opening "foo.c", vim recognizes that "foo.c" is a C file from
the filename extention and sets "filetype" variable.

Vim does not guess the filetype when opening a file using
clearcase extended filenames.  For example, vim does not guess
that "foo.c@@/main/LATEST" is a C file by default.

To fix this, I changed my "$VIMRUNTIME/filetype.vim" to replace...

     au BufNewFile,BufRead *.c               setf c

... into...

     au BufNewFile,BufRead *.c,*.c@@/*       setf c

It works well.  However, I would need to do the same
for all other filetypes.

I seems to me that there must be a more elegant solution.

Any takers?

-- Dominique

On Sun, Sep 30, 2001 at 08:28:27PM +0100, Paul Moore wrote:

-snip-

paul,

> >I copied the above text into vim, and did not see the same thing.  Are
> >you using the released Vim 6.0 or one of the alphas or betas?
>
> I get the "right" behaviour with Vim 6.0.3 (ie, the blank line does *not* end
> the fold). Looks like a bug which was fixed before the final release...

maybe i got a different result from yours, not sure if it is right
though. upon opening the python file i get:

class MyNotebook(wxNotebook):
    def __init__(self, parent):
+-- 8 lines: idNotebook = NewId()-------------

>
> On the other hand, there is a minor annoyance - the *body* of the __init__
> function is treated as an extra fold level, above and beyond the one for the
> "def" line. So we have folds

so the body of the __init__ function is treated as a fold for me, but it
is the first one, not the second. this is with Vim 6.0 compiled from
source yesterday.

>
> 1    class MyNotebook(wxNotebook):
> 2       def __init__(self, parent):
> 3          idNotebook = NewId()
> 3          wxNotebook.__init__(self, parent, idNotebook)
> 3
> 3          idNotebook = NewId()
> 3          self.search = SearchWin.SearchWin(self, mainWin, archiveList)
> 3          self.add = AddWin.AddWin(self, mainWin, archiveList)
> 3          self.AddPage(self.add, "Add Archive")
> 3          self.AddPage(self.search, "Search Archives"

am i correct in assuming your result would look something like (top fold
only) the following?

class MyNotebook(wxNotebook):
+-- 9 lines: def __init__(self,parent):-------------


>
> where I'd prefer (and I'd claim it's more logical) the level 3 folds to be
> merged with the level 2 one. Of course, there's a difficulty if there are
extra
> lines at level 2 (assignments, for instance). In the excat case above, the def
> and its associated lines should be at level 2, whereas if there was an
> intervening line (say an assignment( at level 2 just above the def, you'd want
> the def and its associated lines to be a *separate* fold (at level 2).

if i have your fold result correct, then i'm puzzled why i have the
first fold being made on the __init__ function while yours is on the
class definition?

i'm not sure which i prefer, as they both display the arguments for the
__init__ function, which i'd want to have displayed in any folding.

i was thinking that switching the foldmethod to marker and then mapping
some keys so that classes get the begin and end-fold markers would be a
way to get around the merge problem. while this would work, it might
cause aesthetic problems since the code would be littered with the
markers, and i'm not sure how python doc strings would work with the
markers.



--
Sergio J. Rey http://typhoon.sdsu.edu/rey.html
GPG fingerprint =  16DB 4934 E0F1 B386 AE81  D379 914C 33E5 F690 95DF
Send lawyers, guns and money.
         - Warren Zevon

Paul Moore wrote:
>
[snip]
> On the other hand, there is a minor annoyance - the *body* of the __init__
> function is treated as an extra fold level, above and beyond the one for the
> "def" line. So we have folds
>
> 1    class MyNotebook(wxNotebook):
> 2       def __init__(self, parent):
> 3          idNotebook = NewId()
> 3          wxNotebook.__init__(self, parent, idNotebook)
> 3
> 3          idNotebook = NewId()
> 3          self.search = SearchWin.SearchWin(self, mainWin, archiveList)
> 3          self.add = AddWin.AddWin(self, mainWin, archiveList)
> 3          self.AddPage(self.add, "Add Archive")
> 3          self.AddPage(self.search, "Search Archives"
>
> where I'd prefer (and I'd claim it's more logical) the level 3 folds to be
> merged with the level 2 one. Of course, there's a difficulty if there are
extra
> lines at level 2 (assignments, for instance). In the excat case above, the def
> and its associated lines should be at level 2, whereas if there was an
> intervening line (say an assignment( at level 2 just above the def, you'd want
> the def and its associated lines to be a *separate* fold (at level 2).
>
> I don't think this can be done via foldmethod=indent. Looks like some sort of
> "expr"-based folding is needed. I'd base it on the presence of a colon at the
> end of a line, as this is what introduces nesting constructs in Python.
> (Roughly, the trailing colon marks the *start* of a block, and the end of the
> indented section marks the *end*.
>
> Paul.

      I think you are right:  to get this behavior, you will need to use
'foldexpr'.  You have come pretty close to describing an algorithm for
computing the indent; if you actually give such an algorithm, it cannot be
hard to write a function to implement it.  The algorithm is something like
this:

1. If this is a blank line, set the fold level to -1.
2. If the previous line ends with a : and this line is indented, keep the fold
level.
3. If this line is indented and has a colon, then increase the fold level.
4. If this line is not indented and has a colon, then end one fold and start a
new one at the same level.  (I think this can be done.)
5. If this line is indented less than the previous line, reduce the fold level
by the appropriate number.

Interpret "previous line" to mean "previous non-blank line."

:help fold-expr

HTH 			 --Benji Fisher

Hi,
I've been thinking around the lines of
if executable("cat")
     let g:CatProg="cat"
else if executable("Type")
     let g:CatProg="Type"
endif
what do you think?
Benoit
----- Original Message -----
From: "Piet Delport" <siberiyan@...>
To: "Benoit Cerrina" <b.cerrina@...>
Cc: <vim@...>
Sent: Sunday, September 30, 2001 8:15 PM
Subject: Re: read a file in a variable

On Sat, 29 Sep 2001 22:15:38 -0400, Benji Fisher <benji@...> wrote:

>> I am trying to understand folding, so I tried using foldmethod=indent on a
python file.
>> Mostly it works great, but it stops a fold if there is a blank line in the
function, like in the following code:
>>
>>      class MyNotebook(wxNotebook):
>>         def __init__(self, parent):
>>            idNotebook = NewId()
>>            wxNotebook.__init__(self, parent, idNotebook)
>>
>>            idNotebook = NewId()
>>            self.search = SearchWin.SearchWin(self, mainWin, archiveList)
>>            self.add = AddWin.AddWin(self, mainWin, archiveList)
>>            self.AddPage(self.add, "Add Archive")
>>            self.AddPage(self.search, "Search Archives"
[...]
>
>I copied the above text into vim, and did not see the same thing.  Are
>you using the released Vim 6.0 or one of the alphas or betas?

I get the "right" behaviour with Vim 6.0.3 (ie, the blank line does *not* end
the fold). Looks like a bug which was fixed before the final release...

On the other hand, there is a minor annoyance - the *body* of the __init__
function is treated as an extra fold level, above and beyond the one for the
"def" line. So we have folds

1    class MyNotebook(wxNotebook):
2       def __init__(self, parent):
3          idNotebook = NewId()
3          wxNotebook.__init__(self, parent, idNotebook)
3
3          idNotebook = NewId()
3          self.search = SearchWin.SearchWin(self, mainWin, archiveList)
3          self.add = AddWin.AddWin(self, mainWin, archiveList)
3          self.AddPage(self.add, "Add Archive")
3          self.AddPage(self.search, "Search Archives"

where I'd prefer (and I'd claim it's more logical) the level 3 folds to be
merged with the level 2 one. Of course, there's a difficulty if there are extra
lines at level 2 (assignments, for instance). In the excat case above, the def
and its associated lines should be at level 2, whereas if there was an
intervening line (say an assignment( at level 2 just above the def, you'd want
the def and its associated lines to be a *separate* fold (at level 2).

I don't think this can be done via foldmethod=indent. Looks like some sort of
"expr"-based folding is needed. I'd base it on the presence of a colon at the
end of a line, as this is what introduces nesting constructs in Python.
(Roughly, the trailing colon marks the *start* of a block, and the end of the
indented section marks the *end*.

Paul.

On Fri, Sep 28, 2001 at 11:02:20AM +0200, Marc CHANTREUX wrote:
> On Fri, Sep 28, 2001 at 10:39:16AM +0200, Bram Moolenaar wrote:
> > It requires a bit more than that.  You need to have the debugger tell
> > Vim what source code to display.  You need to have some commands in Vim
> > to define breakpoints and pass them to the debugger.
> >
> > The Sun Workshop interface does this.  Most of the clever logic is in
> > the Workshop program.  This also allows quitting Vim and restarting it,
> > and still display all the breakpoints.
>
> so is it possible to program a vim plugin in C without knowing  the
> vim internals ? an API or something like that ?

I would say all you need is the ability of vim to accept remote commands
(and its ability to write into a file, of course).

Hello,

I've written a indent-file for Haskell. It isn't finshed yet
but I'd like to hear comments about it. I does most of the things I'd
want it to but it isn't customizable and it has a few bugs.

If you are interested you can find it here:
http://www.dtek.chalmers.se/~d99josve/haskell.vim

/jonas
--
[uggc://jjj.qgrx.punyzref.fr/~q99wbfir/  ]
:wq

On Sun, 30 Sep 2001 at 18:13:04 +0200, Benoit Cerrina wrote:
> Hi,
> is there a way to read a file in a variable both on win32 and unix
> (on unix I'd do
> let var=system("cat filename")
> but I can't be sure that there is a cat on any win32 box and if I can
> I'd rather not require it.

Off the top of my head:

if has('win32') || has('win95') || has('win16') || has('dos32') || has('dos16')
   let var=system('type foo')
else
   let var=system('cat foo')
endif

Untested, as usual. :-)  And you can kill the has() tests for
DOS/Windows variants you know you won't be supporting, of course.

--
Piet Delport <siberiyan@...>
Today's subliminal thought is:

Hi,
is there a way to read a file in a variable both on win32 and unix
(on unix I'd do
let var=system("cat filename")
but I can't be sure that there is a cat on any win32 box and if I can
I'd rather not require it.
Benoit

I've inherited some very old C code that is riddled with
conditional compilation directives.  It would be great
to have an automatic way of hiding the currently unused
code sections.

Is there a script that will run the C preprocessor, and
then analyze its output to put fold marks in my original
file that would hide the *current* unincluded sections?
Or are there tricks to make effective use of folding
in this situation?

On Sat, Sep 29, 2001 at 10:15:38PM -0400, Benji Fisher wrote:
-snip-
> > Which requires two folds if I fold in the body of the function __init__:
> >
> >      class MyNotebook(wxNotebook):
> >         def __init__(self, parent):
> >      +---  2 lines: idNotebook = NewID()
> >
> >      +---  5 lines: idNotebook = NewID()
> >
> > The documentation says that the space should have a fold level of the lines
surrounding it.  Why does it stop the fold?
>
>      I copied the above text into vim, and did not see the same thing.  Are
> you using the released Vim 6.0 or one of the alphas or betas?  Note that
> indent-based folding depends on the 'shiftwidth' option.  I do not see how it
> could lead to what you describe, but do you have 'sw' set to something
> reasonable for your code?  (I know, this is a long shot!)

i wasn't able to reproduce the problem with 6.0 or an older beta
(6.0ap). in other words, i get a single fold for the entire class code.
following up on benji's suggestion, perhaps the sw setting is something
to look at.

i have the following set-up for editing python files:
set tabstop=4
set shiftwidth=4
set expandtab
set softtabstop=4
set si
set ai
set foldmethod=indent

and folding works as described in the manual. this is under debian
potato.

HTH
--
Sergio J. Rey http://typhoon.sdsu.edu/rey.html
GPG fingerprint =  16DB 4934 E0F1 B386 AE81  D379 914C 33E5 F690 95DF
rust never sleeps.
         - Neil Young

> >although I read a lot about python I haven't have much occasion to use it
> >but due to the role of indenting in the python syntax
> >I believe that foldmethod=indent would be almost ideal without the need for
> >a syntax based folding.
>
> I am trying to understand folding, so I tried using foldmethod=indent on a
python file.
> Mostly it works great, but it stops a fold if there is a blank line in the
function, like in the following code:
>
>      class MyNotebook(wxNotebook):
>         def __init__(self, parent):
>            idNotebook = NewId()
>            wxNotebook.__init__(self, parent, idNotebook)
>
>            idNotebook = NewId()
>            self.search = SearchWin.SearchWin(self, mainWin, archiveList)
>            self.add = AddWin.AddWin(self, mainWin, archiveList)
>            self.AddPage(self.add, "Add Archive")
>            self.AddPage(self.search, "Search Archives"
>
> Which requires two folds if I fold in the body of the function __init__:
>
>      class MyNotebook(wxNotebook):
>         def __init__(self, parent):
>      +---  2 lines: idNotebook = NewID()
>
>      +---  5 lines: idNotebook = NewID()
>
> The documentation says that the space should have a fold level of the lines
surrounding it.  Why does it stop the fold?

      I copied the above text into vim, and did not see the same thing.  Are
you using the released Vim 6.0 or one of the alphas or betas?  Note that
indent-based folding depends on the 'shiftwidth' option.  I do not see how it
could lead to what you describe, but do you have 'sw' set to something
reasonable for your code?  (I know, this is a long shot!)

      When you say that you "fold in the body of the function __init__" what do
you mean?  Do you use zm or :set foldlevel to increase the level of folding?

					 --Benji Fisher

"Arjona, Ariel" wrote:
>
> I upgraded last night from gvim5.7 to gvim6.0 relase. Got the
> self-extracting 3 MB file. I am running Windows 2000.
> The situation is the following:
> I use gvim to edit ASP files. Most files are over 500 lines. The thing is
> that many times when I scroll up the syntax highlighting messes up. I had
> that problem with gvim57 as well, and what I did was to set sync
> minlines=1000 and for most cases that worked like a charm. My problem is:
> minlines was set to 10 in html.vim, and I set it to 1000, but vim seems  to
> be ignoring my request.
> I had the exact same problem with gvim5.8 but I decided not to bother and
> continue working with 5.7 until 6.0.
> Now that 6.0 is here I'd love to know a way to make syntax highlighting work
> without glitches like it did with 5.7.
>
> Any help is greatly appreciated. I've been waiting for 6.0 for almost a year
> now and I'd hate to have to go back to 5.7 because of this (I can't stand
> messed up highlighting :)

      I think the idea is to put the syn sync line in a file called
$VIM/vimfiles/after/syntax/asp.vim

:help mysyntaxfile-add

Let us know if it works!

> Ariel
> ~
> ~
> :wq

      Was that on purpose? ;)

HTH 			 --Benji Fisher

Freund Or Meir wrote:
>
> I try this command for diff on my win98
> gvim -d scripts.vim sc1.vim
>
> and got the next errors :
> C:\WINDOWS\COMMAND.COM /c diff -a C:\WINDOWS\TEMP\VIo4224.TMP
C:\WINDOWS\TEMP\VI
> n4224.TMP >C:\WINDOWS\TEMP\VId4224.TMP
> Bad command or file name
>
> E97 :cannot create diffs
>
> I am using vim60
> VIM - Vi IMproved 6.0 (2001 Sep 26, compiled Sep 26 2001 17:12:46)
> MS-Windows 32 bit GUI version with OLE support
>
> I think the problem I dont have diff on vim98 where can I  get it?

      Yes, that looks like the problem.  Try Ron Aaron's page of utilities:
http://www.mossbayeng.com/~ron/vim/builds.html

Note to W95 users:  you can get a grep program from the same page.  Then try
out :grep in vim!

HTH 			 --Benji Fisher