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

showbreak extension - variable indent

Expand Messages
  • Vaclav Smilauer
    Hi vim developers, need you advice. I would like to implement the following reature in vim: currently, if wrapping is on, an indented line continues at the
    Message 1 of 13 , Aug 13, 2004
    • 0 Attachment
      Hi vim developers,

      need you advice. I would like to implement the following reature in vim:
      currently, if wrapping is on, an indented line continues at the very
      left, like this (_ = space, | = right window margin, showbreak = +):

      ________This is a very|
      +long line etc.

      What I want to do, is to insert space corresponding to the indent before
      every line, this way:

      ________This is a very|
      ________+long line etc.
      ____This line is also rat|
      ____+ther long...

      That makes wrapped indented (indent-structured) text much more readable
      (think of vimoutliner, source code &c).

      I would like to have some feedback from those who know well vim
      internals. There are at least 3 ways to implement it I know of.

      1. Have a special character in showbreak, say %, that would expand to
      spaces at the beginning of the current line (so, for the above,
      showbreak=%+). Pro: minimal changes to source, just replace
      STRLEN(p_sbr) by a function, taking the special into account. Contra:
      non-conceptual way (or are the other special characters? may we use
      <tab> which is disallowed anyway or whatever else?)

      2. Have a new variable, like showbreakindent. every occurence of p_sbr
      would have to be complemented by call to sbri() returning number of
      spaces for respective line. Pro: user-friendlier, more flexible. Contra:
      more changes to source, possible source of bugs.

      3. Have vim function (e.g. in syntax highlighting) calculate the space
      for every line. Pro: most flexible (think of parenthesized groups
      continuing below the corresponding parenthesis!). Contra: I have no
      know-how to take this approach; would eat up a lot of CPU?

      What would be the preferred way? Is this likely to be CPU intensive?
      Should it be a separate feature? Once functional, is it likely to be
      accepted to vim?

      Thanks for any comments.

      Vaclav
    • Vaclav Smilauer
      This is what I did this afternoon. One minor glitch is that in visual/incsearch mode, highlighting is horizontaly off from cursor by the
      Message 2 of 13 , Aug 16, 2004
      • 0 Attachment
        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.

        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.

        Vaclav Smilauer
      • Vaclav Smilauer
        Should have done make clean. Sorry for config.h in the patch. VS
        Message 3 of 13 , Aug 16, 2004
        • 0 Attachment
          Should have done make clean. Sorry for config.h in the patch. VS
        • 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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.