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

Re: % matching for Python

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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.