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

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

Expand Messages
  • 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 1 of 15 , Sep 25, 2013
      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 2 of 15 , Sep 25, 2013
        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 3 of 15 , Sep 25, 2013
          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 4 of 15 , Sep 25, 2013
            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 5 of 15 , Sep 25, 2013
              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 6 of 15 , Sep 25, 2013
                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 7 of 15 , Sep 25, 2013
                  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 8 of 15 , Sep 25, 2013
                    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 9 of 15 , Sep 25, 2013
                      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 10 of 15 , Sep 25, 2013
                        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 11 of 15 , Sep 28, 2013
                          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.