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

RE: Folding thoughts

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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.