Loading ...
Sorry, an error occurred while loading the content.

Re: Folding thoughts

Expand Messages
  • Arnaud Launay
    ... So now you re ready not to sleep for weeks :) ... Problems of w$ keys is that not everybody have them, and it will cause problems on machine which don t
    Message 1 of 28 , Apr 11, 2000
    • 0 Attachment
      Le Tue, Apr 11, 2000 at 11:43:43AM +0100, Allan Kelly a écrit:
      > <wildly off-topic>
      > baby 1.0, and we're having it at home!

      So now you're ready not to sleep for weeks :)

      > I wonder if that is possible? And what about those stupid windows keys?

      Problems of w$ keys is that not everybody have them, and it will cause problems
      on machine which don't have them. Maybe, a : command should be better...

      Arnaud.
    • David Harrison
      ... *chuckle* Well, this is David Harrison Jr. here. I started to implement my vision of folding based on, then, Vim 5.3. Then came a new baby... I second the
      Message 2 of 28 , Apr 11, 2000
      • 0 Attachment
        On Tue, Apr 11, 2000 at 10:39:57AM +0100, Neil Bird wrote:
        > Bram Moolenaar wrote:
        > > Allan Kelly wrote:
        > > > Hello, My wife and I are expecting a baby any day now [ =) ] and so I
        > > > am spending more time @ home than usual right now.
        > >
        > > Is that baby 1.0 or 2.0? :-)
        >
        > Must be baby number 1.0 - only someone who's not yet gone through those
        > first three months would be planning what to do in the 'spare' time
        > they'll have while at home after bringing the wife home :-)
        >
        > [10 months; just learned to crawl & making the most of it ;) ]

        *chuckle* Well, this is David Harrison Jr. here. I started to implement my
        vision of folding based on, then, Vim 5.3. Then came a new baby...
        I second the motion that it is baby 1.0 for them. The only time
        I seem to have to "work" on folding is in my dreams nowadays. :-)

        I based mine off of the syntax highlighting concept, as I believe it is a
        powerful one indeed. I am seeing this idea surface from others now, too.


        --David Harrison Jr.
        dharriso@...
      • Stephen P. Wall
        ... line ... What if I want the text on the fold line to come from the second line of folded text? Will you allow a multi-line regex? /^.*$^ s* (.* )$/*-- f
        Message 3 of 28 , Apr 11, 2000
        • 0 Attachment
          > From: Bram Moolenaar <Bram@...>
          >
          > Well, although I can imagine situations where you don't want a closed fold to
          > show a line, it can be quite confusing. And the line that replaces a closed
          > fold can contain the function heading, so in this case you don't need the
          line
          > to disappear. I just implemented a 'foldtext' option, which is a
          > substitute-like specification. The default is:
          >
          > /\(\S.*\)/+-- \f lines: \1
          >
          > The first part in between // is a regexp, which matches all text after the
          > indent. The "\f" is replaced with the number of folded lines. The "\1" is
          > replaced with the matched text, as in a substitue. The line is truncated to
          > fit in the window, it won't wrap.

          What if I want the text on the fold line to come from the second line
          of folded text? Will you allow a multi-line regex?

          /^.*$^\s*\(.*\)$/*-- \f lines: \1/

          Or a line number spec?

          2/\(\S.*\)/+-- \f lines: \1/ 2nd line of fold
          $/^\s*\(\S*\)/+-- \f lines: \1/ last line of fold

          How will this text be highlighted? Using it's normal highlighting,
          or a new Fold highlighting?


          > This needs more thinking. Perhaps sacrifying two columns to show the open
          ^^^^^^^^^^ sacrificing
          > folds in the left margin is a good solution in situations where you can have
          a
          > wider window (e.g., in the GUI). Something like this:
          >
          > - /* comment for next function */
          > 1 void
          > 1 function_name(args)
          > 1 {
          > - /* comment 1 */
          > 2 body_part_1
          > - /* comment 2 */
          > 2 body_part_2
          > 1 }
          >
          > The number indicates the fold level. The "-" marks the start of a fold.
          > This works, since a fold is always at least two lines. The margin would be
          > highlighted, if possible, to separate it from the text.

          Those who use numbering sacrifice 8 columns to do so, so I don't think
          sacrificing two columns to use folding is unreasonable. You could
          also use a number to mark the start of a fold, and a vertical bar to
          mark the body. This way, you still see the fold level when the fold
          is closed. Maybe add a '\l' to the foldtext option.

          Will you use the NonText highlight group for this column, or LineNr, or
          create a new group?

          What about navigation? Motion command to go to the start/end of the
          current/next fold region. Use wrapscan when at start/end of file?

          char action in Normal mode
          ----------------------------------------
          [| cursor to N previous start of a fold region
          ]| cursor to N next start of a fold region

          --
          Free High Speed DSL Access:
          http://in.winfire.com/s/isapiEng.dll/wf.exe?cmd=rl&452,180045277&wf.exe
          ______________________________________________________________________
          ________ ______
          Stephen P. Wall Redcom Laboratories, Inc. / __ /\/ ___/\
          Steve_Wall@... One Redcom Center ___/ /\/ /_/ /\__\/
          (716) 924-7550 Victor, NY 14564 /_____/ /_______/ /
          x300 USA \_____\/\_______\/
        • Bram Moolenaar
          ... It s an idea. I ll make a note of this. ... The markers are inside a comment, thus you can compile your file without any special treatment. Examples: /*
          Message 4 of 28 , Apr 12, 2000
          • 0 Attachment
            Ron Aaron wrote:

            > Hmm. I know this is a bit different, but how about allowing the
            > text-objects as targets as well? It would be most excellent to e.g. fold
            > this paragraph, or fold inside these braces.

            It's an idea. I'll make a note of this.

            > ach! Markers stuck *in* the text? This is really not a good idea, if that
            > is what you meant. Suppose I like folding a lot, and I save my doc, and
            > pass it to a friend? Suppose it's C code I want to compile? I shouldn't
            > have to unfold just to run a compile or share a doc.

            The markers are inside a comment, thus you can compile your file without any
            special treatment. Examples:

            /* local variables {{{1 */

            /* findFold() {{{5 */

            The text file is stored without any folds. Remembering which folds were
            closed will go into viminfo and session files. However, you often want a file
            to be folded completely when you open it again. Unless you stopped somewhere
            in the middle of doing something, then you want to go back to the saved
            folding state.

            The folding state can't be stored in the file, because several people could be
            viewing the same file with different folds open/closed. Storing fold state
            inside the file also changes the timestamp of the file, which has many
            disadvantages.

            --
            A consultant is a person who takes your money and annoys your employees while
            tirelessly searching for the best way to extend the consulting contract.
            (Scott Adams - The Dilbert principle)

            /-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
            \-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/
          • Bram Moolenaar
            ... At least Vim has an undo function... Eh, forget I said that! ... I know using Z is a bit dangerous, but couldn t think of another good choice. Looking
            Message 5 of 28 , Apr 12, 2000
            • 0 Attachment
              Allan Kelly wrote:

              > Vim: the editor for all the family =)
              > (better not say 'the family editor', the pope might chase us! ;)

              At least Vim has an "undo" function... Eh, forget I said that!

              > </wildly off-topic>
              >
              > Anyway, sounds like the folding code is quite advanced. I'm looking forward
              > to seeing it and although I appreciate Bram's sentiments of keep it to
              > himself for now, I think that Z (whilst very good because it _looks_
              > like a fold!) is very dangerous due to ZZ possible errors.

              I know using "Z" is a bit dangerous, but couldn't think of another good
              choice. Looking at the "Z" character as something folded is indeed a nice
              one.

              > Personally I'd love to map my (otherwise totally useless) CapsLock key to
              > fold operations. I wonder if that is possible? And what about those stupid
              > windows keys?

              You are of course free to make mappings to the "Z" commands. Using CapsLock
              or the windows key is impossible on many keyboards, thus these can't be used
              for the default command names.

              --
              You have heard the saying that if you put a thousand monkeys in a room with a
              thousand typewriters and waited long enough, eventually you would have a room
              full of dead monkeys.
              (Scott Adams - The Dilbert principle)

              /-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
              \-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/
            • Bram Moolenaar
              ... Once multi-line regexp is implemented, yes. A line-break must be matched explicitly with a n then. ... When would this be useful? I don t like adding
              Message 6 of 28 , Apr 12, 2000
              • 0 Attachment
                Stephen P. Wall wrote:

                > What if I want the text on the fold line to come from the second line
                > of folded text? Will you allow a multi-line regex?

                Once multi-line regexp is implemented, yes. A line-break must be matched
                explicitly with a "\n" then.

                > Or a line number spec?
                >
                > 2/\(\S.*\)/+-- \f lines: \1/ 2nd line of fold
                > $/^\s*\(\S*\)/+-- \f lines: \1/ last line of fold

                When would this be useful? I don't like adding a feature unless there is is a
                good example of how it will be used.

                > How will this text be highlighted? Using it's normal highlighting,
                > or a new Fold highlighting?

                Currently there is a highlight group for folded lines. This might be extended
                to several groups, for different kinds of folds.

                > Those who use numbering sacrifice 8 columns to do so, so I don't think
                > sacrificing two columns to use folding is unreasonable. You could
                > also use a number to mark the start of a fold, and a vertical bar to
                > mark the body.

                Then you can't see where a level 2 fold ends and a level 1 fold continues:

                1 fold level 1 starts here
                |
                2 /* fold level 2 starts here */
                | end of fold level 2
                | } this is in the level 1 fold again

                > This way, you still see the fold level when the fold
                > is closed. Maybe add a '\l' to the foldtext option.

                A closed fold could show the level somewhere. Perhaps using a number doesn't
                make it easy to see the structure though. I'll try out a few things.

                > Will you use the NonText highlight group for this column, or LineNr, or
                > create a new group?

                I don't know yet. It should probably be a new group.

                > What about navigation? Motion command to go to the start/end of the
                > current/next fold region. Use wrapscan when at start/end of file?
                >
                > char action in Normal mode
                > ----------------------------------------
                > [| cursor to N previous start of a fold region
                > ]| cursor to N next start of a fold region

                Moving to the start/end of a fold should be useful, since it defines some
                structure in the text. This can be added a bit later, first folding has to
                work properly.

                --
                hundred-and-one symptoms of being an internet addict:
                2. You kiss your girlfriend's home page.

                /-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
                \-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/
              • Stephen P. Wall
                ... source.c: int dosomething( int arg1, int arg2 ) { function body.... } Now fold everything from the initial int to the closing bracket. having just the
                Message 7 of 28 , Apr 12, 2000
                • 0 Attachment
                  > From: Bram Moolenaar <Bram@...>
                  > > Or a line number spec?
                  > >
                  > > 2/\(\S.*\)/+-- \f lines: \1/ 2nd line of fold
                  > > $/^\s*\(\S*\)/+-- \f lines: \1/ last line of fold
                  >
                  > When would this be useful? I don't like adding a feature unless there is is a
                  > good example of how it will be used.
                  >

                  source.c:

                  int
                  dosomething(
                  int arg1,
                  int arg2
                  )
                  {
                  function body....
                  }


                  Now fold everything from the initial int to the closing bracket.
                  having just the first line available to build your fold comment won't
                  help much, especially if you have a number of functions like this in
                  one file. Being able to grab the second or even the third and fourth
                  lines of the fold instead would be useful. I only included the '$'
                  for completeness.


                  > > ... You could
                  > > also use a number to mark the start of a fold, and a vertical bar to
                  > > mark the body.
                  >
                  > Then you can't see where a level 2 fold ends and a level 1 fold continues:
                  >
                  > 1 fold level 1 starts here
                  > |
                  > 2 /* fold level 2 starts here */
                  > | end of fold level 2
                  > | } this is in the level 1 fold again
                  >

                  Good point. Still needs thought/discussion I guess.

                  > Moving to the start/end of a fold should be useful, since it defines some
                  > structure in the text. This can be added a bit later, first folding has to
                  > work properly.

                  Agreed.

                  Have to say I'm looking forward to getting folding - sounds like a very
                  useful feature.

                  --
                  Free High Speed DSL Access:
                  http://in.winfire.com/s/isapiEng.dll/wf.exe?cmd=rl&452,180045277&wf.exe
                  ______________________________________________________________________
                  ________ ______
                  Stephen P. Wall Redcom Laboratories, Inc. / __ /\/ ___/\
                  Steve_Wall@... One Redcom Center ___/ /\/ /_/ /\__\/
                  (716) 924-7550 Victor, NY 14564 /_____/ /_______/ /
                  x300 USA \_____\/\_______\/
                • Zdenek Sekera
                  ... Excellent point! ... Can t wait, too.
                  Message 8 of 28 , Apr 12, 2000
                  • 0 Attachment
                    "Stephen P. Wall" wrote:
                    >
                    > > From: Bram Moolenaar <Bram@...>
                    > > > Or a line number spec?
                    > > >
                    > > > 2/\(\S.*\)/+-- \f lines: \1/ 2nd line of fold
                    > > > $/^\s*\(\S*\)/+-- \f lines: \1/ last line of fold
                    > >
                    > > When would this be useful? I don't like adding a feature unless there is is a
                    > > good example of how it will be used.
                    > >
                    >
                    > source.c:
                    >
                    > int
                    > dosomething(
                    > int arg1,
                    > int arg2
                    > )
                    > {
                    > function body....
                    > }
                    >
                    > Now fold everything from the initial int to the closing bracket.
                    > having just the first line available to build your fold comment won't
                    > help much, especially if you have a number of functions like this in
                    > one file. Being able to grab the second or even the third and fourth
                    > lines of the fold instead would be useful. I only included the '$'
                    > for completeness.

                    Excellent point!

                    >
                    > Have to say I'm looking forward to getting folding - sounds like a very
                    > useful feature.

                    Can't wait, too.

                    ---Zdenek
                  • Bram Moolenaar
                    ... Well, but the function could just as well start with int dosomething( or static int dosomething( Thus blindly taking the second line isn t very reliable.
                    Message 9 of 28 , Apr 12, 2000
                    • 0 Attachment
                      Stephen P. Wall wrote:

                      > int
                      > dosomething(
                      > int arg1,
                      > int arg2
                      > )
                      > {
                      > function body....
                      > }
                      >
                      >
                      > Now fold everything from the initial int to the closing bracket.
                      > having just the first line available to build your fold comment won't
                      > help much, especially if you have a number of functions like this in
                      > one file. Being able to grab the second or even the third and fourth
                      > lines of the fold instead would be useful. I only included the '$'
                      > for completeness.

                      Well, but the function could just as well start with

                      int dosomething(
                      or
                      static
                      int
                      dosomething(

                      Thus blindly taking the second line isn't very reliable. The regexp should be
                      able to catch it. Assuming multi-line regexp has been implemented, this
                      displays the word before the first "(" in the fold:

                      /\([^(]\|\n\)*\(\<\k\+\s*\)(/function \2

                      --
                      hundred-and-one symptoms of being an internet addict:
                      12. You turn off your modem and get this awful empty feeling, like you just
                      pulled the plug on a loved one.

                      /-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
                      \-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/
                    • Robert Webb
                      ... Maybe lower case z ? I know it already prefixes some other commands, but I don t think there are that many, and zf is free :-) z still looks folded,
                      Message 10 of 28 , Apr 12, 2000
                      • 0 Attachment
                        > I know using "Z" is a bit dangerous, but couldn't think of another good
                        > choice. Looking at the "Z" character as something folded is indeed a nice
                        > one.

                        Maybe lower case "z"? I know it already prefixes some other commands, but I
                        don't think there are that many, and "zf" is free :-) "z" still looks
                        folded, but is not as dangerous.

                        Rob.
                      • Robert Webb
                        ... Hmm. Maybe if you could specify one or more lines from within the fold that still get displayed when the fold is closed, which act like an abbreviation
                        Message 11 of 28 , Apr 16, 2000
                        • 0 Attachment
                          Bram wrote:

                          > It's near to impossible to decide if a comment belongs to the
                          > following fold
                          > or not. There is no other practical choice than to leave it
                          > open, or make a
                          > separate fold out of it. Preprocessor lines are also often a
                          > problem. That's
                          > why manually specifying the folds is quite useful.

                          Hmm. Maybe if you could specify one or more lines from within the fold that
                          still get displayed when the fold is closed, which act like an abbreviation
                          for the whole folded text. Then the fold could go from the comment before
                          the function to the end of the function, and when folded you could just see
                          the function heading without the preceding comment or the following function
                          body. Does this sound doable? Is it too far from "standard" folding, if
                          there is such a thing? Does it matter?

                          Would certainly be nice if the comment before the function could be part of
                          the function's fold. Indeed the function heading itself should kind of be
                          part of the fold, even if it is the part that is still displayed when the
                          fold is closed, so you can just grab the whole thing easily and move it
                          around.

                          > My experience is that you would mostly enter the file with all folds
                          > closed, so
                          > that you can easily navigate to the line you are looking for.

                          Hopefully there'll be an option to always start with all folds open. Then
                          when you edit a file you just see the file as it is, and may choose to use
                          folding if necessary.

                          Rob.
                        • raf
                          ... yes, but an autocommand could create folds upon loading a file according to patterns so a default folded state can easily be achieved. raf
                          Message 12 of 28 , Apr 16, 2000
                          • 0 Attachment
                            Vince Negri wrote:

                            > > I would prefer using a .fold file (or similar) to storing folding info in
                            > .viminfo for these reasons:
                            >
                            > 1) It prevents you having to make a compromise between the number
                            > of files whose folding state is saved and the size of .viminfo file
                            > 2) It makes it easier to transfer a 'convenient' folding state to another
                            > user for a given file (e.g. "Here's the file I was talking about Bert, I've
                            > also folded out the less relevant parts.")
                            >
                            > P.S. Having spoken to a E***s user it appears that the only way of
                            > having persistent folds in that editor is by embedded comments. Otherwise
                            > the folds vanish the next time you open the file.

                            yes, but an autocommand could create folds upon loading a file according
                            to patterns so a default folded state can easily be achieved.

                            raf
                          • Bram Moolenaar
                            ... It s possible, but the question is if we can make it reliable enough to be useful. If you use source code like Vim has, it s mostly structured nicely,
                            Message 13 of 28 , Apr 17, 2000
                            • 0 Attachment
                              Robert Webb wrote:

                              > > It's near to impossible to decide if a comment belongs to the following
                              > > fold or not. There is no other practical choice than to leave it open, or
                              > > make a separate fold out of it. Preprocessor lines are also often a
                              > > problem. That's why manually specifying the folds is quite useful.
                              >
                              > Hmm. Maybe if you could specify one or more lines from within the fold that
                              > still get displayed when the fold is closed, which act like an abbreviation
                              > for the whole folded text. Then the fold could go from the comment before
                              > the function to the end of the function, and when folded you could just see
                              > the function heading without the preceding comment or the following function
                              > body. Does this sound doable? Is it too far from "standard" folding, if
                              > there is such a thing? Does it matter?

                              It's possible, but the question is if we can make it reliable enough to be
                              useful. If you use source code like Vim has, it's mostly structured nicely,
                              with one comment block before the function. However, sometimes the comment is
                              broken in parts. Example (short version of what's in normal.c):

                              /*
                              * normal
                              * [lots of text here...]
                              */
                              /*ARGSUSED*/
                              void
                              normal_cmd(...)

                              The /*ARGSUSED*/ is technically the comment just before the function. But
                              obviously this situation must be detected and the comment before this included
                              in the fold. There are less obvious situations where there are two comments
                              before the function.

                              Also note that the name of the function doesn't match with the one in the
                              comment. For the fold you probably want to use the real function name, not
                              the one from the comment.

                              Preprocessor lines also get in the way. How to catch this situation (from
                              tag.c):

                              static int
                              #ifdef EMACS_TAGS
                              test_for_current(is_etag, fname, fname_end, tag_fname)
                              int is_etag;
                              #else
                              test_for_current(fname, fname_end, tag_fname)
                              #endif
                              char_u *fname;
                              char_u *fname_end;

                              To the human reader it's clear that this is the same function with two
                              different argument lists. But how to make an automatic detection for this?
                              Also take into account that you don't want to get new problems with function
                              prototypes. That probably has to be detected by the missing {} block.

                              Well, this has to be done anyway, for the situations where you don't want to
                              add markers to your file. But it shows that adding markers does help to
                              improve the "foldability" of a file.

                              I have tried using a few different kinds of folding, and quickly discovered
                              that the practical use is limited. Mostly because the folds don't include the
                              right text areas. When the folds cannot be defined precisely folding isn't
                              very useful.

                              > Would certainly be nice if the comment before the function could be part of
                              > the function's fold. Indeed the function heading itself should kind of be
                              > part of the fold, even if it is the part that is still displayed when the
                              > fold is closed, so you can just grab the whole thing easily and move it
                              > around.

                              The best is when you can fold the whole function, including the leading
                              comment and preprocessor lines that belong to it. It would show the function
                              name in the folded line. Then you can do "dd" on this line and "p"ut it
                              somewhere else. Only when the fold was defined properly can you do this
                              without fear of breaking your code.

                              > > My experience is that you would mostly enter the file with all folds
                              > > closed, so that you can easily navigate to the line you are looking for.
                              >
                              > Hopefully there'll be an option to always start with all folds open. Then
                              > when you edit a file you just see the file as it is, and may choose to use
                              > folding if necessary.

                              Yes, that will be an option. Hopefully we can come up with a minimal set of
                              options. Folding tends to add a lot of different ways of working. I don't
                              want to add too many new commands and options. Not only because it makes Vim
                              bigger, but also because the user will have to spend more time making the
                              right choice.

                              --
                              hundred-and-one symptoms of being an internet addict:
                              62. If your doorbell rings, you think hat new mail has arrived. And then
                              you're disappointed that it's only someone at the door.

                              /-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
                              \-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/
                            • Ives Aerts
                              ... Maybe we are all too focused on folding away function definitions? The times that I found folding practical was when I wanted to selectively edit parts of
                              Message 14 of 28 , Apr 17, 2000
                              • 0 Attachment
                                On Mon, Apr 17, 2000 at 10:16:18AM +0200, Bram Moolenaar wrote:
                                > I have tried using a few different kinds of folding, and quickly
                                > discovered that the practical use is limited.

                                Maybe we are all too focused on folding away function definitions?

                                The times that I found folding practical was when I wanted to
                                selectively edit parts of a file. I.e.: fold away all lines that
                                matched a certain criteria and then do a global editing operation on
                                the remaining lines without affecting those that were folded away.

                                Quite useful, and certainly without any need for folds that remain
                                active across editing sessions.

                                Cheers,
                                -Ives
                                ______________________________________________________________________
                                Ives Aerts (Senior R&D engineer) Sony Digital Media Europe
                                Ives.Aerts@... St.Stevens Woluwestr. 55
                                `A mathematician is a machine for turning B-1130 Brussels, Belgium
                                coffee into theorems.' PHONE : +32 2 724 86 11
                                (Paul Erdos) FAX : +32 2 724 86 88
                              • Dr. Charles E. Campbell
                                ... /* Crazy.c */ #include #define OPENFUNC { #define CLOSEFUNC } #define STARTCMMNT /##* #define STOPCMMNT *##/ STARTCMMNT yeah, this is a
                                Message 15 of 28 , Apr 17, 2000
                                • 0 Attachment
                                  Thus saith Bram Moolenaar:
                                  > Preprocessor lines are also often a problem...
                                  > It's possible, but the question is if we can make it reliable enough to be
                                  > useful.

                                  Nah! Preprocessor != reliability. Try the following function on for size:

                                  ---------------------------------------------------------------------
                                  /* Crazy.c */
                                  #include <stdio.h>

                                  #define OPENFUNC {
                                  #define CLOSEFUNC }
                                  #define STARTCMMNT /##*
                                  #define STOPCMMNT *##/

                                  STARTCMMNT yeah, this is a comment, believe it or not!
                                  Maybe I should put those lovely #defines
                                  into a header file, too...
                                  STOPCMMNT
                                  int main()
                                  OPENFUNC
                                  printf("Hello, crazy world!\n");
                                  CLOSEFUNC
                                  ---------------------------------------------------------------------

                                  Regards,
                                  Dr C

                                  --
                                  Charles E Campbell, Jr, PhD _ __ __
                                  Goddard Space Flight Center / /_/\_\_/ /
                                  cec@... /_/ \/_//_/
                                  PGP public key: http://www.erols.com/astronaut/pgp.html/
                                • Bram Moolenaar
                                  ... I won t deny this is useful. But you can already use the :g and :v commands to do this. You can t directly see which lines they will work on, but the
                                  Message 16 of 28 , Apr 17, 2000
                                  • 0 Attachment
                                    Ives Aerts wrote:

                                    > Maybe we are all too focused on folding away function definitions?
                                    >
                                    > The times that I found folding practical was when I wanted to
                                    > selectively edit parts of a file. I.e.: fold away all lines that
                                    > matched a certain criteria and then do a global editing operation on
                                    > the remaining lines without affecting those that were folded away.
                                    >
                                    > Quite useful, and certainly without any need for folds that remain
                                    > active across editing sessions.

                                    I won't deny this is useful. But you can already use the ":g" and ":v"
                                    commands to do this. You can't directly see which lines they will work on,
                                    but the functionality for the change is already there.

                                    When folds are defined in another way, performing a command on folded or not
                                    folded lines would be useful. It's quite easy to add a command like ":onfold
                                    cmd" to execute "cmd" on every folded line. Would work like ":g". Perhaps
                                    ":onfold!" can be used to execute "cmd" on every not-folded line.

                                    --
                                    hundred-and-one symptoms of being an internet addict:
                                    64. The remote to the T.V. is missing...and you don't even care.

                                    /-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
                                    \-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/
                                  • Bram Moolenaar
                                    ... OK, you proved you can think of crazy preprocessor use! But I suppose you wrote this as an example. I wonder what actually appears in files people use.
                                    Message 17 of 28 , Apr 17, 2000
                                    • 0 Attachment
                                      Charles Campbell wrote:
                                      > Thus saith Bram Moolenaar:
                                      > > Preprocessor lines are also often a problem...
                                      > > It's possible, but the question is if we can make it reliable enough to be
                                      > > useful.
                                      >
                                      > Nah! Preprocessor != reliability. Try the following function on for size:

                                      OK, you proved you can think of crazy preprocessor use!

                                      But I suppose you wrote this as an example. I wonder what actually appears in
                                      files people use. MS-Windows code looks quite funny sometimes. Then the
                                      question is for how many files a function-recognition algorithm still works
                                      good enough without becoming very complex.

                                      --
                                      hundred-and-one symptoms of being an internet addict:
                                      67. Your hard drive crashes. You haven't logged in for two hours. You start
                                      to twitch. You pick up the phone and manually dial your ISP's access
                                      number. You try to hum to communicate with the modem. You succeed.

                                      /-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
                                      \-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/
                                    • Edward S. Hirgelt
                                      ... From: Bram Moolenaar To: Dr. Charles E. Campbell Cc: VimDev Sent: Monday, April
                                      Message 18 of 28 , Apr 17, 2000
                                      • 0 Attachment
                                        ----- Original Message -----
                                        From: "Bram Moolenaar" <Bram@...>
                                        To: "Dr. Charles E. Campbell" <cec@...>
                                        Cc: "VimDev" <vim-dev@...>
                                        Sent: Monday, April 17, 2000 13:45
                                        Subject: Re: [vimdev] Folding thoughts


                                        > OK, you proved you can think of crazy preprocessor use!

                                        Not surprisingly, this crazy use isn't that farfetched. The original source
                                        to the Unix adb debugger was written in C with preprocessor definitions that
                                        made it look surprisingly like ALGOL (BEGIN, END, etc). A lot of generated
                                        code (IDL compilers, etc) produce highly stylized code as well. Perhaps not
                                        to this extent...

                                        Ed
                                        ----
                                        Edward S. Hirgelt
                                        Classified Ventures, Inc
                                        126 Woodland Way
                                        Piedmont, Ca 94611
                                      • Ives Aerts
                                        ... Sure, but there the criteria needs to be a single regular expression. In my folding example I often used a series of commands, including manually folding
                                        Message 19 of 28 , Apr 18, 2000
                                        • 0 Attachment
                                          On Mon, Apr 17, 2000 at 10:45:37PM +0200, Bram Moolenaar wrote:
                                          > > I.e.: fold away all lines that matched a certain criteria and then
                                          > > do a global editing operation on the remaining lines without
                                          > > affecting those that were folded away.
                                          >
                                          > I won't deny this is useful. But you can already use the ":g" and
                                          > ":v" commands to do this. You can't directly see which lines they
                                          > will work on, but the functionality for the change is already there.

                                          Sure, but there the 'criteria' needs to be a single regular
                                          expression. In my folding example I often used a series of commands,
                                          including manually folding away certain parts. (and as you said: it's
                                          comforting to see in advance which lines are going to be affected by
                                          the operation).

                                          Anyway, it was just a small reminder that function definitions are not
                                          the only practical application of folds...

                                          Cheers,
                                          -Ives
                                          ______________________________________________________________________
                                          Ives Aerts (Senior R&D engineer) Sony Digital Media Europe
                                          Ives.Aerts@... St.Stevens Woluwestr. 55
                                          `Disraeli was pretty close: actually, there B-1130 Brussels, Belgium
                                          are lies, damn lies, statistics, bench- PHONE : +32 2 724 86 11
                                          marks, and delivery dates.' FAX : +32 2 724 86 88
                                        • Rahul Joshi
                                          Hi, Actually i asked this on vim user s list. We cannot write a regexp to match nested comments or nested parantheses (eg in a search pattern) but vim s syntax
                                          Message 20 of 28 , Apr 19, 2000
                                          • 0 Attachment
                                            Hi,

                                            Actually i asked this on vim user's list.

                                            We cannot write a regexp to match nested comments
                                            or nested parantheses (eg in a search pattern)
                                            but vim's syntax highlighting is more intelligent.

                                            It can hightlight nested comments.

                                            syntax region Comment start=/\/\*/ end=/\*\// \
                                            contains=Comment

                                            I was just thinking if we could use a similar
                                            thing for folding wherein we can have nested folds for
                                            nested structures. Eg. nested { } brackets.
                                            (if we assume that nested folding will be supported)

                                            so that we can fully fold a function - one fold per
                                            each pair of { }.

                                            regards.

                                            __________________________________________________
                                            Do You Yahoo!?
                                            Send online invitations with Yahoo! Invites.
                                            http://invites.yahoo.com
                                          Your message has been successfully submitted and would be delivered to recipients shortly.