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

Does 'man' syntax do its job?

Expand Messages
  • Zvi Har'El
    Hi, 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)
    Message 1 of 8 , Jan 1, 2007
    • 0 Attachment
      Hi,

      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. The same effect
      is generated without the man syntax, just with sourcing
      $VIMRUNTIME/syntax/ctrlh.vim. This is not new to 7.0 - 6.3 shows the same
      results. You can see a screen dump of 'gview' in
      http://www.math.technion.ac.il/~rl/etc/gview.jpg , and of 'view' on an xterm
      with a yellow background in http://www.math.technion.ac.il/~rl/etc/view.jpg. I
      I ran 'gview' and 'view' with the command line

      gview -i NONE -c 'syntax on' vimtutor.man

      view -i NONE -c 'syntax on' vimtutor.man

      Regards,

      Zvi
      --
      Dr. Zvi Har'El mailto:rl@... Department of Mathematics
      tel:+972-54-4227607 icq:179294841 Technion - Israel Institute of Technology
      fax:+972-4-8293388 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL
      "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942)
      Monday, 11 Tevet 5767, 1 January 2007, 3:34PM
    • 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 2 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 3 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 4 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 5 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 6 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
              • James Vega
                ... Both of those hide information, but in a way that is still discoverable/noticeable by the user. Folds show a fold line, and ignored highlights still
                Message 7 of 8 , Jan 3, 2007
                • 0 Attachment
                  On Wed, Jan 03, 2007 at 05:06:50PM +0100, A.J.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.
                  >
                  > 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.

                  Both of those hide information, but in a way that is still
                  discoverable/noticeable by the user. Folds show a fold line, and
                  'ignored' highlights still occupy real estate on the screen. Also, with
                  the colorschemes I've used, you can still see the actual ignored text
                  when the cursor is on the character. When using the conceal
                  functionality, text is completely hidden from the user. (I just saw
                  Vince's reply that this depends on 'conceallevel', so it may not be as
                  unobvious as I originally thought.) This has its place obviously (as
                  evidenced by the patch even existing), but I can understand reluctance
                  to include the patch since it so dramatically affects the display of the
                  buffer.

                  On the other hand, integrating the 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.

                  James
                  --
                  GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@...>
                • 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 8 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.