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

% matching for Python

Expand Messages
  • Benji Fisher
    Python users: I decided that matchit.vim is not the answer to everything, so I wrote the attached script to do % matching based on indent in Python files. You
    Message 1 of 16 , Aug 5, 2002
    • 0 Attachment
      Python users:

      I decided that matchit.vim is not the answer to everything, so I wrote the
      attached script to do % matching based on indent in Python files. You can add
      this to your ftplugin/ directory with its current name (python_match.vim) or put
      it in ftplugin/python/ or :source it from your ftplugin/python.vim file. It
      implements the following motion commands:

      [% Go to the start of the current block. If currently at the start of a
      block, move to the start of the enclosing block.

      ]% Go to the end of the current block. If currently at the start of a
      block, move to the end of that block.

      % Use the default behavior if on a comment line, not on the first WORD,
      or not on the start or end of a block. If on the first WORD of the
      first (last) line of a block, move to the start of the last (first)
      line of the block.

      Please test this and send me your comments. Note:

      * I recognize a comment as starting with #. Are there other comments in Python?

      * I decide I am at the start of a block if the next line (ignoring comment
      lines) has larger indent. I decide I am at the end of a block if the next line
      (ignoring comment lines) has smaller indent.

      * An empty line has zero indent. In particular, it ends any block.

      * I use indent() to get the indent of a line. I am not sure how Python treats
      tabs and spaces; is there a better way than indent()?

      * How should [% and ]% act on comment lines?

      * Do you want any of these keys to act differently? Should one of these (or an
      additional key) move to the start of the next block rather than the end of the
      current one, for example? Should I modify the behavior when at the start or end
      of a block?

      --Benji Fisher
    • Bram Moolenaar
      ... I m afraid this is not really the kind of behavior I expect from % . I would expect it go to over if/elif/else and try/except/finally constructs. While
      Message 2 of 16 , Aug 5, 2002
      • 0 Attachment
        Benji Fisher wrote:

        > Python users:
        >
        > I decided that matchit.vim is not the answer to everything, so I
        > wrote the attached script to do % matching based on indent in Python
        > files. You can add this to your ftplugin/ directory with its current
        > name (python_match.vim) or put it in ftplugin/python/ or :source it
        > from your ftplugin/python.vim file. It implements the following
        > motion commands:

        I'm afraid this is not really the kind of behavior I expect from "%". I
        would expect it go to over if/elif/else and try/except/finally
        constructs. While checking the indent, of course.

        I'm using mappings for [[ and ]] to move over functions and [{ and ]} to
        move to the start/end of a block. See below.

        > [% Go to the start of the current block. If currently at the start of a
        > block, move to the start of the enclosing block.
        >
        > ]% Go to the end of the current block. If currently at the start of a
        > block, move to the end of that block.

        These get stuck at an empty line. That's not where a block ends, thus I
        wouldn't want this to happen.

        > * I use indent() to get the indent of a line. I am not sure how Python treats
        > tabs and spaces; is there a better way than indent()?

        I think Python always uses a tabstop of eight, nobody should edit a
        Python file with a tabstop unequal 8 anyway. indent() matches with what
        you see on the screen, thus it should work well.


        Here are the mappings and functions I'm currently using:

        nnoremap <silent> <buffer> ]] :call <SID>Python_jump('/^\(class\\|def\)')<cr>
        nnoremap <silent> <buffer> [[ :call <SID>Python_jump('?^\(class\\|def\)')<cr>
        nnoremap <silent> <buffer> ]m :call <SID>Python_jump('/^\s*\(class\\|def\)')<cr>
        nnoremap <silent> <buffer> [m :call <SID>Python_jump('?^\s*\(class\\|def\)')<cr>

        if exists('*<SID>Python_jump') | finish | endif

        fun! <SID>Python_jump(motion) range
        let cnt = v:count1
        let save = @/ " save last search pattern
        mark '
        while cnt > 0
        silent! exe a:motion
        let cnt = cnt - 1
        endwhile
        call histdel('/', -1)
        let @/ = save " restore last search pattern
        endfun

        nnoremap <silent> <buffer> ]} :call <SID>Python_find(1)<cr>
        nnoremap <silent> <buffer> [{ :call <SID>Python_find(-1)<cr>

        fun! <SID>Python_find(add)
        let lnum = line(".")
        let indent = indent(lnum)
        while 1
        let lnum = lnum + a:add
        if lnum < 1 || lnum > line("$")
        return
        endif
        if indent(lnum) < indent && getline(lnum) =~ '\S'
        break
        endif
        endwhile
        exe lnum
        endfun



        --
        hundred-and-one symptoms of being an internet addict:
        107. When using your phone you forget that you don't have to use your
        keyboard.

        /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
        /// Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim \\\
        \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
        \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
      • Alejandro López-Valencia
        ... Actually a tabstop of four. The style guide (PEP 8, check http://www.python.org/doc/pep/ if I remember the address correctly) declares: Use an indent of
        Message 3 of 16 , Aug 5, 2002
        • 0 Attachment
          Bram Moolenaar wrote:
          >
          > I think Python always uses a tabstop of eight, nobody should edit a
          > Python file with a tabstop unequal 8 anyway. indent() matches with
          > what you see on the screen, thus it should work well.
          >
          >

          Actually a tabstop of four. The style guide (PEP 8, check
          http://www.python.org/doc/pep/ if I remember the address correctly)
          declares: Use an indent of four and never mix tabs and spaces in the same
          file. That is, the default python indention plugin should set
          tabstop=shiftwidth=4 and expandtab as the default; trying to use tabs
          usually leads to madness and weird runtime errors because the bytecode
          compiler ends up guessing things that aren't.
        • David Brown
          ... PEP8 specifies an indent of 4, and highly recommends using only spaces for indenting. It explicitly states that spaces and tabs should never be mixed. The
          Message 4 of 16 , Aug 5, 2002
          • 0 Attachment
            On Mon, Aug 05, 2002 at 04:04:18PM -0500, Alejandro L?pez-Valencia wrote:
            > Bram Moolenaar wrote:
            > >
            > > I think Python always uses a tabstop of eight, nobody should edit a
            > > Python file with a tabstop unequal 8 anyway. indent() matches with
            > > what you see on the screen, thus it should work well.
            >
            > Actually a tabstop of four. The style guide (PEP 8, check
            > http://www.python.org/doc/pep/ if I remember the address correctly)
            > declares: Use an indent of four and never mix tabs and spaces in the same
            > file. That is, the default python indention plugin should set
            > tabstop=shiftwidth=4 and expandtab as the default; trying to use tabs
            > usually leads to madness and weird runtime errors because the bytecode
            > compiler ends up guessing things that aren't.

            PEP8 specifies an indent of 4, and highly recommends using only spaces
            for indenting. It explicitly states that spaces and tabs should never
            be mixed.

            The Python language always has the tabstops at 8. Setting tabstop to a
            value other than 8 can easily cause code to break in python (although
            you will probably do ok, if the shiftwidth is also the same value).

            To comply with the PEP 8, you should set shiftwidth=4 and noexpandtab.

            Dave Brown
          • Bram Moolenaar
            ... That s: http://www.python.org/peps/pep-0008.html ... As I read it this PEP suggests using expandtab . However, I m mixing tabs and spaces (e.g., one tab
            Message 5 of 16 , Aug 6, 2002
            • 0 Attachment
              David Brown wrote:

              > On Mon, Aug 05, 2002 at 04:04:18PM -0500, Alejandro L?pez-Valencia wrote:
              > > Bram Moolenaar wrote:
              > > >
              > > > I think Python always uses a tabstop of eight, nobody should edit a
              > > > Python file with a tabstop unequal 8 anyway. indent() matches with
              > > > what you see on the screen, thus it should work well.
              > >
              > > Actually a tabstop of four. The style guide (PEP 8, check
              > > http://www.python.org/doc/pep/ if I remember the address correctly)

              That's: http://www.python.org/peps/pep-0008.html

              > > declares: Use an indent of four and never mix tabs and spaces in the same
              > > file. That is, the default python indention plugin should set
              > > tabstop=shiftwidth=4 and expandtab as the default; trying to use tabs
              > > usually leads to madness and weird runtime errors because the bytecode
              > > compiler ends up guessing things that aren't.
              >
              > PEP8 specifies an indent of 4, and highly recommends using only spaces
              > for indenting. It explicitly states that spaces and tabs should never
              > be mixed.
              >
              > The Python language always has the tabstops at 8. Setting tabstop to a
              > value other than 8 can easily cause code to break in python (although
              > you will probably do ok, if the shiftwidth is also the same value).
              >
              > To comply with the PEP 8, you should set shiftwidth=4 and noexpandtab.

              As I read it this PEP suggests using 'expandtab'. However, I'm mixing
              tabs and spaces (e.g., one tab and four spaces for three indent levels)
              and haven't had any problem with this. Just make sure 'tabstop' isn't
              changed from its default value of 8.

              --
              An actual excerpt from a classified section of a city newspaper:
              "Illiterate? Write today for free help!"

              /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
              /// Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim \\\
              \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
              \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
            • Alejandro López-Valencia
              ... Hmm... I think that s fine if you don t expect your code to be read, much less edited, by anyone else, mixing tabs and spaces that is :). Unless you jot
              Message 6 of 16 , Aug 6, 2002
              • 0 Attachment
                Bram Moolenaar wrote:
                > David Brown wrote:
                >
                >> On Mon, Aug 05, 2002 at 04:04:18PM -0500, Alejandro L?pez-Valencia
                >> wrote:
                >>> Bram Moolenaar wrote:
                >>>>
                >>>> I think Python always uses a tabstop of eight, nobody should edit a
                >>>> Python file with a tabstop unequal 8 anyway. indent() matches with
                >>>> what you see on the screen, thus it should work well.
                >>>
                >>> Actually a tabstop of four. The style guide (PEP 8, check
                >>> http://www.python.org/doc/pep/ if I remember the address correctly)
                >
                > That's: http://www.python.org/peps/pep-0008.html
                >
                >>> declares: Use an indent of four and never mix tabs and spaces in
                >>> the same file. That is, the default python indention plugin should
                >>> set tabstop=shiftwidth=4 and expandtab as the default; trying to
                >>> use tabs usually leads to madness and weird runtime errors because
                >>> the bytecode compiler ends up guessing things that aren't.
                >>
                >> PEP8 specifies an indent of 4, and highly recommends using only
                >> spaces for indenting. It explicitly states that spaces and tabs
                >> should never be mixed.
                >>
                >> The Python language always has the tabstops at 8. Setting tabstop to
                >> a value other than 8 can easily cause code to break in python
                >> (although you will probably do ok, if the shiftwidth is also the
                >> same value).
                >>
                >> To comply with the PEP 8, you should set shiftwidth=4 and
                >> noexpandtab.
                >
                > As I read it this PEP suggests using 'expandtab'. However, I'm mixing
                > tabs and spaces (e.g., one tab and four spaces for three indent
                > levels) and haven't had any problem with this. Just make sure
                > 'tabstop' isn't changed from its default value of 8.

                Hmm... I think that's fine if you don't expect your code to be read, much
                less edited, by anyone else, mixing tabs and spaces that is :). Unless you
                jot down somewhere in the file what kind of scheme you use.

                What I can say from personal experience is that I've had no joy trying to
                fix other people's code that had exotic indention patterns such as yours.
                Even after running pyindent.py and tabindent.py on those 2000+ LOC files,
                fixing them to not only compile but also work as expected wasn't fun at all.
                My point is that python has syntactical and orthographical regularity.
                Unlike C and C++, where indention is a matter of spiritual persuasion and
                the appearance of jihads and holy crusades among the different opinions are
                a fact of life (children!), there are clear rules for python and those
                should be the default. This way, newbies get the expected style
                transparently and those who already have a mental perversion about the
                matter, well..., we can fix it to our liking.
              • Benji Fisher
                ... My second attempt is attached. It should work on if/elif/else and try/except/finally . Should I make it ignore case? Are there other matching
                Message 7 of 16 , Aug 6, 2002
                • 0 Attachment
                  Bram Moolenaar wrote:
                  >
                  > I'm afraid this is not really the kind of behavior I expect from "%". I
                  > would expect it go to over if/elif/else and try/except/finally
                  > constructs. While checking the indent, of course.

                  My second attempt is attached. It should work on if/elif/else and
                  try/except/finally . Should I make it ignore case? Are there other matching
                  constructs? Should % do anything on a for or while line?

                  The :omap's probably do not yet work well. Not much point fixing that
                  until I make the motions more useful...

                  > I'm using mappings for [[ and ]] to move over functions and [{ and ]} to
                  > move to the start/end of a block. See below.

                  It looks as though your [{ is similar to my [%. Your ]} goes to the start
                  of the next block, rather than the end of the current one. I suppose that is
                  more useful. You do not check for comments; is this legal in Python?

                  # This is a very long comment so I started it at the left margin even though
                  # it is in the middle of a triply-indented block

                  > > [% Go to the start of the current block. If currently at the start of a
                  > > block, move to the start of the enclosing block.
                  > >
                  > > ]% Go to the end of the current block. If currently at the start of a
                  > > block, move to the end of that block.
                  >
                  > These get stuck at an empty line. That's not where a block ends, thus I
                  > wouldn't want this to happen.

                  Are empty lines comments, or do they end all blocks? What behavior would
                  be more useful? Perhaps, if the cursor starts on an empty line, these should
                  first move to the next (up for [%, down for ]%) non-empty, non-comment line?

                  > > * I use indent() to get the indent of a line. I am not sure how Python treats
                  > > tabs and spaces; is there a better way than indent()?
                  >
                  > I think Python always uses a tabstop of eight, nobody should edit a
                  > Python file with a tabstop unequal 8 anyway. indent() matches with what
                  > you see on the screen, thus it should work well.

                  I'll trust indent(). I see there has been some discussion of this...

                  --Benji Fisher
                • David Brown
                  ... That s why the PEP8 specifies to use spaces instead of tabs. However, Python was designed to accept tabs as equivalent to spaces, but _ALWAYS_ with a
                  Message 8 of 16 , Aug 6, 2002
                  • 0 Attachment
                    On Tue, Aug 06, 2002 at 07:51:41AM -0500, Alejandro L?pez-Valencia wrote:

                    > What I can say from personal experience is that I've had no joy trying to
                    > fix other people's code that had exotic indention patterns such as yours.
                    > Even after running pyindent.py and tabindent.py on those 2000+ LOC files,
                    > fixing them to not only compile but also work as expected wasn't fun at all.
                    > My point is that python has syntactical and orthographical regularity.
                    > Unlike C and C++, where indention is a matter of spiritual persuasion and
                    > the appearance of jihads and holy crusades among the different opinions are
                    > a fact of life (children!), there are clear rules for python and those
                    > should be the default. This way, newbies get the expected style
                    > transparently and those who already have a mental perversion about the
                    > matter, well..., we can fix it to our liking.

                    That's why the PEP8 specifies to use spaces instead of tabs. However,
                    Python was designed to accept tabs as equivalent to spaces, but _ALWAYS_
                    with a tabstop set to 8. It is the setting of the tabstop to a value of
                    other than 8 (common for non *nix editors) that can bite. Even with the
                    tabstop set wrong, often you get lucky and things just work, especially
                    if indenting is only done with tabs.

                    My main reaction was to the suggestion to set the tabstop to 4 for
                    python code. This is going to bite someone someday. The default for
                    python, according to PEP8 should be

                    shiftwidth=4
                    tabstop=8
                    expandtab

                    If you expect less to be able to share files with users of inconsistent
                    editors,

                    shiftwidth=4
                    tabstop=8
                    noexpandtab

                    will work fine, it fits exactly what python wants. However, it may make
                    the code look weird if someone has a non-standard tabstop setting.

                    tabstop should never be set to anything other than 8 when working on
                    Python code. The Python lexer expands tabs to 8 spaces, so if you do
                    differently, there will be a mismatch between what python sees and what
                    is visible on the screen.

                    Dave
                  • Alejandro López-Valencia
                    On Tuesday, August 06, 2002 10:56 AM, ... The conflict you point out is a consequence of making shiftwidth different to tabstop, now, that, is asking for real
                    Message 9 of 16 , Aug 6, 2002
                    • 0 Attachment
                      On Tuesday, August 06, 2002 10:56 AM,
                      David Brown <vim@...> about the unbearable subtleness of being wrote:

                      >
                      > That's why the PEP8 specifies to use spaces instead of tabs. However,
                      > Python was designed to accept tabs as equivalent to spaces, but
                      > _ALWAYS_ with a tabstop set to 8. It is the setting of the tabstop
                      > to a value of other than 8 (common for non *nix editors) that can
                      > bite. Even with the tabstop set wrong, often you get lucky and
                      > things just work, especially if indenting is only done with tabs.
                      >
                      > My main reaction was to the suggestion to set the tabstop to 4 for
                      > python code. This is going to bite someone someday. The default for
                      > python, according to PEP8 should be
                      >
                      > shiftwidth=4
                      > tabstop=8
                      > expandtab

                      The conflict you point out is a consequence of making shiftwidth different
                      to tabstop, now, that, is asking for real trouble. :)

                      I prefer

                      shiftwidth=4
                      tabstop=4
                      expandtab

                      because it works and is portable at the same time. That is, it works fine
                      with new files and with files that are properly indented, that is, where the
                      creator has either used spaces (and one can therefore figure out his/her
                      perverted idea of how many spaces is an indent and adjust accordingly) or
                      uses one tab per indention level *and* no space-tabs mixing for indention.

                      As well, if one chooses to forgo the expandtab setting and use tabs instead
                      of spaces, the file is still readable under a text editor that only manages
                      8 space tabstops (because most of those can't change shiftwidth neither);
                      and the python bytecode compiler will do the right thing as well.
                    • Bram Moolenaar
                      ... This appears to work reasonably well. One problem: an empty line in between the if and else stops it from working. ... No, Python is case sensitive.
                      Message 10 of 16 , Aug 6, 2002
                      • 0 Attachment
                        Benji Fisher wrote:

                        > My second attempt is attached. It should work on if/elif/else and
                        > try/except/finally .

                        This appears to work reasonably well. One problem: an empty line in
                        between the "if" and "else" stops it from working.

                        > Should I make it ignore case?

                        No, Python is case sensitive.

                        > Are there other matching constructs? Should % do anything on a for or
                        > while line?

                        I wouldn't know what to do with "%" on a "for" or "while". Better leave
                        it alone, so that it looks for the first ( or [ to be matched.

                        > It looks as though your [{ is similar to my [%. Your ]} goes to
                        > the start of the next block, rather than the end of the current one.
                        > I suppose that is more useful.

                        I didn't really make a choice for this. Finding the last line with a
                        certain indent before one with less indent was a bit more complicated to
                        implement. The two positions are very close, for moving around it
                        doesn't matter much. However, for deleting a block with "d]}" it would
                        be better to go to the end of the block, not to the start of the next
                        one.

                        > You do not check for comments; is this legal in Python?
                        >
                        > # This is a very long comment so I started it at the left margin even though
                        > # it is in the middle of a triply-indented block

                        Yes, comments are ignored. It's like the whole comment wasn't there,
                        the indent doesn't matter.

                        > Are empty lines comments, or do they end all blocks? What
                        > behavior would be more useful? Perhaps, if the cursor starts on an
                        > empty line, these should first move to the next (up for [%, down for
                        > ]%) non-empty, non-comment line?

                        Empty lines are ignored. When starting on an empty line I think the
                        indent of the next line should be used. Although the previous line
                        would be useful in some situations, but you can't guess this.

                        > I'll trust indent(). I see there has been some discussion of this...

                        Space invaders!

                        --
                        I have a watch cat! Just break in and she'll watch.

                        /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                        /// Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim \\\
                        \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
                        \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
                      • Bram Moolenaar
                        ... If someone uses a tabstop setting different from 8 for Python code, then he is in trouble. Not because of my use of tabs, but because he is using a wrong
                        Message 11 of 16 , Aug 6, 2002
                        • 0 Attachment
                          Alejandro Valencia wrote:

                          > > As I read it this PEP suggests using 'expandtab'. However, I'm mixing
                          > > tabs and spaces (e.g., one tab and four spaces for three indent
                          > > levels) and haven't had any problem with this. Just make sure
                          > > 'tabstop' isn't changed from its default value of 8.
                          >
                          > Hmm... I think that's fine if you don't expect your code to be read, much
                          > less edited, by anyone else, mixing tabs and spaces that is :). Unless you
                          > jot down somewhere in the file what kind of scheme you use.

                          If someone uses a tabstop setting different from 8 for Python code, then
                          he is in trouble. Not because of my use of tabs, but because he is
                          using a wrong tabstop. Hopefully someone who uses a different tabstop
                          setting runs into enough problems to teach him not to do it.
                          Perhaps using tabs to teach someone a lesson is not really the right
                          thing to do...

                          --
                          hundred-and-one symptoms of being an internet addict:
                          125. You begin to wonder how often it REALLY is necessary to get up
                          and shower or bathe.

                          /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                          /// Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim \\\
                          \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
                          \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
                        • Benji Fisher
                          ... See below. ... Good. That is what the script does now (I think). ... OK. When I get the :omap s working properly, I ll test this. ... I did not actually
                          Message 12 of 16 , Aug 6, 2002
                          • 0 Attachment
                            Bram Moolenaar wrote:
                            >
                            > Benji Fisher wrote:
                            >
                            > > My second attempt is attached. It should work on if/elif/else and
                            > > try/except/finally .
                            >
                            > This appears to work reasonably well. One problem: an empty line in
                            > between the "if" and "else" stops it from working.

                            See below.

                            > > Are there other matching constructs? Should % do anything on a for or
                            > > while line?
                            >
                            > I wouldn't know what to do with "%" on a "for" or "while". Better leave
                            > it alone, so that it looks for the first ( or [ to be matched.

                            Good. That is what the script does now (I think).

                            > > It looks as though your [{ is similar to my [%. Your ]} goes to
                            > > the start of the next block, rather than the end of the current one.
                            > > I suppose that is more useful.
                            >
                            > I didn't really make a choice for this. Finding the last line with a
                            > certain indent before one with less indent was a bit more complicated to
                            > implement. The two positions are very close, for moving around it
                            > doesn't matter much. However, for deleting a block with "d]}" it would
                            > be better to go to the end of the block, not to the start of the next
                            > one.

                            OK. When I get the :omap's working properly, I'll test this.

                            > > You do not check for comments; is this legal in Python?
                            > >
                            > > # This is a very long comment so I started it at the left margin even though
                            > > # it is in the middle of a triply-indented block
                            >
                            > Yes, comments are ignored. It's like the whole comment wasn't there,
                            > the indent doesn't matter.

                            I did not actually test it, but I think that comments like the above will
                            attract your [{ and ]} mappings.

                            > > Are empty lines comments, or do they end all blocks? What
                            > > behavior would be more useful? Perhaps, if the cursor starts on an
                            > > empty line, these should first move to the next (up for [%, down for
                            > > ]%) non-empty, non-comment line?
                            >
                            > Empty lines are ignored. When starting on an empty line I think the
                            > indent of the next line should be used. Although the previous line
                            > would be useful in some situations, but you can't guess this.

                            I will treat empty lines like comments, and (with [% and ]%) start by
                            moving to the next non-comment line. Are blank lines also treated like empty
                            lines? I will guess that they are. (Easy enough to fix if I get it wrong.)

                            Only small changes for now. Unless someone wants to see it, I will not
                            post my next version until the :omap's work, maybe tomorrow.

                            --Benji Fisher
                          • Benji Fisher
                            ... [snip] ... I changed my mind; the changes were not so minor. Especially, since I now treat empty lines as comments, I revised my idea of what starts a new
                            Message 13 of 16 , Aug 6, 2002
                            • 0 Attachment
                              Benji Fisher wrote:
                              >
                              [snip]
                              > Only small changes for now. Unless someone wants to see it, I will not
                              > post my next version until the :omap's work, maybe tomorrow.

                              I changed my mind; the changes were not so minor. Especially, since I now
                              treat empty lines as comments, I revised my idea of what starts a new block.
                              (In the example Python script I was looking at, there were empty lines
                              separating blocks. I assumed that, having indent 0, they indicated the
                              top-level block.) I now assume that in

                              foo
                              ...
                              bar
                              ...

                              (where foo and bar have the same indent) then "bar" starts a new block unless it
                              is recognized as a continuation: for example, if "foo" is "if" and "bar" is
                              "elif" or "else".

                              Please test this version with nested blocks, non-aligned comment lines,
                              empty (and blank) lines, etc. If you like it, I will add the :omap's tomorrow.

                              --Benji Fisher
                            • Alejandro López-Valencia
                              On Tuesday, August 06, 2002 12:18 PM, Alejandro López-Valencia wrote referring to the ... Giving the issue a bit more thought last
                              Message 14 of 16 , Aug 7, 2002
                              • 0 Attachment
                                On Tuesday, August 06, 2002 12:18 PM,
                                Alejandro López-Valencia <dradul@...> wrote referring to the
                                unbearable subtleness of being:

                                >
                                > I prefer
                                >
                                > shiftwidth=4
                                > tabstop=4
                                > expandtab
                                >
                                > because it works and is portable at the same time.

                                Giving the issue a bit more thought last night, and judicious reading of the
                                doc pages, I have come to a little realization (in the same level as when I
                                learned to tie my shoelaces :). I can safely leave tabstop at 8 if I set
                                softtabstop at 4. But, of course, the trouble starts when another poor sould
                                reads my code and I have forgotten to use expandtab everywhere and/or retab
                                all the files to spaces...
                              • Bram Moolenaar
                                ... Much better. But one fix is required: fun! NonComment(inc, ...) Should be: fun! s:NonComment(inc, ...) -- hundred-and-one symptoms of being an internet
                                Message 15 of 16 , Aug 7, 2002
                                • 0 Attachment
                                  Benji Fisher wrote:

                                  > I changed my mind; the changes were not so minor. Especially, since I now
                                  > treat empty lines as comments, I revised my idea of what starts a new block.
                                  > (In the example Python script I was looking at, there were empty lines
                                  > separating blocks. I assumed that, having indent 0, they indicated the
                                  > top-level block.) I now assume that in
                                  >
                                  > foo
                                  > ...
                                  > bar
                                  > ...
                                  >
                                  > (where foo and bar have the same indent) then "bar" starts a new block
                                  > unless it is recognized as a continuation: for example, if "foo" is
                                  > "if" and "bar" is "elif" or "else".
                                  >
                                  > Please test this version with nested blocks, non-aligned comment
                                  > lines, empty (and blank) lines, etc. If you like it, I will add the
                                  > :omap's tomorrow.

                                  Much better. But one fix is required:

                                  fun! NonComment(inc, ...)

                                  Should be:

                                  fun! s:NonComment(inc, ...)

                                  --
                                  hundred-and-one symptoms of being an internet addict:
                                  137. You decide to stay in college for an additional year or two,
                                  just so you can have the free Internet access.

                                  /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                                  /// Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim \\\
                                  \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
                                  \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
                                • Benji Fisher
                                  ... Here is the latest version of my Python %-matching script. Please test it as described above, and also test it in Visual and Operator-pending mode. For
                                  Message 16 of 16 , Aug 15, 2002
                                  • 0 Attachment
                                    Benji Fisher wrote:
                                    >
                                    > Please test this version with nested blocks, non-aligned comment lines,
                                    > empty (and blank) lines, etc. If you like it, I will add the :omap's tomorrow.

                                    Here is the latest version of my Python %-matching script. Please test it
                                    as described above, and also test it in Visual and Operator-pending mode. For
                                    example, "d]%" should do what you want it to. (If it does not, tell me how you
                                    would like it to act.) Again, this script implements the following motions:

                                    % and g%: cycle (backwards) through if/elif/else and try/except/catch
                                    structures

                                    [%: go to the start of the current block

                                    ]%: go to the end of the current block

                                    My latest change was to modify the behavior of ]% when the cursor does not start
                                    on one of the key words listed above.

                                    I will be off-line for a week, starting in two days.

                                    --Benji Fisher
                                  Your message has been successfully submitted and would be delivered to recipients shortly.