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

Re: Does 'man' syntax do its job?

Expand Messages
  • Charles E Campbell Jr
    ... Why would you expect that? Syntax highlighting is highlighting, not inline folding. Vim doesn t support inline folding. Vince Negri has provided a patch
    Message 1 of 8 , Jan 3, 2007
    • 0 Attachment
      Zvi Har'El wrote:

      >I tried to use view with the 'man' syntax, for example on the file vimtutor.man
      >obtained by
      >
      > GROFF_NO_SGR=y groff -Tascii -man $(man -w vimtutor) > vimtutor.man
      >
      >(see http://www.math.technion.ac.il/~rl/etc/vimtutor.man)
      >(this is not the file vimtutor.man in the vim distribution - the latter
      >doesn't include embedded backspaces).
      >
      >I have the following problem: while the character before an embedded backspace
      >is ignored (sort of: it is colored white), the backspace is printed as a ^H.
      >I would expect the two characters to be skipped all together. (snip)
      >

      Why would you expect that? Syntax highlighting is highlighting, not
      inline folding. Vim doesn't support inline folding. Vince Negri has
      provided a patch to vim's source (http://vince.negri.googlepages.com/)
      which permits inline folding, though. I've used that feature in AnsiEsc
      (http://vim.sourceforge.net/scripts/script.php?script_id=302) which
      highlights text using Ansi Escape sequences (while suppressing the
      escape sequences themselves).

      However, it is unrealistic to expect that man.vim would support Negri's
      unofficial patch; in fact, there's not many scripts that do. One
      natural use for such a feature would be to allow LaTeX files to be
      displayed using its embedded directives while suppressing the directives
      themselves, which would make for nice LaTeX editing.

      Unfortunately, IMHO, inline folding didn't get enough votes during vim
      7.0's development, and Bram is uncomfortable with the idea of inline
      folding because it, naturally enough, suppresses information (Vince's
      patch typically folds all lines but the current one). At least, that's
      how I understand the state of things.

      Regards,
      Chip Campbell
    • A.J.Mechelynck
      Charles E Campbell Jr wrote: [...] ... Doesn t linewise folding also suppress information? Yet Vim has had that for quite some time. It is true that it doesn t
      Message 2 of 8 , Jan 3, 2007
      • 0 Attachment
        Charles E Campbell Jr wrote:
        [...]
        > Unfortunately, IMHO, inline folding didn't get enough votes during vim
        > 7.0's development, and Bram is uncomfortable with the idea of inline
        > folding because it, naturally enough, suppresses information (Vince's
        > patch typically folds all lines but the current one). At least, that's
        > how I understand the state of things.
        >
        > Regards,
        > Chip Campbell
        >
        >

        Doesn't linewise folding also suppress information? Yet Vim has had that for
        quite some time. It is true that it doesn't make the folds disappear
        completely; rather, each outer closed fold is replaced by one line. That
        wouldn't work for inline folding; but maybe it could use the 'foldcolumn' or
        something to draw attention to the fact that something has been hidden.

        And BTW, the Hidden highlight group (guibg=bg guifg=bg) also "suppresses"
        whatever uses it, yet IIUC it is used a lot in helpfiles. I'm not sure about
        netrw, but the older Explorer plugin also used it to hide its sort key.


        Best regards,
        Tony.
      • Charles E Campbell Jr
        ... That wasn t my objection; I rather like inline folding. Also, perhaps I may not have stated Bram s objection correctly, or perhaps I misunderstood it.
        Message 3 of 8 , Jan 3, 2007
        • 0 Attachment
          A.J.Mechelynck wrote:

          > Charles E Campbell Jr wrote:
          > [...]
          >
          >> Unfortunately, IMHO, inline folding didn't get enough votes during
          >> vim 7.0's development, and Bram is uncomfortable with the idea of
          >> inline folding because it, naturally enough, suppresses information
          >> (Vince's patch typically folds all lines but the current one). At
          >> least, that's how I understand the state of things.
          >>
          >> Regards,
          >> Chip Campbell
          >>
          >>
          >
          > Doesn't linewise folding also suppress information? Yet Vim has had
          > that for quite some time. It is true that it doesn't make the folds
          > disappear completely; rather, each outer closed fold is replaced by
          > one line. That wouldn't work for inline folding; but maybe it could
          > use the 'foldcolumn' or something to draw attention to the fact that
          > something has been hidden.
          >
          > And BTW, the Hidden highlight group (guibg=bg guifg=bg) also
          > "suppresses" whatever uses it, yet IIUC it is used a lot in helpfiles.
          > I'm not sure about netrw, but the older Explorer plugin also used it
          > to hide its sort key.

          That wasn't my objection; I rather like inline folding. Also, perhaps I
          may not have stated Bram's objection correctly, or perhaps I
          misunderstood it. After all, he does have the following note in the
          todo.txt:

          - Add 'hidecomment' option: don't display comments in /* */ and after //.
          Or is the conceal patch from Vince Negri a more generic solution?

          Vince Negri's patch could certainly be used to hide comments but leave
          the comment start designators visible. It basically allows one to
          extend syntax highlighting to include the "conceal" option, so one can
          specify things to inline conceal.

          Vince's folding patch supports the notion of "conceallevel"; taken from
          his patch to options.txt:

          'conceallevel' Effect
          0 Text is shown normally
          1 Each block of concealed text is replaced with the
          character defined in 'listchars' (default is a dash)
          and highlighted with the "Conceal" highlight group.
          2 Concealed text is completely hidden unless it has a
          custom replacement character defined (see
          |syn-cchar|.
          3 Concealed text is completely hidden.

          Even conceallevel==3 isn't actually "completely hidden"; instead, the
          current line (the one the cursor is on and where presumably editing may
          occur) has its text shown normally (ie. no inline folding on the current
          line).

          Regards,
          Chip Campbell
        • Vince Negri
          ... The display depends on the setting of concealevel . When set to 1, inline folded elements are replaced by a configurable special character. When set to 2,
          Message 4 of 8 , Jan 3, 2007
          • 0 Attachment
            A.J.Mechelynck [mailto:antoine.mechelynck@...] wrote:

            > Doesn't linewise folding also suppress information? Yet Vim has had that for
            > quite some time. It is true that it doesn't make the folds disappear
            > completely; rather, each outer closed fold is replaced by one line. That
            > wouldn't work for inline folding; but maybe it could use the 'foldcolumn' or
            > something to draw attention to the fact that something has been hidden.

            The display depends on the setting of "concealevel". When set to 1, inline folded
            elements are replaced by a configurable special character. When set to 2, the
            folded elements are hidden completely; your idea of showing something in
            foldcolumn is an interesting one.

            Vince
          • Vince Negri
            ... Oo, a bug in my docs. Thanks for spotting this. Vince
            Message 5 of 8 , Jan 3, 2007
            • 0 Attachment
              Charles E Campbell Jr [mailto:drchip@...] wrote:

              > Even conceallevel==3 isn't actually "completely hidden"; instead, the
              > current line (the one the cursor is on and where presumably editing may
              > occur) has its text shown normally (ie. no inline folding on the current
              > line).

              Oo, a bug in my docs. Thanks for spotting this.

              Vince
            • Vince Negri
              James Vega [mailto:jamessan@jamessan.com] wrote: On the other hand, integrating the [conceal] patch would provide a solution for various itches that I know
              Message 6 of 8 , Jan 4, 2007
              • 0 Attachment
                James Vega [mailto:jamessan@...] wrote:

                On the other hand, integrating the [conceal] patch would provide a solution for
                various itches that I know people want to scratch (mainly to do with
                builtin previewing of filetypes like html, tex, etc). If it were
                disabled by default (as I think folding should be), it would allow
                people that knew of it to take advantage of the functionality without
                causing novice users to wonder what the heck is going on.

                FYI the default "conceallevel" is 0, at which no concealment goes on at all.

                To recap:

                0 - normal operation.

                1 - inline folding, each group of concealed chars replaced by a configurable character
                (by default this is a "-" highlighted to look similar to a folded line.

                Mode 1 is most useful for "folding out" applications, since you can always
                see that something has been removed.

                2 - hide/replace mode. Concealed chars are hidden completely, unless a character has
                been specified for them in the syntax definition. Simple example: in my own
                HTML syntax I have the "&" sequence folded and replaced with "&".

                Mode 2 is the most useful for "smart" TeX and HTML etc editing, as it has
                the cleanest look.

                3 - hide mode. Concealed chars are always hidden completely. This is only there for
                completeness, I would imagine option 2 is always the more useful.


                Vince
              Your message has been successfully submitted and would be delivered to recipients shortly.