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

'cindent' and 'cinkeys' with 0# inhibits >> of lines with # in column 1

Expand Messages
  • Gary Johnson
    I ve discovered that with cindent set and with cinkeys containing 0# as it does by default, the command has no effect on a line having a # in column 1.
    Message 1 of 15 , Sep 24, 2013
    • 0 Attachment
      I've discovered that with 'cindent' set and with 'cinkeys'
      containing 0# as it does by default, the >> command has no effect on
      a line having a # in column 1.

      To demonstrate this, start Vim as

      vim -N -u NONE

      and enter this line with the # in column 1:

      #define this

      Type >> and <<. Note that the line shifts to the right and left.

      Now execute

      :set cindent

      and type >>. Note that the line does not move.

      Execute

      :set cinkeys-=0#

      and type >> again. The line shifts to the right.

      I've observed this on Linux using vim version 7.2.148 as well as
      7.4.27, so this is not a new problem and may well have existed from
      the beginning.

      Granted, this is a minor problem that I've just now encountered
      after having used Vim for many years; it's just annoyingly
      interfering with what I'm trying to do at the moment.

      Regards,
      Gary

      --
      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Christian Brabandt
      ... That happens on purpose. See op_shift(): ,----[ ops.c ]- ... `---- I guess, the intention is, that in C code the defines need to be in the first column.
      Message 2 of 15 , Sep 24, 2013
      • 0 Attachment
        On Di, 24 Sep 2013, Gary Johnson wrote:

        > I've discovered that with 'cindent' set and with 'cinkeys'
        > containing 0# as it does by default, the >> command has no effect on
        > a line having a # in column 1.
        >
        > To demonstrate this, start Vim as
        >
        > vim -N -u NONE
        >
        > and enter this line with the # in column 1:
        >
        > #define this
        >
        > Type >> and <<. Note that the line shifts to the right and left.
        >
        > Now execute
        >
        > :set cindent
        >
        > and type >>. Note that the line does not move.
        >
        > Execute
        >
        > :set cinkeys-=0#
        >
        > and type >> again. The line shifts to the right.
        >
        > I've observed this on Linux using vim version 7.2.148 as well as
        > 7.4.27, so this is not a new problem and may well have existed from
        > the beginning.
        >
        > Granted, this is a minor problem that I've just now encountered
        > after having used Vim for many years; it's just annoyingly
        > interfering with what I'm trying to do at the moment.

        That happens on purpose. See op_shift():

        ,----[ ops.c ]-
        | [...]
        | 248 for (i = oap->line_count; --i >= 0; )
        | 249 {
        | 250 first_char = *ml_get_curline();
        | 251 if (first_char == NUL) /* empty line */
        | 252 curwin->w_cursor.col = 0;
        | 253 #ifdef FEAT_VISUALEXTRA
        | 254 else if (oap->block_mode)
        | 255 shift_block(oap, amount);
        | 256 #endif
        | 257 else
        | 258 /* Move the line right if it doesn't start with '#', 'smartindent'
        | 259 * isn't set or 'cindent' isn't set or '#' isn't in 'cino'. */
        | 260 #if defined(FEAT_SMARTINDENT) || defined(FEAT_CINDENT)
        | 261 if (first_char != '#' || !preprocs_left())
        | 262 #endif
        | 263 {
        | 264 shift_line(oap->op_type == OP_LSHIFT, p_sr, amount, FALSE);
        | 265 }
        | 266 ++curwin->w_cursor.lnum;
        | 267 }
        | [...]
        `----

        I guess, the intention is, that in C code the defines need to be in the
        first column.

        regards,
        Christian
        --
        Die meisten reden origineller, als sie schreiben.
        -- Jean Paul

        --
        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Gary Johnson
        ... Thanks for checking that. It s odd, though. K&R, 2nd Ed., says: A12. Preprocessing A preprocessor performs macro substitution, conditional compilation,
        Message 3 of 15 , Sep 24, 2013
        • 0 Attachment
          On 2013-09-24, Christian Brabandt wrote:
          > On Di, 24 Sep 2013, Gary Johnson wrote:
          >
          > > I've discovered that with 'cindent' set and with 'cinkeys'
          > > containing 0# as it does by default, the >> command has no effect on
          > > a line having a # in column 1.
          > >
          > > To demonstrate this, start Vim as
          > >
          > > vim -N -u NONE
          > >
          > > and enter this line with the # in column 1:
          > >
          > > #define this
          > >
          > > Type >> and <<. Note that the line shifts to the right and left.
          > >
          > > Now execute
          > >
          > > :set cindent
          > >
          > > and type >>. Note that the line does not move.
          > >
          > > Execute
          > >
          > > :set cinkeys-=0#
          > >
          > > and type >> again. The line shifts to the right.
          > >
          > > I've observed this on Linux using vim version 7.2.148 as well as
          > > 7.4.27, so this is not a new problem and may well have existed from
          > > the beginning.
          > >
          > > Granted, this is a minor problem that I've just now encountered
          > > after having used Vim for many years; it's just annoyingly
          > > interfering with what I'm trying to do at the moment.
          >
          > That happens on purpose. See op_shift():
          >
          > ,----[ ops.c ]-
          > | [...]
          > | 248 for (i = oap->line_count; --i >= 0; )
          > | 249 {
          > | 250 first_char = *ml_get_curline();
          > | 251 if (first_char == NUL) /* empty line */
          > | 252 curwin->w_cursor.col = 0;
          > | 253 #ifdef FEAT_VISUALEXTRA
          > | 254 else if (oap->block_mode)
          > | 255 shift_block(oap, amount);
          > | 256 #endif
          > | 257 else
          > | 258 /* Move the line right if it doesn't start with '#', 'smartindent'
          > | 259 * isn't set or 'cindent' isn't set or '#' isn't in 'cino'. */
          > | 260 #if defined(FEAT_SMARTINDENT) || defined(FEAT_CINDENT)
          > | 261 if (first_char != '#' || !preprocs_left())
          > | 262 #endif
          > | 263 {
          > | 264 shift_line(oap->op_type == OP_LSHIFT, p_sr, amount, FALSE);
          > | 265 }
          > | 266 ++curwin->w_cursor.lnum;
          > | 267 }
          > | [...]
          > `----
          >
          > I guess, the intention is, that in C code the defines need to be in the
          > first column.

          Thanks for checking that.

          It's odd, though. K&R, 2nd Ed., says:

          A12. Preprocessing

          A preprocessor performs macro substitution, conditional
          compilation, and inclusion of named files. Lines beginning with
          #, perhaps preceded by white space, communicate with this
          preprocessor.

          Vim's behavior looks to me like a mistake in someone's understanding
          of C.

          I could see an indentation function moving lines beginning with # to
          the left, but preventing the user from executing a command to
          deliberately shift a line seems a little extreme.

          Regards,
          Gary

          --
          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Christian Brabandt
          ... [...] ... Indeed, it looks strange. Especially, since left shifts are allowed, but once you reach column 1, you can t right shift anymore. Also note, that
          Message 4 of 15 , Sep 24, 2013
          • 0 Attachment
            On Di, 24 Sep 2013, Gary Johnson wrote:

            > On 2013-09-24, Christian Brabandt wrote:
            > >
            > > I guess, the intention is, that in C code the defines need to be in the
            > > first column.
            >
            > Thanks for checking that.
            >
            [...]
            > Vim's behavior looks to me like a mistake in someone's understanding
            > of C.
            >
            > I could see an indentation function moving lines beginning with # to
            > the left, but preventing the user from executing a command to
            > deliberately shift a line seems a little extreme.

            Indeed, it looks strange. Especially, since left shifts are allowed, but
            once you reach column 1, you can't right shift anymore. Also note, that
            despite Vim's inability to right shift defines, the file will still be
            marked modified.

            Here is a simple patch, allowing the user to right shift #defines.

            regards,
            Christian
            --
            Liebe ist die gesellschaftlich anerkannte Form des
            Wahnsinns.
            -- Benjamin Stramke

            --
            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • Bram Moolenaar
            ... Allowing white space before the # is later addition, older C compilers do not allow it. My K&R does not mention it. And because of that it has been a
            Message 5 of 15 , Sep 25, 2013
            • 0 Attachment
              Christian Brabandt wrote:

              > On Di, 24 Sep 2013, Gary Johnson wrote:
              >
              > > On 2013-09-24, Christian Brabandt wrote:
              > > >
              > > > I guess, the intention is, that in C code the defines need to be in the
              > > > first column.
              > >
              > > Thanks for checking that.
              > >
              > [...]
              > > Vim's behavior looks to me like a mistake in someone's understanding
              > > of C.
              > >
              > > I could see an indentation function moving lines beginning with # to
              > > the left, but preventing the user from executing a command to
              > > deliberately shift a line seems a little extreme.
              >
              > Indeed, it looks strange. Especially, since left shifts are allowed, but
              > once you reach column 1, you can't right shift anymore. Also note, that
              > despite Vim's inability to right shift defines, the file will still be
              > marked modified.
              >
              > Here is a simple patch, allowing the user to right shift #defines.

              Allowing white space before the # is later addition, older C compilers
              do not allow it. My K&R does not mention it. And because of that it
              has been a convention to keep the # in the first column and put any
              indent after it.

              For portability and readability I would encourage keeping the # in the
              first column. Allowing to put it elsewhere should be an option that is
              off by default.


              --
              God made the integers; all else is the work of Man.
              -- Kronecker

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              \\\ an exciting new programming language -- http://www.Zimbu.org ///
              \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

              --
              --
              You received this message from the "vim_dev" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php

              ---
              You received this message because you are subscribed to the Google Groups "vim_dev" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Christian Brabandt
              ... An addition to cinkeys? Or a separate option? regards, Christian -- -- You received this message from the vim_dev maillist. Do not top-post! Type your
              Message 6 of 15 , Sep 25, 2013
              • 0 Attachment
                On Wed, September 25, 2013 13:18, Bram Moolenaar wrote:
                >
                > Christian Brabandt wrote:
                >
                >> On Di, 24 Sep 2013, Gary Johnson wrote:
                >>
                >> > On 2013-09-24, Christian Brabandt wrote:
                >> > >
                >> > > I guess, the intention is, that in C code the defines need to be in
                >> the
                >> > > first column.
                >> >
                >> > Thanks for checking that.
                >> >
                >> [...]
                >> > Vim's behavior looks to me like a mistake in someone's understanding
                >> > of C.
                >> >
                >> > I could see an indentation function moving lines beginning with # to
                >> > the left, but preventing the user from executing a command to
                >> > deliberately shift a line seems a little extreme.
                >>
                >> Indeed, it looks strange. Especially, since left shifts are allowed, but
                >> once you reach column 1, you can't right shift anymore. Also note, that
                >> despite Vim's inability to right shift defines, the file will still be
                >> marked modified.
                >>
                >> Here is a simple patch, allowing the user to right shift #defines.
                >
                > Allowing white space before the # is later addition, older C compilers
                > do not allow it. My K&R does not mention it. And because of that it
                > has been a convention to keep the # in the first column and put any
                > indent after it.
                >
                > For portability and readability I would encourage keeping the # in the
                > first column. Allowing to put it elsewhere should be an option that is
                > off by default.

                An addition to cinkeys? Or a separate option?

                regards,
                Christian

                --
                --
                You received this message from the "vim_dev" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php

                ---
                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • Bram Moolenaar
                ... cinoptions is for cindent options. -- We re knights of the Round Table Our shows are formidable But many times We re given rhymes That are quite
                Message 7 of 15 , Sep 25, 2013
                • 0 Attachment
                  Christian Brabandt wrote:

                  > >> Indeed, it looks strange. Especially, since left shifts are allowed, but
                  > >> once you reach column 1, you can't right shift anymore. Also note, that
                  > >> despite Vim's inability to right shift defines, the file will still be
                  > >> marked modified.
                  > >>
                  > >> Here is a simple patch, allowing the user to right shift #defines.
                  > >
                  > > Allowing white space before the # is later addition, older C compilers
                  > > do not allow it. My K&R does not mention it. And because of that it
                  > > has been a convention to keep the # in the first column and put any
                  > > indent after it.
                  > >
                  > > For portability and readability I would encourage keeping the # in the
                  > > first column. Allowing to put it elsewhere should be an option that is
                  > > off by default.
                  >
                  > An addition to cinkeys? Or a separate option?

                  'cinoptions' is for 'cindent' options.

                  --
                  We're knights of the Round Table
                  Our shows are formidable
                  But many times
                  We're given rhymes
                  That are quite unsingable
                  We're opera mad in Camelot
                  We sing from the diaphragm a lot.
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

                  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                  /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                  \\\ an exciting new programming language -- http://www.Zimbu.org ///
                  \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                  --
                  --
                  You received this message from the "vim_dev" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php

                  ---
                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                • Ben Fritz
                  ... Agree, that makes sense. And thus the default cindent settings should also place it in the first column. ... I thought at first it is very strange Vim
                  Message 8 of 15 , Sep 25, 2013
                  • 0 Attachment
                    On Wednesday, September 25, 2013 6:18:00 AM UTC-5, Bram Moolenaar wrote:
                    >
                    >
                    > For portability and readability I would encourage keeping the # in the
                    >
                    > first column.

                    Agree, that makes sense. And thus the default 'cindent' settings should also place it in the first column.

                    > Allowing to put it elsewhere should be an option that is
                    >
                    > off by default.
                    >

                    I thought at first it is very strange Vim would EVER ignore a specific user command to indent a line, but then realized this is because I'm thinking about '>>'.

                    More dangerous would be using >aB, without knowing there are preprocessor lines in that code block. Then it actually makes sense to keep those in the first line.

                    --
                    --
                    You received this message from the "vim_dev" maillist.
                    Do not top-post! Type your reply below the text you are replying to.
                    For more information, visit http://www.vim.org/maillist.php

                    ---
                    You received this message because you are subscribed to the Google Groups "vim_dev" group.
                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                    For more options, visit https://groups.google.com/groups/opt_out.
                  • Christian Brabandt
                    ... So do we agree, that cino=#N with N being non-zero would allow to indent defines ? regards, Christian -- -- You received this message from the vim_dev
                    Message 9 of 15 , Sep 25, 2013
                    • 0 Attachment
                      On Wed, September 25, 2013 15:21, Bram Moolenaar wrote:
                      > 'cinoptions' is for 'cindent' options.

                      So do we agree, that cino=#N with N being non-zero would allow to
                      indent 'defines'?

                      regards,
                      Christian

                      --
                      --
                      You received this message from the "vim_dev" maillist.
                      Do not top-post! Type your reply below the text you are replying to.
                      For more information, visit http://www.vim.org/maillist.php

                      ---
                      You received this message because you are subscribed to the Google Groups "vim_dev" group.
                      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                      For more options, visit https://groups.google.com/groups/opt_out.
                    • Gary Johnson
                      ... I disagree. If I execute =aB, then I am telling the editor to use its judgement and its indentation rules to indent all the lines in that block, which may
                      Message 10 of 15 , Sep 25, 2013
                      • 0 Attachment
                        On 2013-09-25, Ben Fritz wrote:
                        > On Wednesday, September 25, 2013 6:18:00 AM UTC-5, Bram Moolenaar wrote:
                        > >
                        > >
                        > > For portability and readability I would encourage keeping the # in the
                        > >
                        > > first column.
                        >
                        > Agree, that makes sense. And thus the default 'cindent' settings
                        > should also place it in the first column.
                        >
                        > > Allowing to put it elsewhere should be an option that is
                        > >
                        > > off by default.
                        > >
                        >
                        > I thought at first it is very strange Vim would EVER ignore a
                        > specific user command to indent a line, but then realized this is
                        > because I'm thinking about '>>'.
                        >
                        > More dangerous would be using >aB, without knowing there are
                        > preprocessor lines in that code block. Then it actually makes
                        > sense to keep those in the first line.

                        I disagree.

                        If I execute =aB, then I am telling the editor to use its judgement
                        and its indentation rules to indent all the lines in that block,
                        which may well include shifting preprocessor lines all the way to
                        the left.

                        However, if I execute >aB, I am telling the editor explicitly that
                        I want all the lines in that block to be shifted to the right. It
                        is my choice and my judgement that that is the right thing to do.
                        The > command should mean "shift", not "shift unless the editor
                        thinks it knows better than the user."

                        Regards,
                        Gary

                        --
                        --
                        You received this message from the "vim_dev" maillist.
                        Do not top-post! Type your reply below the text you are replying to.
                        For more information, visit http://www.vim.org/maillist.php

                        ---
                        You received this message because you are subscribed to the Google Groups "vim_dev" group.
                        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                        For more options, visit https://groups.google.com/groups/opt_out.
                      • Bram Moolenaar
                        ... If you see the command as increasing indent then it makes perfect sense that indenting rules apply. For the same reason shiftwidth is used for
                        Message 11 of 15 , Sep 25, 2013
                        • 0 Attachment
                          Gary Johnson wrote:

                          > On 2013-09-25, Ben Fritz wrote:
                          > > On Wednesday, September 25, 2013 6:18:00 AM UTC-5, Bram Moolenaar wrote:
                          > > >
                          > > >
                          > > > For portability and readability I would encourage keeping the # in the
                          > > >
                          > > > first column.
                          > >
                          > > Agree, that makes sense. And thus the default 'cindent' settings
                          > > should also place it in the first column.
                          > >
                          > > > Allowing to put it elsewhere should be an option that is
                          > > >
                          > > > off by default.
                          > > >
                          > >
                          > > I thought at first it is very strange Vim would EVER ignore a
                          > > specific user command to indent a line, but then realized this is
                          > > because I'm thinking about '>>'.
                          > >
                          > > More dangerous would be using >aB, without knowing there are
                          > > preprocessor lines in that code block. Then it actually makes
                          > > sense to keep those in the first line.
                          >
                          > I disagree.
                          >
                          > If I execute =aB, then I am telling the editor to use its judgement
                          > and its indentation rules to indent all the lines in that block,
                          > which may well include shifting preprocessor lines all the way to
                          > the left.
                          >
                          > However, if I execute >aB, I am telling the editor explicitly that
                          > I want all the lines in that block to be shifted to the right. It
                          > is my choice and my judgement that that is the right thing to do.
                          > The > command should mean "shift", not "shift unless the editor
                          > thinks it knows better than the user."

                          If you see the ">" command as increasing indent then it makes perfect
                          sense that indenting rules apply. For the same reason 'shiftwidth' is
                          used for indenting.

                          --
                          ARTHUR: (as the MAN next to him is squashed by a sheep) Knights! Run away!
                          Midst echoing shouts of "run away" the KNIGHTS retreat to cover with the odd
                          cow or goose hitting them still. The KNIGHTS crouch down under cover.
                          "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

                          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                          \\\ an exciting new programming language -- http://www.Zimbu.org ///
                          \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                          --
                          --
                          You received this message from the "vim_dev" maillist.
                          Do not top-post! Type your reply below the text you are replying to.
                          For more information, visit http://www.vim.org/maillist.php

                          ---
                          You received this message because you are subscribed to the Google Groups "vim_dev" group.
                          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                          For more options, visit https://groups.google.com/groups/opt_out.
                        • Gary Johnson
                          ... :help says shift[s] , not increases indent . However, it s the utility of the command that s important, not its description, and I see your point.
                          Message 12 of 15 , Sep 25, 2013
                          • 0 Attachment
                            On 2013-09-25, Bram Moolenaar wrote:
                            > Gary Johnson wrote:
                            >
                            > > On 2013-09-25, Ben Fritz wrote:
                            > > > On Wednesday, September 25, 2013 6:18:00 AM UTC-5, Bram Moolenaar wrote:
                            > > > >
                            > > > >
                            > > > > For portability and readability I would encourage keeping the # in the
                            > > > >
                            > > > > first column.
                            > > >
                            > > > Agree, that makes sense. And thus the default 'cindent' settings
                            > > > should also place it in the first column.
                            > > >
                            > > > > Allowing to put it elsewhere should be an option that is
                            > > > >
                            > > > > off by default.
                            > > > >
                            > > >
                            > > > I thought at first it is very strange Vim would EVER ignore a
                            > > > specific user command to indent a line, but then realized this is
                            > > > because I'm thinking about '>>'.
                            > > >
                            > > > More dangerous would be using >aB, without knowing there are
                            > > > preprocessor lines in that code block. Then it actually makes
                            > > > sense to keep those in the first line.
                            > >
                            > > I disagree.
                            > >
                            > > If I execute =aB, then I am telling the editor to use its judgement
                            > > and its indentation rules to indent all the lines in that block,
                            > > which may well include shifting preprocessor lines all the way to
                            > > the left.
                            > >
                            > > However, if I execute >aB, I am telling the editor explicitly that
                            > > I want all the lines in that block to be shifted to the right. It
                            > > is my choice and my judgement that that is the right thing to do.
                            > > The > command should mean "shift", not "shift unless the editor
                            > > thinks it knows better than the user."
                            >
                            > If you see the ">" command as increasing indent then it makes perfect
                            > sense that indenting rules apply. For the same reason 'shiftwidth' is
                            > used for indenting.

                            ":help >" says "shift[s]", not "increases indent". However, it's
                            the utility of the command that's important, not its description,
                            and I see your point. I'll concede.

                            Regards,
                            Gary

                            --
                            --
                            You received this message from the "vim_dev" maillist.
                            Do not top-post! Type your reply below the text you are replying to.
                            For more information, visit http://www.vim.org/maillist.php

                            ---
                            You received this message because you are subscribed to the Google Groups "vim_dev" group.
                            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                            For more options, visit https://groups.google.com/groups/opt_out.
                          • Christian Brabandt
                            ... No one complains, so here is an updated patch. regards, Christian -- Mit dem Alter nimmt die Urteilskraft zu und das Genie ab. -- Immanuel Kant -- -- You
                            Message 13 of 15 , Sep 25, 2013
                            • 0 Attachment
                              On Mi, 25 Sep 2013, Christian Brabandt wrote:

                              > On Wed, September 25, 2013 15:21, Bram Moolenaar wrote:
                              > > 'cinoptions' is for 'cindent' options.
                              >
                              > So do we agree, that cino=#N with N being non-zero would allow to
                              > indent 'defines'?

                              No one complains, so here is an updated patch.

                              regards,
                              Christian
                              --
                              Mit dem Alter nimmt die Urteilskraft zu und das Genie ab.
                              -- Immanuel Kant

                              --
                              --
                              You received this message from the "vim_dev" maillist.
                              Do not top-post! Type your reply below the text you are replying to.
                              For more information, visit http://www.vim.org/maillist.php

                              ---
                              You received this message because you are subscribed to the Google Groups "vim_dev" group.
                              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                              For more options, visit https://groups.google.com/groups/opt_out.
                            • Christian Brabandt
                              ... Grmml, It helps to actually attach a file. So let s try that again: Best, Christian -- F: Warum heißt der Trabi Trabi? A: Wenn er schneller wäre, würde
                              Message 14 of 15 , Sep 25, 2013
                              • 0 Attachment
                                On Mi, 25 Sep 2013, Christian Brabandt wrote:

                                > On Mi, 25 Sep 2013, Christian Brabandt wrote:
                                >
                                > > On Wed, September 25, 2013 15:21, Bram Moolenaar wrote:
                                > > > 'cinoptions' is for 'cindent' options.
                                > >
                                > > So do we agree, that cino=#N with N being non-zero would allow to
                                > > indent 'defines'?
                                >
                                > No one complains, so here is an updated patch.

                                Grmml, It helps to actually attach a file. So let's try that again:

                                Best,
                                Christian
                                --
                                F: Warum heißt der Trabi Trabi?
                                A: Wenn er schneller wäre, würde er Galoppi heißen.

                                --
                                --
                                You received this message from the "vim_dev" maillist.
                                Do not top-post! Type your reply below the text you are replying to.
                                For more information, visit http://www.vim.org/maillist.php

                                ---
                                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                For more options, visit https://groups.google.com/groups/opt_out.
                              • Bram Moolenaar
                                ... Thanks. It makes sense to me, but can anyone think of a situation where #1 is in cino and the user would still want #lines to be in the leftmost column?
                                Message 15 of 15 , Sep 28, 2013
                                • 0 Attachment
                                  Christian Brabandt wrote:

                                  > On Mi, 25 Sep 2013, Christian Brabandt wrote:
                                  >
                                  > > On Mi, 25 Sep 2013, Christian Brabandt wrote:
                                  > >
                                  > > > On Wed, September 25, 2013 15:21, Bram Moolenaar wrote:
                                  > > > > 'cinoptions' is for 'cindent' options.
                                  > > >
                                  > > > So do we agree, that cino=#N with N being non-zero would allow to
                                  > > > indent 'defines'?
                                  > >
                                  > > No one complains, so here is an updated patch.
                                  >
                                  > Grmml, It helps to actually attach a file. So let's try that again:

                                  Thanks. It makes sense to me, but can anyone think of a situation where
                                  #1 is in 'cino' and the user would still want #lines to be in the
                                  leftmost column?

                                  --
                                  GALAHAD: No. Look, I can tackle this lot single-handed!
                                  GIRLS: Yes, yes, let him Tackle us single-handed!
                                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

                                  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                                  /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                                  \\\ an exciting new programming language -- http://www.Zimbu.org ///
                                  \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                                  --
                                  --
                                  You received this message from the "vim_dev" maillist.
                                  Do not top-post! Type your reply below the text you are replying to.
                                  For more information, visit http://www.vim.org/maillist.php

                                  ---
                                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                  For more options, visit https://groups.google.com/groups/opt_out.
                                Your message has been successfully submitted and would be delivered to recipients shortly.