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

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

Expand Messages
  • 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 1 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.