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

Re: showbreak extension - variable indent [ "done" ]

Expand Messages
  • Vaclav Smilauer
    This is the definitive version for breakindent. Everything I tried worked as expected (that is, visuals, edition, motion). Please someone competent, review the
    Message 1 of 13 , Aug 17, 2004
    • 0 Attachment
      This is the definitive version for breakindent. Everything I tried
      worked as expected (that is, visuals, edition, motion). Please someone
      competent, review the documentation and/or coding; release it so that
      people can test it and report bugs.

      By default, it is off.

      Hope this mailing list is not a black hole for patches... seems rather
      abandoned right now.

      Best regards, Vaclav
    • Benji Fisher
      ... It seems that Bram Moolenaar is on vacation at the moment. New patches are not likely to be made official until he gets back, but you might get a few
      Message 2 of 13 , Aug 17, 2004
      • 0 Attachment
        On Tue, Aug 17, 2004 at 11:47:32AM +0200, Vaclav Smilauer wrote:
        > This is the definitive version for breakindent. Everything I tried
        > worked as expected (that is, visuals, edition, motion). Please someone
        > competent, review the documentation and/or coding; release it so that
        > people can test it and report bugs.
        >
        > By default, it is off.
        >
        > Hope this mailing list is not a black hole for patches... seems rather
        > abandoned right now.
        >
        > Best regards, Vaclav

        It seems that Bram Moolenaar is on vacation at the moment. New
        patches are not likely to be made official until he gets back, but you
        might get a few volunteers to test it (sorry, not me in the foreseeable
        future). When Bram does get back, he will probably work through the
        accumulated mail on these lists; give him some time.

        HTH --Benji Fisher
      • Vaclav Smilauer
        Just to prove my stupidity: please remove this line from the patch. Or gcc will yell. +# undef BRI_MIN VS
        Message 3 of 13 , Aug 17, 2004
        • 0 Attachment
          Just to prove my stupidity: please remove this line from the patch. Or
          gcc will yell.

          +# undef BRI_MIN

          VS
        • Brandt, Servatius
          ... Vaclav - Usually I have columns set to 80 and don t type more than 80 characters per line, so there are no wrapping lines. But sometimes I switch on
          Message 4 of 13 , Aug 19, 2004
          • 0 Attachment
            Vaclav Smilauer wrote:

            > This is the definitive version for breakindent. Everything I tried
            > worked as expected (that is, visuals, edition, motion). Please someone

            > competent, review the documentation and/or coding; release it so that
            > people can test it and report bugs.
            >
            > By default, it is off.

            Vaclav -

            Usually I have 'columns' set to 80 and don't type more than 80
            characters per line, so there are no wrapping lines. But sometimes
            I switch on 'number', and then lines longer than 72 characters wrap. So
            your patch will be useful for me. It just needs a few minor changes
            because it doesn't fit well when "n" is not in 'cpoptions'.

            To see what I'm talking about use a color scheme with different
            highlight settings for the "Normal", "NonText", and "LineNr" highlight
            groups and try the following settings:

            :se nonu nolbr sbr=>
            :se nonu lbr sbr=>\
            :se nu nolbr sbr=\ \ \ \ \ \ \ > cpo+=n
            :se nu lbr sbr=\ \ \ \ \ \ >\ cpo+=n

            The last two settings look best when "NonText" and "LineNr" use
            different foreground colors but the same background color. For the
            highlighting see ":help :highlight" and ":help higlight-groups".

            You should make the following changes:

            1) When 'cpoptions' contains "n", add your extra spaces AFTER
            the 'showbreak' string, not before it.

            2) For consistency, do so also when 'cpoptions' does not
            contain "n".

            3) Display your extra spaces with the "NonText" highlight
            attribute.

            1) is mandatory to work well with ":set nu cpo+=n", 2) makes it easier
            to implement and to understand, and 3) makes clear where the real text
            begins even if 2) causes a single-letter 'showbreak' value being
            displayed at the left margin of the screen. Note that the 'showbreak'
            value is displayed as "NonText" as well.

            Thanks for the nice idea and implementing this.

            - Servatius


            ------------------------------------------------------------------------
            Servatius Brandt Phone: +49 89 636-41504
            Fujitsu Siemens Computers Fax: +49 89 636-48716
            EP SW AD C++ Email: Servatius.Brandt@...
          • Vaclav Smilauer
            Hi, ... In c code for example, sometimes I change nest level and consequently all hard linebreaks are wrong (many lines longer than 80...). ... Hmm, I see. I
            Message 5 of 13 , Aug 19, 2004
            • 0 Attachment
              Hi,

              >Vaclav -
              >
              >Usually I have 'columns' set to 80 and don't type more than 80
              >characters per line, so there are no wrapping lines.
              >
              In c code for example, sometimes I change nest level and consequently
              all hard linebreaks are wrong (many lines longer than 80...).

              >I switch on 'number', and then lines longer than 72 characters wrap. So
              >your patch will be useful for me. It just needs a few minor changes
              >because it doesn't fit well when "n" is not in 'cpoptions'.
              >
              >
              Hmm, I see. I did not know there was such a feature (don't understand
              well its purpose, whatever...), shoudn't be hard.

              >To see what I'm talking about use a color scheme with different
              >highlight settings for the "Normal", "NonText", and "LineNr" highlight
              >groups and try the following settings:
              >
              > :se nonu nolbr sbr=>
              > :se nonu lbr sbr=>\
              > :se nu nolbr sbr=\ \ \ \ \ \ \ > cpo+=n
              > :se nu lbr sbr=\ \ \ \ \ \ >\ cpo+=n
              >
              >The last two settings look best when "NonText" and "LineNr" use
              >different foreground colors but the same background color. For the
              >highlighting see ":help :highlight" and ":help higlight-groups".
              >
              >
              Originally, the breakindent spaces were highlighted the same as
              showbreak, but I thought that having stripes marking the broken line
              from the very left somewhat defeated the purpose of the feature (I have
              the evening color scheme, btw): to have the indentation structure
              visible in the most clean manner possible. With the current highlight,
              blocks stand out very clearly (rectangularly... :-) )

              This change is trivial but I doubt its usefulness. Anyone else comments
              on this?

              My idea is having showbreak doing what it should (showing the break) and
              breakdindent also (indenting the break, not showing it, which is already
              handled by showbreak). Using breakindent alone can be confusing (you
              don't see what is wrapped and what are newlines).

              > <>
              > You should make the following changes:
              >
              > 1) When 'cpoptions' contains "n", add your extra spaces AFTER
              > the 'showbreak' string, not before it.

              > <> 2) For consistency, do so also when 'cpoptions' does not
              > contain "n".
              >
              > 3) Display your extra spaces with the "NonText" highlight
              > attribute.
              >
              > 1) is mandatory to work well with ":set nu cpo+=n", 2) makes it easier
              > to implement and to understand, and 3) makes clear where the real text
              > begins even if 2) causes a single-letter 'showbreak' value being
              > displayed at the left margin of the screen. Note that the 'showbreak'
              > value is displayed as "NonText" as well.
              >
              > Thanks for the nice idea and implementing this.
              >
              > - Servatius

              Thanks for your testing and suggestions! I still think that you see the
              purpose of breakindent differently from me, hence you insist on 1)
              (after showbreak) which for me does not make any sense.

              Regards, Vaclav
            • Brandt, Servatius
              ... That s absolutely ok, people work differently. That s why options are useful. ... So ... A few years ago (I don t remember the Vim version), the
              Message 6 of 13 , Aug 20, 2004
              • 0 Attachment
                Vaclav Smilauer wrote:

                > >Usually I have 'columns' set to 80 and don't type more than 80
                > >characters per line, so there are no wrapping lines.
                > >
                > In c code for example, sometimes I change nest level and consequently
                > all hard linebreaks are wrong (many lines longer than 80...).

                That's absolutely ok, people work differently. That's why options are
                useful.

                > >I switch on 'number', and then lines longer than 72 characters wrap.
                So
                > >your patch will be useful for me. It just needs a few minor changes
                > >because it doesn't fit well when "n" is not in 'cpoptions'.
                > >
                > >
                > Hmm, I see. I did not know there was such a feature (don't understand
                > well its purpose, whatever...), shoudn't be hard.

                A few years ago (I don't remember the Vim version), the 'showbreak'
                value was always displayed at the left margin of the screen, but this
                looked ugly when 'showbreak' was set to a single character like ">" and
                'number' was on. So Bram changed the default behaviour: the 'showbreak'
                value is now displayed after the 'number' column. This was very
                reasonable because most people will just set 'showbreak' to ">" once in
                their .vimrc, but may enter the ":set number" or ":set nonumber"
                commands various times in their editing session.

                On the other hand, a 'showbreak' value of eight characters (for instance
                seven spaces and one ">") when 'number' is set looks much better with
                the old behaviour: this embeds the 'showbreak' value in the 'number'
                field. For that reason, Bram introduced the "n" switch in 'cpoptions'
                when he changed the default behaviour (see ":help cpo-n").

                Note that this requires setting 'showbreak' to the eight-character value
                simultaneously when switching on 'number' and setting 'showbreak' to the
                single charcater ">" when switching off 'number'. But if you write
                a toggle function for these settings and map it to a key, this is very
                convenient. When using 'number' and also 'linebreak', I even use
                a 'showbreak' value of six spaces plus ">" plus another space as this
                increases readability beyond that what 'linebreak' already does. The
                different 'showbreak' value reminds me also that 'linebreak' is set.

                > >To see what I'm talking about use a color scheme with different
                > >highlight settings for the "Normal", "NonText", and "LineNr"
                highlight
                > >groups and try the following settings:
                > >
                > > :se nonu nolbr sbr=>
                > > :se nonu lbr sbr=>\
                > > :se nu nolbr sbr=\ \ \ \ \ \ \ > cpo+=n
                > > :se nu lbr sbr=\ \ \ \ \ \ >\ cpo+=n
                > >
                > >The last two settings look best when "NonText" and "LineNr" use
                > >different foreground colors but the same background color. For the
                > >highlighting see ":help :highlight" and ":help higlight-groups".
                > >
                > >
                > Originally, the breakindent spaces were highlighted the same as
                > showbreak, but I thought that having stripes marking the broken line
                > from the very left somewhat defeated the purpose of the feature (I
                have
                > the evening color scheme, btw): to have the indentation structure
                > visible in the most clean manner possible. With the current highlight,

                > blocks stand out very clearly (rectangularly... :-) )
                >
                > This change is trivial but I doubt its usefulness. Anyone else
                comments
                > on this?

                I agree with you that displaying the indenting spaces in the same color
                like normal text looks better - for me. But other people may have
                a different opinion. These characters don't actually belong to the
                text, so displaying them with "Normal" highlighting is misleading. My
                critics is against FORCING users to display the non-text characters as
                text, not against the possibility to do so. If you use the "NonText"
                highlighting for the indent spaces, you can assign the same background
                color you use for "Normal" also to "NonText" in order to avoid the
                stripes. But this has the disadvantage that the 'showbreak' character
                is affected as well (since it uses "NonText", too). So maybe we need
                more flexibility and have to introduce an extra "BreakIndent" highlight
                group for the 'breakindent' spaces.

                I don't say that doing all this is mandatory, the decision whether to
                accept highlighting the extra spaces as "Normal" will be up to Bram.
                I just want to prepare you that there is the possibility that things may
                get changed to match using habits of other Vim users.

                > My idea is having showbreak doing what it should (showing the break)
                and
                > breakdindent also (indenting the break, not showing it, which is
                already
                > handled by showbreak).

                In my opinion, having 'breakindent' indenting the line continuation
                AFTER the 'showbreak' character(s) makes more sense. This makes this
                option also independent on 'showbreak': it works also when 'showbreak'
                is set to an empty string. Confusion of the indent spaces and spaces
                really in the text can be avoided by using the "NonText" or a new
                "BreakIndent" highlighting group for 'breakindent'.

                When 'showbreak' is non-empty, this fulfills also better what you
                described the purpose of the feature (quote): "to have the indentation
                structure visible in the most clean manner possible". You would get

                |if expr
                | long line ...
                |>___continuation
                |endif

                instead of

                |if expr
                | long line ...
                |____>continuation
                |endif

                (I used "|" for the screen margin on the left, "_" means an indenting
                space not in the text, and ">" is the 'showbreak' character). Note that
                my suggestion means that the length of the 'showbreak' character has to
                be taken into account when computing the number of indenting spaces to
                be used (three instead of four here).


                > Using breakindent alone can be confusing (you
                > don't see what is wrapped and what are newlines).

                "alone" here means with an empty value for 'showbreak'. This is true,
                but nothing new. It's even the default of that option (for VI
                compatibility). By the way, there is no confusion with an empty value
                of 'showbreak' if you have 'number' set.

                > > You should make the following changes:
                > >
                > > 1) When 'cpoptions' contains "n", add your extra spaces AFTER
                > > the 'showbreak' string, not before it.
                >
                > > 2) For consistency, do so also when 'cpoptions' does not
                > > contain "n".
                > >
                > > 3) Display your extra spaces with the "NonText" highlight
                > > attribute.
                > >
                > > 1) is mandatory to work well with ":set nu cpo+=n", 2) makes it
                easier
                > > to implement and to understand, and 3) makes clear where the real
                text
                > > begins even if 2) causes a single-letter 'showbreak' value being
                > > displayed at the left margin of the screen. Note that the
                'showbreak'
                > > value is displayed as "NonText" as well.
                > >
                > > Thanks for the nice idea and implementing this.
                > >
                > > - Servatius
                >
                > Thanks for your testing and suggestions! I still think that you see
                the
                > purpose of breakindent differently from me, hence you insist on 1)
                > (after showbreak) which for me does not make any sense.

                No, 1) is a must. The "n" flag in 'cpoption' means that the 'showbreak'
                column is the same as the 'number' column (although the documentation is
                a bit weak because the idea of having 'breakindent' was not in mind when
                the "n" flag was documented). If you insert the indenting spaces in
                front
                of the 'showbreak' value if 'cpo' contains "n" you punish people who
                embed an eight-character 'showbreak' string in the eight-character wide
                'number' field.

                If I see the purpose of 'breakindent' a bit differenly from you, then
                this is because of 2) and the additional arguments I gave in this post.

                Anyway, this will be a nice option, and I'm sure that Bram will make the
                right decision about the details. Just wait a few months until he is
                back from holidays and see what happens.

                - Servatius


                ------------------------------------------------------------------------
                Servatius Brandt Phone: +49 89 636-41504
                Fujitsu Siemens Computers Fax: +49 89 636-48716
                EP SW AD C++ Email: Servatius.Brandt@...
              • Vaclav Smilauer
                ... Just this one for now: sub 1) I actually meant just the part whether breakindent should come before or after showbreak. Yes, clearly, if cpo has n, its
                Message 7 of 13 , Aug 20, 2004
                • 0 Attachment
                  > > Thanks for your testing and suggestions! I still think that you see
                  > the
                  > > purpose of breakindent differently from me, hence you insist on 1)
                  > > (after showbreak) which for me does not make any sense.
                  >
                  > No, 1) is a must. The "n" flag in 'cpoption' means that the 'showbreak'
                  > column is the same as the 'number' column (although the documentation is
                  > a bit weak because the idea of having 'breakindent' was not in mind when
                  > the "n" flag was documented). If you insert the indenting spaces in
                  > front
                  > of the 'showbreak' value if 'cpo' contains "n" you punish people who
                  > embed an eight-character 'showbreak' string in the eight-character wide
                  > 'number' field.

                  Just this one for now: sub 1) I actually meant just the part whether
                  breakindent should come before or after showbreak. Yes, clearly, if cpo
                  has n, its behaviour must change. I already "implemented" it (and made
                  the implementation generally cleaner) so that 8 spaces are added in such
                  case. Will send patch tonight. Incidentally, it also fixed bugs if
                  linebreak was on (have no idea why; see below).

                  BTW I don't understand though why this (i.e. breakindent) stuff has to
                  appear on two places: in charset.c and screen.c. Why does not screen
                  remember what is where, so that visual position <-> text position be
                  just matter of lookup in one array in BOTH directions? For now, if
                  things are no synchronized, one gets displayed cursor elsewhere than
                  characters are inserted, mouse selecting not under cursor and whole
                  bunch of different things. PITA.

                  Regards, Vaclav

                  PS Servatius, no need to cc to me, i'm subscribed to vim-dev.
                • Vaclav Smilauer
                  [quoting myself] ... This is not true. Linebreak is still broken and I have no idea neither how it works exactly nor how to fix it... On the last wrapped line,
                  Message 8 of 13 , Aug 28, 2004
                  • 0 Attachment
                    [quoting myself]

                    >Incidentally, it also fixed bugs if
                    >linebreak was on (have no idea why; see below).
                    >
                    >
                    This is not true. Linebreak is still broken and I have no idea neither
                    how it works exactly nor how to fix it... On the last wrapped line,
                    there is [breakindent-amount-for-the-current-line] characters wide gap:
                    cursor and visual selection is right (verify: select & paste) but the
                    text is off. If set 'nolinebreak' everything seems OK.

                    Ideas someone?

                    Vaclav Smilauer
                  • Bram Moolenaar
                    ... You probably need to pass the line number in all places where win_lbr_chartabsize() is used. ... What happens in a narrow window, that is narrower than the
                    Message 9 of 13 , Aug 31, 2004
                    • 0 Attachment
                      Vaclav Smilauer wrote:

                      > This is what I did this afternoon.
                      >
                      > One minor glitch is that in visual/incsearch mode, highlighting is
                      > horizontaly off from cursor by the indent-amount*wrapped-line-number.
                      > Pretty please, someone understanding screen.c have a look at it. I
                      > loosely copied it from showbreak but there must be something wrong.

                      You probably need to pass the line number in all places where
                      win_lbr_chartabsize() is used.

                      > I had to change the prototype of win_lbr_chartabsize, adding a fifth
                      > argument *linenr_T. However, if NULL, it behaves exactly the same. It
                      > needs to know the line number, because indent is not the same at every line.
                      >
                      > There is window-local boolean breakindent. Try it out, set showbreak=+,
                      > set breakindent, set linebreak. Example: open a c source code a squeeze
                      > the code: it is nice to see that indentation is preserved. (don't forget
                      > FEAT_LINEBREAK).
                      >
                      > Any feedback, testing or even improvements are welcome. At least for me,
                      > this is THE feature to be added to vim.

                      What happens in a narrow window, that is narrower than the amount of
                      indent? I would guess no text will be displayed at all, just indent.

                      I would actually prefer a bit more indent for a continuation line.
                      Somehow it also needs to be marked as a continuation line.

                      --
                      hundred-and-one symptoms of being an internet addict:
                      259. When you enter your name in the AltaVista search engine, the top ten
                      matches do indeed refer to you.

                      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                      /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                      \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                      \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                    • Vaclav Smilauer
                      This is the latest breakindent patch. Bram: 1. if window is too narrow, the indent is diminished as to keep at least 20 columns of text
                      Message 10 of 13 , Sep 5, 2004
                      • 0 Attachment
                        This is the latest breakindent patch.

                        Bram:

                        1. if window is too narrow, the indent is diminished as to keep at least
                        20 columns of text (misc1:get_breakindent_p_lnum(...)), window width
                        permitting (with or w/o 'number' and/or 'cpoptions' having 'n').

                        2. As to syntax highlighting, we had a discussion on that with
                        Servartius in this thread. It is up to you to decide whether to
                        highlight it as showbreak or as text (which I prefer for its visual
                        non-intrusiveness). If you want to have the indent a bit bigger (as you
                        mentioned in your post), there is showbreak. It is also up to you
                        whether to have showbreak before or after the indent or have it
                        configurable.

                        Linebreak does not work properly, please someone suggest a way to fix it.

                        Sincerely, Vaclav

                        >Vaclav Smilauer wrote:
                        >
                        >
                        >
                        >>>Usually I have 'columns' set to 80 and don't type more than 80
                        >>>characters per line, so there are no wrapping lines.
                        >>>
                        >>>
                        >>>
                        >>In c code for example, sometimes I change nest level and consequently
                        >>all hard linebreaks are wrong (many lines longer than 80...).
                        >>
                        >>
                        >
                        >That's absolutely ok, people work differently. That's why options are
                        >useful.
                        >
                        >
                        >
                        >>>I switch on 'number', and then lines longer than 72 characters wrap.
                        >>>
                        >>>
                        >So
                        >
                        >
                        >>>your patch will be useful for me. It just needs a few minor changes
                        >>>because it doesn't fit well when "n" is not in 'cpoptions'.
                        >>>
                        >>>
                        >>>
                        >>>
                        >>Hmm, I see. I did not know there was such a feature (don't understand
                        >>well its purpose, whatever...), shoudn't be hard.
                        >>
                        >>
                        >
                        >A few years ago (I don't remember the Vim version), the 'showbreak'
                        >value was always displayed at the left margin of the screen, but this
                        >looked ugly when 'showbreak' was set to a single character like ">" and
                        >'number' was on. So Bram changed the default behaviour: the 'showbreak'
                        >value is now displayed after the 'number' column. This was very
                        >reasonable because most people will just set 'showbreak' to ">" once in
                        >their .vimrc, but may enter the ":set number" or ":set nonumber"
                        >commands various times in their editing session.
                        >
                        >On the other hand, a 'showbreak' value of eight characters (for instance
                        >seven spaces and one ">") when 'number' is set looks much better with
                        >the old behaviour: this embeds the 'showbreak' value in the 'number'
                        >field. For that reason, Bram introduced the "n" switch in 'cpoptions'
                        >when he changed the default behaviour (see ":help cpo-n").
                        >
                        >Note that this requires setting 'showbreak' to the eight-character value
                        >simultaneously when switching on 'number' and setting 'showbreak' to the
                        >single charcater ">" when switching off 'number'. But if you write
                        >a toggle function for these settings and map it to a key, this is very
                        >convenient. When using 'number' and also 'linebreak', I even use
                        >a 'showbreak' value of six spaces plus ">" plus another space as this
                        >increases readability beyond that what 'linebreak' already does. The
                        >different 'showbreak' value reminds me also that 'linebreak' is set.
                        >
                        >
                        >
                        >>>To see what I'm talking about use a color scheme with different
                        >>>highlight settings for the "Normal", "NonText", and "LineNr"
                        >>>
                        >>>
                        >highlight
                        >
                        >
                        >>>groups and try the following settings:
                        >>>
                        >>> :se nonu nolbr sbr=>
                        >>> :se nonu lbr sbr=>\
                        >>> :se nu nolbr sbr=\ \ \ \ \ \ \ > cpo+=n
                        >>> :se nu lbr sbr=\ \ \ \ \ \ >\ cpo+=n
                        >>>
                        >>>The last two settings look best when "NonText" and "LineNr" use
                        >>>different foreground colors but the same background color. For the
                        >>>highlighting see ":help :highlight" and ":help higlight-groups".
                        >>>
                        >>>
                        >>>
                        >>>
                        >>Originally, the breakindent spaces were highlighted the same as
                        >>showbreak, but I thought that having stripes marking the broken line
                        >>from the very left somewhat defeated the purpose of the feature (I
                        >>
                        >>
                        >have
                        >
                        >
                        >>the evening color scheme, btw): to have the indentation structure
                        >>visible in the most clean manner possible. With the current highlight,
                        >>
                        >>
                        >
                        >
                        >
                        >>blocks stand out very clearly (rectangularly... :-) )
                        >>
                        >>This change is trivial but I doubt its usefulness. Anyone else
                        >>
                        >>
                        >comments
                        >
                        >
                        >>on this?
                        >>
                        >>
                        >
                        >I agree with you that displaying the indenting spaces in the same color
                        >like normal text looks better - for me. But other people may have
                        >a different opinion. These characters don't actually belong to the
                        >text, so displaying them with "Normal" highlighting is misleading. My
                        >critics is against FORCING users to display the non-text characters as
                        >text, not against the possibility to do so. If you use the "NonText"
                        >highlighting for the indent spaces, you can assign the same background
                        >color you use for "Normal" also to "NonText" in order to avoid the
                        >stripes. But this has the disadvantage that the 'showbreak' character
                        >is affected as well (since it uses "NonText", too). So maybe we need
                        >more flexibility and have to introduce an extra "BreakIndent" highlight
                        >group for the 'breakindent' spaces.
                        >
                        >I don't say that doing all this is mandatory, the decision whether to
                        >accept highlighting the extra spaces as "Normal" will be up to Bram.
                        >I just want to prepare you that there is the possibility that things may
                        >get changed to match using habits of other Vim users.
                        >
                        >
                        >
                        >>My idea is having showbreak doing what it should (showing the break)
                        >>
                        >>
                        >and
                        >
                        >
                        >>breakdindent also (indenting the break, not showing it, which is
                        >>
                        >>
                        >already
                        >
                        >
                        >>handled by showbreak).
                        >>
                        >>
                        >
                        >In my opinion, having 'breakindent' indenting the line continuation
                        >AFTER the 'showbreak' character(s) makes more sense. This makes this
                        >option also independent on 'showbreak': it works also when 'showbreak'
                        >is set to an empty string. Confusion of the indent spaces and spaces
                        >really in the text can be avoided by using the "NonText" or a new
                        >"BreakIndent" highlighting group for 'breakindent'.
                        >
                        >When 'showbreak' is non-empty, this fulfills also better what you
                        >described the purpose of the feature (quote): "to have the indentation
                        >structure visible in the most clean manner possible". You would get
                        >
                        > |if expr
                        > | long line ...
                        > |>___continuation
                        > |endif
                        >
                        >instead of
                        >
                        > |if expr
                        > | long line ...
                        > |____>continuation
                        > |endif
                        >
                        >(I used "|" for the screen margin on the left, "_" means an indenting
                        >space not in the text, and ">" is the 'showbreak' character). Note that
                        >my suggestion means that the length of the 'showbreak' character has to
                        >be taken into account when computing the number of indenting spaces to
                        >be used (three instead of four here).
                        >
                        >
                        >
                        >
                        >>Using breakindent alone can be confusing (you
                        >>don't see what is wrapped and what are newlines).
                        >>
                        >>
                        >
                        >"alone" here means with an empty value for 'showbreak'. This is true,
                        >but nothing new. It's even the default of that option (for VI
                        >compatibility). By the way, there is no confusion with an empty value
                        >of 'showbreak' if you have 'number' set.
                        >
                        >
                        >
                        >>>You should make the following changes:
                        >>>
                        >>>1) When 'cpoptions' contains "n", add your extra spaces AFTER
                        >>>the 'showbreak' string, not before it.
                        >>>
                        >>>
                        >>>2) For consistency, do so also when 'cpoptions' does not
                        >>>contain "n".
                        >>>
                        >>>3) Display your extra spaces with the "NonText" highlight
                        >>>attribute.
                        >>>
                        >>>1) is mandatory to work well with ":set nu cpo+=n", 2) makes it
                        >>>
                        >>>
                        >easier
                        >
                        >
                        >>>to implement and to understand, and 3) makes clear where the real
                        >>>
                        >>>
                        >text
                        >
                        >
                        >>>begins even if 2) causes a single-letter 'showbreak' value being
                        >>>displayed at the left margin of the screen. Note that the
                        >>>
                        >>>
                        >'showbreak'
                        >
                        >
                        >>>value is displayed as "NonText" as well.
                        >>>
                        >>>Thanks for the nice idea and implementing this.
                        >>>
                        >>>- Servatius
                        >>>
                        >>>
                        >>Thanks for your testing and suggestions! I still think that you see
                        >>
                        >>
                        >the
                        >
                        >
                        >>purpose of breakindent differently from me, hence you insist on 1)
                        >>(after showbreak) which for me does not make any sense.
                        >>
                        >>
                        >
                        >No, 1) is a must. The "n" flag in 'cpoption' means that the 'showbreak'
                        >column is the same as the 'number' column (although the documentation is
                        >a bit weak because the idea of having 'breakindent' was not in mind when
                        >the "n" flag was documented). If you insert the indenting spaces in
                        >front
                        >of the 'showbreak' value if 'cpo' contains "n" you punish people who
                        >embed an eight-character 'showbreak' string in the eight-character wide
                        >'number' field.
                        >
                        >If I see the purpose of 'breakindent' a bit differenly from you, then
                        >this is because of 2) and the additional arguments I gave in this post.
                        >
                        >Anyway, this will be a nice option, and I'm sure that Bram will make the
                        >right decision about the details. Just wait a few months until he is
                        >back from holidays and see what happens.
                        >
                        >- Servatius
                        >
                        >
                        >------------------------------------------------------------------------
                        >Servatius Brandt Phone: +49 89 636-41504
                        >Fujitsu Siemens Computers Fax: +49 89 636-48716
                        >EP SW AD C++ Email: Servatius.Brandt@...
                        >
                        >
                        >
                        >
                      Your message has been successfully submitted and would be delivered to recipients shortly.