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

Fwd: Patch: Fix wrong 'iskeyword' treatment in xmlcomplete.vim

Expand Messages
  • Kana Natsuno
    I found a problematic behavior in xmlcomplete.vim a few years ago. I wrote a patch to fix it and sent to the maintainer, but I ve never got any reply. So that
    Message 1 of 2 , Jun 29, 2013
    • 0 Attachment
      I found a problematic behavior in xmlcomplete.vim a few years ago.
      I wrote a patch to fix it and sent to the maintainer, but I've never
      got any reply.
      So that I send the patch to here.


      ---------- Forwarded message ----------
      From: Kana Natsuno <kana@...>
      Date: Fri, Apr 9, 2010 at 11:33 PM
      Subject: Patch: Fix wrong 'iskeyword' treatment in xmlcomplete.vim
      To: Mikolaj Machowski <mikmach@...>


      Hello,

      I found a bug in xmlcomplete.vim which is bundled as the standard
      runtime files of Vim. s:SetKeywords() and s:RestoreKeywords() have
      a side effect that the global value of 'iskeyword' is overridden.

      For example, s:Instack() in xmlcomplete.vim is defined as follows:

      function! s:Instack(el, sname)
      exe 'let stack='.a:sname " (1)
      call s:SetKeywords() " (2)
      let m=match(stack, '\<'.a:el.'\>')
      call s:RestoreKeywords() " (3)
      ...

      After executing s:Instack(), the global value of 'iskeyword'
      (&g:iskeyword), the local value of 'iskeyword' (&l:iskeyword) and
      g:IsKeywordBack are changed as follows:

      Step | &g:iskeyword | &l:iskeyword | g:IsKeywordBack
      -----+-----------------+-----------------+----------------
      (1) | [some value] | [another value] | N/A
      (2) | 33-255 | 33-255 | [another value]
      (3) | [another value] | [another value] | [another value]

      This overwriting is very annoying; whenever a new buffer is created and
      'iskeyword' for the new buffer is not configured explicitly, the global
      value of 'iskeyword' will be used. If user opens a new buffer after
      completion with xmlcomplete.vim, the global value of 'iskeyword' is
      silently replaced with a value for XML. So that 'iskeyword'-sensitive
      operations such as *, #, etc don't work as user expects.

      Attached patch fixes the bug. Please include it.

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

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Bram Moolenaar
      ... Thanks. Looks OK to me. I ll include it, unless Mikolaj objects. -- ARTHUR: I did say sorry about the `old woman, but from the behind you looked--
      Message 2 of 2 , Jun 29, 2013
      • 0 Attachment
        Kana Natsuno wrote:

        > I found a problematic behavior in xmlcomplete.vim a few years ago.
        > I wrote a patch to fix it and sent to the maintainer, but I've never
        > got any reply.
        > So that I send the patch to here.
        >
        > ---------- Forwarded message ----------
        > From: Kana Natsuno <kana@...>
        > Date: Fri, Apr 9, 2010 at 11:33 PM
        > Subject: Patch: Fix wrong 'iskeyword' treatment in xmlcomplete.vim
        > To: Mikolaj Machowski <mikmach@...>
        >
        >
        > Hello,
        >
        > I found a bug in xmlcomplete.vim which is bundled as the standard
        > runtime files of Vim. s:SetKeywords() and s:RestoreKeywords() have
        > a side effect that the global value of 'iskeyword' is overridden.
        >
        > For example, s:Instack() in xmlcomplete.vim is defined as follows:
        >
        > function! s:Instack(el, sname)
        > exe 'let stack='.a:sname " (1)
        > call s:SetKeywords() " (2)
        > let m=match(stack, '\<'.a:el.'\>')
        > call s:RestoreKeywords() " (3)
        > ...
        >
        > After executing s:Instack(), the global value of 'iskeyword'
        > (&g:iskeyword), the local value of 'iskeyword' (&l:iskeyword) and
        > g:IsKeywordBack are changed as follows:
        >
        > Step | &g:iskeyword | &l:iskeyword | g:IsKeywordBack
        > -----+-----------------+-----------------+----------------
        > (1) | [some value] | [another value] | N/A
        > (2) | 33-255 | 33-255 | [another value]
        > (3) | [another value] | [another value] | [another value]
        >
        > This overwriting is very annoying; whenever a new buffer is created and
        > 'iskeyword' for the new buffer is not configured explicitly, the global
        > value of 'iskeyword' will be used. If user opens a new buffer after
        > completion with xmlcomplete.vim, the global value of 'iskeyword' is
        > silently replaced with a value for XML. So that 'iskeyword'-sensitive
        > operations such as *, #, etc don't work as user expects.
        >
        > Attached patch fixes the bug. Please include it.

        Thanks. Looks OK to me. I'll include it, unless Mikolaj objects.

        --
        ARTHUR: I did say sorry about the `old woman,' but from the behind you
        looked--
        DENNIS: What I object to is you automatically treat me like an inferior!
        ARTHUR: Well, I AM king...
        The Quest for the Holy Grail (Monty Python)

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

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

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