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

Add count to :close and :hide commands

Expand Messages
  • Marcin Szamotulski
    Hello, I wrote a patch which adds [count] to :colse, :hide and ^Wc normal command. When given the window with window number [count] will be closed/hidden.
    Message 1 of 17 , Aug 9 3:04 AM
      Hello,

      I wrote a patch which adds [count] to :colse, :hide and ^Wc normal
      command. When given the window with window number [count] will be
      closed/hidden. Sometimes I want to close not the current window but
      another one, this command let to do that without switching windows
      without ^Ww normal command.

      Best regards,
      Marcin Szamotulski
    • Bram Moolenaar
      ... Nice idea. I would find :1close and :9close the most useful, closing the first and last window. Looks like the code does take the last window when
      Message 2 of 17 , Aug 9 4:08 AM
        Marcin Szamotulski wrote:

        > I wrote a patch which adds [count] to :colse, :hide and ^Wc normal
        > command. When given the window with window number [count] will be
        > closed/hidden. Sometimes I want to close not the current window but
        > another one, this command let to do that without switching windows
        > without ^Ww normal command.

        Nice idea. I would find ":1close" and ":9close" the most useful,
        closing the first and last window. Looks like the code does take the
        last window when the count is more than the number of windows. This
        isn't obvious in the documentation, adding these two as an example will
        make them found quicker. And perhaps :hide docs should refer to the
        explanation of [count] in :close.

        How about a test?


        --
        hundred-and-one symptoms of being an internet addict:
        9. All your daydreaming is preoccupied with getting a faster connection to the
        net: 28.8...ISDN...cable modem...T1...T3.

        /// 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/d/optout.
      • Bram Moolenaar
        ... Thinking about this, it would also be very nice to be able to close the ... And there is this entry in the todo list: Can t easily close the help window,
        Message 3 of 17 , Aug 10 6:51 AM
          I wrote:

          > Marcin Szamotulski wrote:
          >
          > > I wrote a patch which adds [count] to :colse, :hide and ^Wc normal
          > > command. When given the window with window number [count] will be
          > > closed/hidden. Sometimes I want to close not the current window but
          > > another one, this command let to do that without switching windows
          > > without ^Ww normal command.
          >
          > Nice idea. I would find ":1close" and ":9close" the most useful,
          > closing the first and last window. Looks like the code does take the
          > last window when the count is more than the number of windows. This
          > isn't obvious in the documentation, adding these two as an example will
          > make them found quicker. And perhaps :hide docs should refer to the
          > explanation of [count] in :close.
          >
          > How about a test?

          Thinking about this, it would also be very nice to be able to close the
          next or previous window:

          :+1close
          :-1close

          And there is this entry in the todo list:

          Can't easily close the help window, like ":pc" closes the
          preview window and ":ccl" closes the quickfix window. Add
          ":hclose". (Chris Gaal)
          Patch for :helpclose, Christian Brabandt, 2010 Sep 6.

          Looks like I'm a bit behind including patches...

          --
          hundred-and-one symptoms of being an internet addict:
          18. Your wife drapes a blond wig over your monitor to remind you of what she
          looks like.

          /// 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/d/optout.
        • Marcin Szamotulski
          ... There are probably a few other commands that could benefit with a similar approach. Best regards, Marcin Szamotulski
          Message 4 of 17 , Aug 10 11:33 AM
            On 15:51 Sun 10 Aug , Bram Moolenaar wrote:
            >
            > I wrote:
            >
            > > Marcin Szamotulski wrote:
            > >
            > > > I wrote a patch which adds [count] to :colse, :hide and ^Wc normal
            > > > command. When given the window with window number [count] will be
            > > > closed/hidden. Sometimes I want to close not the current window but
            > > > another one, this command let to do that without switching windows
            > > > without ^Ww normal command.
            > >
            > > Nice idea. I would find ":1close" and ":9close" the most useful,
            > > closing the first and last window. Looks like the code does take the
            > > last window when the count is more than the number of windows. This
            > > isn't obvious in the documentation, adding these two as an example will
            > > make them found quicker. And perhaps :hide docs should refer to the
            > > explanation of [count] in :close.
            > >
            > > How about a test?
            >
            > Thinking about this, it would also be very nice to be able to close the
            > next or previous window:
            >
            > :+1close
            > :-1close
            >
            > And there is this entry in the todo list:
            >
            > Can't easily close the help window, like ":pc" closes the
            > preview window and ":ccl" closes the quickfix window. Add
            > ":hclose". (Chris Gaal)
            > Patch for :helpclose, Christian Brabandt, 2010 Sep 6.
            >
            > Looks like I'm a bit behind including patches...

            Here is the patch. As a bonus:
            :$close " will close the last window
            :$-close " will close the penultimate window
            :.close " the same as :close
            :%close, :/pattern/close, :*close, ... " will emit E16 error

            There are probably a few other commands that could benefit with
            a similar approach.

            Best regards,
            Marcin Szamotulski
          • Marcin Szamotulski
            ... I updated the patch. It also includes changes for :argument, ... The patch includes a test. I attach also one more patch which makes :argadd work as
            Message 5 of 17 , Aug 14 3:14 AM
              On 19:33 Sun 10 Aug , Marcin Szamotulski wrote:
              > On 15:51 Sun 10 Aug , Bram Moolenaar wrote:
              > >
              > > I wrote:
              > >
              > > > Marcin Szamotulski wrote:
              > > >
              > > > > I wrote a patch which adds [count] to :colse, :hide and ^Wc normal
              > > > > command. When given the window with window number [count] will be
              > > > > closed/hidden. Sometimes I want to close not the current window but
              > > > > another one, this command let to do that without switching windows
              > > > > without ^Ww normal command.
              > > >
              > > > Nice idea. I would find ":1close" and ":9close" the most useful,
              > > > closing the first and last window. Looks like the code does take the
              > > > last window when the count is more than the number of windows. This
              > > > isn't obvious in the documentation, adding these two as an example will
              > > > make them found quicker. And perhaps :hide docs should refer to the
              > > > explanation of [count] in :close.
              > > >
              > > > How about a test?
              > >
              > > Thinking about this, it would also be very nice to be able to close the
              > > next or previous window:
              > >
              > > :+1close
              > > :-1close
              > >
              > > And there is this entry in the todo list:
              > >
              > > Can't easily close the help window, like ":pc" closes the
              > > preview window and ":ccl" closes the quickfix window. Add
              > > ":hclose". (Chris Gaal)
              > > Patch for :helpclose, Christian Brabandt, 2010 Sep 6.
              > >
              > > Looks like I'm a bit behind including patches...
              >
              > Here is the patch. As a bonus:
              > :$close " will close the last window
              > :$-close " will close the penultimate window
              > :.close " the same as :close
              > :%close, :/pattern/close, :*close, ... " will emit E16 error
              >
              > There are probably a few other commands that could benefit with
              > a similar approach.
              >
              > Best regards,
              > Marcin Szamotulski

              I updated the patch. It also includes changes for :argument,
              :sargument, :argedit, :argadd (they share the same logic for the [count]),
              and :argdelete. The supported counts are:

              :$argadd% " add at the end of arglist
              :-argadd% " add before the current argument
              :.argadd% " the same as :argadd%

              :%argdelete " delete all arguments
              :$argdelete " delete the last one
              :.argdelete " delete the current argument
              :+argdelete " delete the one after current
              :argdelete " with no count and no command argument: delete the current argument
              :2,$-2argdelete " will also work

              The patch includes a test.

              I attach also one more patch which makes ":argadd" work as ":argadd%".

              Best regards,
              Marcin Szamotulski
            • 'Andy Wokula' via vim_dev
              ... Some people expect :1,$bd or :%bd to delete all buffers. -- Andy -- -- You received this message from the vim_dev maillist. Do not top-post! Type your
              Message 6 of 17 , Aug 20 10:03 AM
                Am 10.08.2014 20:33, schrieb Marcin Szamotulski:
                > On 15:51 Sun 10 Aug , Bram Moolenaar wrote:
                >>
                >> I wrote:
                >>
                >>> Marcin Szamotulski wrote:
                >>>
                >>>> I wrote a patch which adds [count] to :colse, :hide and ^Wc normal
                >>>> command. When given the window with window number [count] will be
                >>>> closed/hidden. Sometimes I want to close not the current window but
                >>>> another one, this command let to do that without switching windows
                >>>> without ^Ww normal command.
                >>>
                >>> Nice idea. I would find ":1close" and ":9close" the most useful,
                >>> closing the first and last window. Looks like the code does take the
                >>> last window when the count is more than the number of windows. This
                >>> isn't obvious in the documentation, adding these two as an example will
                >>> make them found quicker. And perhaps :hide docs should refer to the
                >>> explanation of [count] in :close.
                >>>
                >>> How about a test?
                >>
                >> Thinking about this, it would also be very nice to be able to close the
                >> next or previous window:
                >>
                >> :+1close
                >> :-1close
                >>
                >> And there is this entry in the todo list:
                >>
                >> Can't easily close the help window, like ":pc" closes the
                >> preview window and ":ccl" closes the quickfix window. Add
                >> ":hclose". (Chris Gaal)
                >> Patch for :helpclose, Christian Brabandt, 2010 Sep 6.
                >>
                >> Looks like I'm a bit behind including patches...
                >
                > Here is the patch. As a bonus:
                > :$close " will close the last window
                > :$-close " will close the penultimate window
                > :.close " the same as :close
                > :%close, :/pattern/close, :*close, ... " will emit E16 error
                >
                > There are probably a few other commands that could benefit with
                > a similar approach.
                >
                > Best regards,
                > Marcin Szamotulski

                Some people expect :1,$bd or :%bd to delete all buffers.

                --
                Andy

                --
                --
                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/d/optout.
              • Christian Brabandt
                ... That only works by accident, because your current buffer has more lines than you have open buffers. Or saying it differently, this does not work in an
                Message 7 of 17 , Aug 20 10:49 PM
                  Am 2014-08-20 19:03, schrieb 'Andy Wokula' via vim_dev:
                  > Some people expect :1,$bd or :%bd to delete all buffers.

                  That only works by accident, because your current buffer has
                  more lines than you have open buffers.

                  Or saying it differently, this does not work in an empty buffer.

                  So this expectation is not really valid.

                  Best,
                  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/d/optout.
                • 'Andy Wokula' via vim_dev
                  ... Er, what you cited implies that it doesn t work at the moment (as expected (by some people (for a long time))). The idea is to make it become valid ... ...
                  Message 8 of 17 , Aug 21 10:41 AM
                    Am 21.08.2014 um 07:49 schrieb Christian Brabandt:
                    > Am 2014-08-20 19:03, schrieb 'Andy Wokula' via vim_dev:
                    >> Some people expect :1,$bd or :%bd to delete all buffers.
                    >
                    > That only works by accident, because your current buffer has more
                    > lines than you have open buffers.
                    >
                    > Or saying it differently, this does not work in an empty buffer.
                    >
                    > So this expectation is not really valid.
                    >
                    > Best, Christian

                    Er, what you cited implies that it doesn't work at the moment
                    (as expected (by some people (for a long time))).

                    The idea is to make it become valid ...

                    > Marcin Szamotulski wrote:
                    >> There are probably a few other commands that could benefit with a
                    >> similar approach.

                    Got it?

                    --
                    Andy

                    --
                    --
                    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/d/optout.
                  • Christian Brabandt
                    ... Ah, I thought you wanted to keep the current behaviour, that currently %bd already does delete all buffers (but only, if your buffer has enough lines).
                    Message 9 of 17 , Aug 21 11:02 AM
                      On Do, 21 Aug 2014, 'Andy Wokula' via vim_dev wrote:

                      > Am 21.08.2014 um 07:49 schrieb Christian Brabandt:
                      > >Am 2014-08-20 19:03, schrieb 'Andy Wokula' via vim_dev:
                      > >>Some people expect :1,$bd or :%bd to delete all buffers.
                      > >
                      > >That only works by accident, because your current buffer has more
                      > >lines than you have open buffers.
                      > >
                      > >Or saying it differently, this does not work in an empty buffer.
                      > >
                      > >So this expectation is not really valid.
                      >
                      > Er, what you cited implies that it doesn't work at the moment
                      > (as expected (by some people (for a long time))).
                      >
                      > The idea is to make it become valid ...
                      >
                      > >Marcin Szamotulski wrote:
                      > >>There are probably a few other commands that could benefit with a
                      > >>similar approach.
                      >
                      > Got it?
                      >

                      Ah, I thought you wanted to keep the current behaviour, that currently
                      %bd already does delete all buffers (but only, if your buffer has enough
                      lines).

                      Best,
                      Christian
                      --
                      Richtiges Auffassen einer Sache und Mißverstehen der gleichen Sache
                      schließen einander nicht aus.
                      -- Franz Kafka

                      --
                      --
                      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/d/optout.
                    • Marcin Szamotulski
                      ... Hi, So here are updated patches: count.patch - the counts argadd.patch - :argadd to be a valid command without and argument (:argadd%) Best regards, Marcin
                      Message 10 of 17 , Aug 30 4:16 AM
                        On 20:02 Thu 21 Aug , Christian Brabandt wrote:
                        >
                        > On Do, 21 Aug 2014, 'Andy Wokula' via vim_dev wrote:
                        >
                        > > Am 21.08.2014 um 07:49 schrieb Christian Brabandt:
                        > > >Am 2014-08-20 19:03, schrieb 'Andy Wokula' via vim_dev:
                        > > >>Some people expect :1,$bd or :%bd to delete all buffers.
                        > > >
                        > > >That only works by accident, because your current buffer has more
                        > > >lines than you have open buffers.
                        > > >
                        > > >Or saying it differently, this does not work in an empty buffer.
                        > > >
                        > > >So this expectation is not really valid.
                        > >
                        > > Er, what you cited implies that it doesn't work at the moment
                        > > (as expected (by some people (for a long time))).
                        > >
                        > > The idea is to make it become valid ...
                        > >
                        > > >Marcin Szamotulski wrote:
                        > > >>There are probably a few other commands that could benefit with a
                        > > >>similar approach.
                        > >
                        > > Got it?
                        > >
                        >
                        > Ah, I thought you wanted to keep the current behaviour, that currently
                        > %bd already does delete all buffers (but only, if your buffer has enough
                        > lines).
                        >
                        > Best,
                        > Christian
                        > --
                        > Richtiges Auffassen einer Sache und Mißverstehen der gleichen Sache
                        > schließen einander nicht aus.
                        > -- Franz Kafka
                        >

                        Hi,

                        So here are updated patches:
                        count.patch - the counts
                        argadd.patch - :argadd to be a valid command without and argument (:argadd%)

                        Best regards,
                        Marcin
                      • Bram Moolenaar
                        ... The patch for argadd doesn t take care of everything: - If there are special characters in the current buffer name, these are not handled correctly.
                        Message 11 of 17 , Sep 19, 2014
                          Marcin Szamotulski wrote:

                          > On 20:02 Thu 21 Aug , Christian Brabandt wrote:
                          > >
                          > > On Do, 21 Aug 2014, 'Andy Wokula' via vim_dev wrote:
                          > >
                          > > > Am 21.08.2014 um 07:49 schrieb Christian Brabandt:
                          > > > >Am 2014-08-20 19:03, schrieb 'Andy Wokula' via vim_dev:
                          > > > >>Some people expect :1,$bd or :%bd to delete all buffers.
                          > > > >
                          > > > >That only works by accident, because your current buffer has more
                          > > > >lines than you have open buffers.
                          > > > >
                          > > > >Or saying it differently, this does not work in an empty buffer.
                          > > > >
                          > > > >So this expectation is not really valid.
                          > > >
                          > > > Er, what you cited implies that it doesn't work at the moment
                          > > > (as expected (by some people (for a long time))).
                          > > >
                          > > > The idea is to make it become valid ...
                          > > >
                          > > > >Marcin Szamotulski wrote:
                          > > > >>There are probably a few other commands that could benefit with a
                          > > > >>similar approach.
                          > > >
                          > > > Got it?
                          > > >
                          > >
                          > > Ah, I thought you wanted to keep the current behaviour, that currently
                          > > %bd already does delete all buffers (but only, if your buffer has enough
                          > > lines).
                          >
                          > Hi,
                          >
                          > So here are updated patches:
                          > count.patch - the counts
                          > argadd.patch - :argadd to be a valid command without and argument (:argadd%)

                          The patch for argadd doesn't take care of everything:
                          - If there are special characters in the current buffer name, these are
                          not handled correctly. buf->b_fname should be added to new_ga
                          directly instead of parsing the string with get_arglist().
                          - If the current buffer does not have a name there should be an error
                          message.

                          Please adjust the patch for that.

                          --
                          hundred-and-one symptoms of being an internet addict:
                          164. You got out to buy software, instead of going out for a beer.

                          /// 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/d/optout.
                        • Bram Moolenaar
                          ... I had a look at the count patch. I don t like the solution much. I think it would work better to add a flag similar to NOTADD that specifies the kind of
                          Message 12 of 17 , Sep 19, 2014
                            Marcin Szamotulski wrote:

                            > On 20:02 Thu 21 Aug , Christian Brabandt wrote:
                            > >
                            > > On Do, 21 Aug 2014, 'Andy Wokula' via vim_dev wrote:
                            > >
                            > > > Am 21.08.2014 um 07:49 schrieb Christian Brabandt:
                            > > > >Am 2014-08-20 19:03, schrieb 'Andy Wokula' via vim_dev:
                            > > > >>Some people expect :1,$bd or :%bd to delete all buffers.
                            > > > >
                            > > > >That only works by accident, because your current buffer has more
                            > > > >lines than you have open buffers.
                            > > > >
                            > > > >Or saying it differently, this does not work in an empty buffer.
                            > > > >
                            > > > >So this expectation is not really valid.
                            > > >
                            > > > Er, what you cited implies that it doesn't work at the moment
                            > > > (as expected (by some people (for a long time))).
                            > > >
                            > > > The idea is to make it become valid ...
                            > > >
                            > > > >Marcin Szamotulski wrote:
                            > > > >>There are probably a few other commands that could benefit with a
                            > > > >>similar approach.
                            > > >
                            > > > Got it?
                            > >
                            > > Ah, I thought you wanted to keep the current behaviour, that currently
                            > > %bd already does delete all buffers (but only, if your buffer has enough
                            > > lines).
                            >
                            > Hi,
                            >
                            > So here are updated patches:
                            > count.patch - the counts
                            > argadd.patch - :argadd to be a valid command without and argument (:argadd%)

                            I had a look at the count patch. I don't like the solution much.

                            I think it would work better to add a flag similar to NOTADD that
                            specifies the kind of count: window number, buffer number, etc. That
                            way there is no need to pass information from where the counts are
                            parsed to where there is a switch on the command. Can use
                            compute_count() directly. First computing counts based on line numbers
                            and then redoing that for something else doesn't seem right.

                            The code that computes the counts looks much too complicated.

                            Please give the tests a name, we stopped using numbers recently.

                            --
                            You're as much use as a condom machine at the Vatican.
                            -- Rimmer to Holly in Red Dwarf 'Queeg'

                            /// 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/d/optout.
                          • Marcin Szamotulski
                            ... I slightly improved the patch, I added NOTLNR to command s flags and now the count is not computed twice. I also refactored the code so it s simpler and I
                            Message 13 of 17 , Nov 8, 2014
                              > I had a look at the count patch. I don't like the solution much.
                              >
                              > I think it would work better to add a flag similar to NOTADD that
                              > specifies the kind of count: window number, buffer number, etc. That
                              > way there is no need to pass information from where the counts are
                              > parsed to where there is a switch on the command. Can use
                              > compute_count() directly. First computing counts based on line numbers
                              > and then redoing that for something else doesn't seem right.
                              >
                              > The code that computes the counts looks much too complicated.
                              >
                              > Please give the tests a name, we stopped using numbers recently.

                              I slightly improved the patch, I added NOTLNR to command's flags and now
                              the count is not computed twice. I also refactored the code so it's
                              simpler and I think easier to follow.

                              Best regards,
                              Marcin
                            • Bram Moolenaar
                              ... Thanks for the update. The code is still quite bulky. What I don t like is first adding NOTLNR and then, when it is set, using a switch on the specific
                              Message 14 of 17 , Nov 12, 2014
                                Marcin Szamotulski wrote:

                                > > I had a look at the count patch. I don't like the solution much.
                                > >
                                > > I think it would work better to add a flag similar to NOTADD that
                                > > specifies the kind of count: window number, buffer number, etc. That
                                > > way there is no need to pass information from where the counts are
                                > > parsed to where there is a switch on the command. Can use
                                > > compute_count() directly. First computing counts based on line numbers
                                > > and then redoing that for something else doesn't seem right.
                                > >
                                > > The code that computes the counts looks much too complicated.
                                > >
                                > > Please give the tests a name, we stopped using numbers recently.
                                >
                                > I slightly improved the patch, I added NOTLNR to command's flags and now
                                > the count is not computed twice. I also refactored the code so it's
                                > simpler and I think easier to follow.

                                Thanks for the update. The code is still quite bulky. What I don't
                                like is first adding NOTLNR and then, when it is set, using a switch on
                                the specific command. There already is NOTADR, which has a similar
                                meaning but would now be a bit different.

                                It's probably better to add a new field in the cmdname struct that
                                specifies the type of range. Like cmd_argt, but with a separate list of
                                values, e.g. ADDR_LNUM, ADDR_WINDOW, etc.

                                Then where the special characters such as "$" are parsed, that flag can
                                be used to decide what the value is: Last line number, highest window
                                number, etc. That avoids having to pass the type around and then later
                                using it.

                                There we can also check for errors. E.g. when the address is
                                "/pattern/" while the command takes a window number.


                                --
                                TIM: Too late.
                                ARTHUR: What?
                                TIM: There he is!
                                [They all turn, and see a large white RABBIT lollop a few yards out of the
                                cave. Accompanied by terrifying chord and jarring metallic monster noise.]
                                "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/d/optout.
                              • Marcin Szamotulski
                                ... I think there is no way of getting rid of `addr_T` struct. The reason is that when the range is parsed we don t yet know what is the command, so we cannot
                                Message 15 of 17 , Nov 22, 2014
                                  On 17:04 Wed 12 Nov , Bram Moolenaar wrote:
                                  >
                                  > Marcin Szamotulski wrote:
                                  >
                                  > > > I had a look at the count patch. I don't like the solution much.
                                  > > >
                                  > > > I think it would work better to add a flag similar to NOTADD that
                                  > > > specifies the kind of count: window number, buffer number, etc. That
                                  > > > way there is no need to pass information from where the counts are
                                  > > > parsed to where there is a switch on the command. Can use
                                  > > > compute_count() directly. First computing counts based on line numbers
                                  > > > and then redoing that for something else doesn't seem right.
                                  > > >
                                  > > > The code that computes the counts looks much too complicated.
                                  > > >
                                  > > > Please give the tests a name, we stopped using numbers recently.
                                  > >
                                  > > I slightly improved the patch, I added NOTLNR to command's flags and now
                                  > > the count is not computed twice. I also refactored the code so it's
                                  > > simpler and I think easier to follow.
                                  >
                                  > Thanks for the update. The code is still quite bulky. What I don't
                                  > like is first adding NOTLNR and then, when it is set, using a switch on
                                  > the specific command. There already is NOTADR, which has a similar
                                  > meaning but would now be a bit different.
                                  >
                                  > It's probably better to add a new field in the cmdname struct that
                                  > specifies the type of range. Like cmd_argt, but with a separate list of
                                  > values, e.g. ADDR_LNUM, ADDR_WINDOW, etc.
                                  >
                                  > Then where the special characters such as "$" are parsed, that flag can
                                  > be used to decide what the value is: Last line number, highest window
                                  > number, etc. That avoids having to pass the type around and then later
                                  > using it.
                                  >
                                  > There we can also check for errors. E.g. when the address is
                                  > "/pattern/" while the command takes a window number.

                                  I think there is no way of getting rid of `addr_T` struct. The reason
                                  is that when the range is parsed we don't yet know what is the command,
                                  so we cannot use ADDR_LNUM, ADDR_WINDOW yet. You're right though that
                                  `NOTLNT` wasn't a good idea. What I suggest that we first parse the
                                  range into `addr_T` structs, without setting the `ea.line1` and
                                  `ea.line2`; after parsing the range we know which command runs (what is
                                  checked by `find_command` at this point and now we can set `ea.line1` and `ea.line2`
                                  since we will now which of `ADDR_LNUM`, ... should be used. It can be
                                  done using the function I wrote `compute_count`. At this place we will
                                  be able to handle errors as well.

                                  I will write a patch for that if you don't have any objections.

                                  Best regards,
                                  Marcin

                                  --
                                  --
                                  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/d/optout.
                                • Bram Moolenaar
                                  ... Right, the range comes before the command, thus we don t know what to do with the range when first encountering it. So we basically have two alternatives:
                                  Message 16 of 17 , Nov 22, 2014
                                    Marcin Szamotulski wrote:

                                    > On 17:04 Wed 12 Nov , Bram Moolenaar wrote:
                                    > >
                                    > > Marcin Szamotulski wrote:
                                    > >
                                    > > > > I had a look at the count patch. I don't like the solution much.
                                    > > > >
                                    > > > > I think it would work better to add a flag similar to NOTADD that
                                    > > > > specifies the kind of count: window number, buffer number, etc. That
                                    > > > > way there is no need to pass information from where the counts are
                                    > > > > parsed to where there is a switch on the command. Can use
                                    > > > > compute_count() directly. First computing counts based on line numbers
                                    > > > > and then redoing that for something else doesn't seem right.
                                    > > > >
                                    > > > > The code that computes the counts looks much too complicated.
                                    > > > >
                                    > > > > Please give the tests a name, we stopped using numbers recently.
                                    > > >
                                    > > > I slightly improved the patch, I added NOTLNR to command's flags and now
                                    > > > the count is not computed twice. I also refactored the code so it's
                                    > > > simpler and I think easier to follow.
                                    > >
                                    > > Thanks for the update. The code is still quite bulky. What I don't
                                    > > like is first adding NOTLNR and then, when it is set, using a switch on
                                    > > the specific command. There already is NOTADR, which has a similar
                                    > > meaning but would now be a bit different.
                                    > >
                                    > > It's probably better to add a new field in the cmdname struct that
                                    > > specifies the type of range. Like cmd_argt, but with a separate list of
                                    > > values, e.g. ADDR_LNUM, ADDR_WINDOW, etc.
                                    > >
                                    > > Then where the special characters such as "$" are parsed, that flag can
                                    > > be used to decide what the value is: Last line number, highest window
                                    > > number, etc. That avoids having to pass the type around and then later
                                    > > using it.
                                    > >
                                    > > There we can also check for errors. E.g. when the address is
                                    > > "/pattern/" while the command takes a window number.
                                    >
                                    > I think there is no way of getting rid of `addr_T` struct. The reason
                                    > is that when the range is parsed we don't yet know what is the command,
                                    > so we cannot use ADDR_LNUM, ADDR_WINDOW yet. You're right though that
                                    > `NOTLNT` wasn't a good idea. What I suggest that we first parse the
                                    > range into `addr_T` structs, without setting the `ea.line1` and
                                    > `ea.line2`; after parsing the range we know which command runs (what is
                                    > checked by `find_command` at this point and now we can set `ea.line1`
                                    > and `ea.line2` since we will now which of `ADDR_LNUM`, ... should be
                                    > used. It can be done using the function I wrote `compute_count`. At
                                    > this place we will be able to handle errors as well.
                                    >
                                    > I will write a patch for that if you don't have any objections.

                                    Right, the range comes before the command, thus we don't know what to
                                    do with the range when first encountering it.

                                    So we basically have two alternatives:
                                    1. What you say: parse the range and store it in some intermediate form,
                                    then parse the command and once we know the type of rnage we can
                                    compute the actual range.
                                    2. Go over the range twice: Once to skip over it and find the command,
                                    then a second time when we know the command, and thus how to compute
                                    the actual range.

                                    I would argue the second solution is better. We do not need to come up
                                    with an intermediate format, with new symbols and stuff. Also, we do
                                    not need to store anything in the first round. The disadvantage is
                                    having to parse twice, but that should be fast and we can use the same
                                    code: A function that skips over the actual computation in the first
                                    round.

                                    How about that?

                                    --
                                    Violators can be fined, arrested or jailed for making ugly faces at a dog.
                                    [real standing law in Oklahoma, United States of America]

                                    /// 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/d/optout.
                                  • Marcin Szamotulski
                                    ... Sounds good. I will go with the second solution. Best regards, Marcin -- -- You received this message from the vim_dev maillist. Do not top-post! Type
                                    Message 17 of 17 , Nov 22, 2014
                                      On 18:48 Sat 22 Nov , Bram Moolenaar wrote:
                                      >
                                      > Marcin Szamotulski wrote:
                                      >
                                      > > On 17:04 Wed 12 Nov , Bram Moolenaar wrote:
                                      > > >
                                      > > > Marcin Szamotulski wrote:
                                      > > >
                                      > > > > > I had a look at the count patch. I don't like the solution much.
                                      > > > > >
                                      > > > > > I think it would work better to add a flag similar to NOTADD that
                                      > > > > > specifies the kind of count: window number, buffer number, etc. That
                                      > > > > > way there is no need to pass information from where the counts are
                                      > > > > > parsed to where there is a switch on the command. Can use
                                      > > > > > compute_count() directly. First computing counts based on line numbers
                                      > > > > > and then redoing that for something else doesn't seem right.
                                      > > > > >
                                      > > > > > The code that computes the counts looks much too complicated.
                                      > > > > >
                                      > > > > > Please give the tests a name, we stopped using numbers recently.
                                      > > > >
                                      > > > > I slightly improved the patch, I added NOTLNR to command's flags and now
                                      > > > > the count is not computed twice. I also refactored the code so it's
                                      > > > > simpler and I think easier to follow.
                                      > > >
                                      > > > Thanks for the update. The code is still quite bulky. What I don't
                                      > > > like is first adding NOTLNR and then, when it is set, using a switch on
                                      > > > the specific command. There already is NOTADR, which has a similar
                                      > > > meaning but would now be a bit different.
                                      > > >
                                      > > > It's probably better to add a new field in the cmdname struct that
                                      > > > specifies the type of range. Like cmd_argt, but with a separate list of
                                      > > > values, e.g. ADDR_LNUM, ADDR_WINDOW, etc.
                                      > > >
                                      > > > Then where the special characters such as "$" are parsed, that flag can
                                      > > > be used to decide what the value is: Last line number, highest window
                                      > > > number, etc. That avoids having to pass the type around and then later
                                      > > > using it.
                                      > > >
                                      > > > There we can also check for errors. E.g. when the address is
                                      > > > "/pattern/" while the command takes a window number.
                                      > >
                                      > > I think there is no way of getting rid of `addr_T` struct. The reason
                                      > > is that when the range is parsed we don't yet know what is the command,
                                      > > so we cannot use ADDR_LNUM, ADDR_WINDOW yet. You're right though that
                                      > > `NOTLNT` wasn't a good idea. What I suggest that we first parse the
                                      > > range into `addr_T` structs, without setting the `ea.line1` and
                                      > > `ea.line2`; after parsing the range we know which command runs (what is
                                      > > checked by `find_command` at this point and now we can set `ea.line1`
                                      > > and `ea.line2` since we will now which of `ADDR_LNUM`, ... should be
                                      > > used. It can be done using the function I wrote `compute_count`. At
                                      > > this place we will be able to handle errors as well.
                                      > >
                                      > > I will write a patch for that if you don't have any objections.
                                      >
                                      > Right, the range comes before the command, thus we don't know what to
                                      > do with the range when first encountering it.
                                      >
                                      > So we basically have two alternatives:
                                      > 1. What you say: parse the range and store it in some intermediate form,
                                      > then parse the command and once we know the type of rnage we can
                                      > compute the actual range.
                                      > 2. Go over the range twice: Once to skip over it and find the command,
                                      > then a second time when we know the command, and thus how to compute
                                      > the actual range.
                                      >
                                      > I would argue the second solution is better. We do not need to come up
                                      > with an intermediate format, with new symbols and stuff. Also, we do
                                      > not need to store anything in the first round. The disadvantage is
                                      > having to parse twice, but that should be fast and we can use the same
                                      > code: A function that skips over the actual computation in the first
                                      > round.
                                      >
                                      > How about that?

                                      Sounds good. I will go with the second solution.

                                      Best regards,
                                      Marcin

                                      --
                                      --
                                      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/d/optout.
                                    Your message has been successfully submitted and would be delivered to recipients shortly.