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

completeopt: menu|menuone + longest = bug?

Expand Messages
  • Eric Van Dewoestine
    Tested with vim70g Given the following file contents: BlahBlahImpl BlahBlah.Type If I try to perform the following on a new line at the end of the file
    Message 1 of 7 , Apr 30, 2006
    • 0 Attachment
      Tested with vim70g

      Given the following file contents:
      BlahBlahImpl
      BlahBlah.Type

      If I try to perform the following on a new line at the end of the file
      Bl<c-x><c-n or p>.T<c-n or p>

      The resulting text should be
      BlahBlah.Type
      However, if my 'completeopt' has menu and longest, or menuone and
      longest, I get unexpected results.

      Case 1:
      Bl<c-x><c-n>.T<c-n>

      Results in:
      BlahBlah.T
      Vim Message = "Back at original"
      Subsiquent <c-n> calls have no effect.

      Case 2:
      Bl<c-x><c-p>.T<c-p>

      Results in:
      Bl
      Vim Message = "Back at original"
      Subsiquent <c-p> calls have no effect.
      This case is even worse than the first since my previously completed
      BlahBlah text is now gone.

      Note: I tested the above by simply starting vim as follows:
      To show unexpected behavior:
      vi -u NONE -c "set completeopt=menu,longest"
      To show expected behavior:
      vi -u NONE -c "set completeopt=longest"
      or
      vi -u NONE -c "set completeopt=menu"

      --
      eric
    • Bram Moolenaar
      ... I know about this: When you type the . and there no complete match was inserted (showing the longest common text in this example), Vim assumes you are
      Message 2 of 7 , May 1, 2006
      • 0 Attachment
        Eric Van Dewoestine wrote:

        > Tested with vim70g
        >
        > Given the following file contents:
        > BlahBlahImpl
        > BlahBlah.Type
        >
        > If I try to perform the following on a new line at the end of the file
        > Bl<c-x><c-n or p>.T<c-n or p>
        >
        > The resulting text should be
        > BlahBlah.Type
        > However, if my 'completeopt' has menu and longest, or menuone and
        > longest, I get unexpected results.
        >
        > Case 1:
        > Bl<c-x><c-n>.T<c-n>
        >
        > Results in:
        > BlahBlah.T
        > Vim Message = "Back at original"
        > Subsiquent <c-n> calls have no effect.
        >
        > Case 2:
        > Bl<c-x><c-p>.T<c-p>
        >
        > Results in:
        > Bl
        > Vim Message = "Back at original"
        > Subsiquent <c-p> calls have no effect.
        > This case is even worse than the first since my previously completed
        > BlahBlah text is now gone.
        >
        > Note: I tested the above by simply starting vim as follows:
        > To show unexpected behavior:
        > vi -u NONE -c "set completeopt=menu,longest"
        > To show expected behavior:
        > vi -u NONE -c "set completeopt=longest"
        > or
        > vi -u NONE -c "set completeopt=menu"

        I know about this: When you type the "." and there no complete
        match was inserted (showing the longest common text in this example),
        Vim assumes you are extending the text to reduce the list of matches.
        Thus the completion still starts at "BlahBlah".

        You need to stop completion somehow, e.g., with a space and backspace.

        This is not a nice way to work. I thought of having all punctuation
        characters stop completion, but that breaks completion of items where
        punctuation can be part of the match (e.g., () for functions).

        --
        The problem with political jokes is that they get elected.

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ download, build and distribute -- http://www.A-A-P.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
      • Eric Van Dewoestine
        ... Ah, that makes sense. What about an option for specifying what characters end the completion? setlocal completedelim+=. or something similar? -- eric
        Message 3 of 7 , May 1, 2006
        • 0 Attachment
          > I know about this: When you type the "." and there no complete
          > match was inserted (showing the longest common text in this example),
          > Vim assumes you are extending the text to reduce the list of matches.
          > Thus the completion still starts at "BlahBlah".
          >
          > You need to stop completion somehow, e.g., with a space and backspace.
          >
          > This is not a nice way to work. I thought of having all punctuation
          > characters stop completion, but that breaks completion of items where
          > punctuation can be part of the match (e.g., () for functions).
          >

          Ah, that makes sense. What about an option for specifying what
          characters end the completion?

          setlocal completedelim+=.

          or something similar?

          --
          eric
        • Bram Moolenaar
          ... It s too complicated already, adding another option will mainly cause more users to get confused. Also, I wouldn t know what to set it to for C. --
          Message 4 of 7 , May 1, 2006
          • 0 Attachment
            Eric Van Dewoestine wrote:

            > > I know about this: When you type the "." and there no complete
            > > match was inserted (showing the longest common text in this example),
            > > Vim assumes you are extending the text to reduce the list of matches.
            > > Thus the completion still starts at "BlahBlah".
            > >
            > > You need to stop completion somehow, e.g., with a space and backspace.
            > >
            > > This is not a nice way to work. I thought of having all punctuation
            > > characters stop completion, but that breaks completion of items where
            > > punctuation can be part of the match (e.g., () for functions).
            > >
            >
            > Ah, that makes sense. What about an option for specifying what
            > characters end the completion?
            >
            > setlocal completedelim+=.
            >
            > or something similar?

            It's too complicated already, adding another option will mainly cause
            more users to get confused. Also, I wouldn't know what to set it to for
            C.

            --
            ARTHUR: I've said I'm sorry about the old woman, but from the behind you
            looked ...
            DENNIS: What I object to is that you automatically treat me like an inferior...
            ARTHUR: Well ... I AM king.
            "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/ \\\
            \\\ download, build and distribute -- http://www.A-A-P.org ///
            \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
          • mzyzik@gmail.com
            ... It s not that confusing. This is not a good reason for not implementing something like completedelim . A better reason would be that nobody feels like
            Message 5 of 7 , May 1, 2006
            • 0 Attachment
              On Tue, May 02, 2006 at 12:13:37AM +0200, Bram Moolenaar wrote:
              >
              > Eric Van Dewoestine wrote:
              >
              > > > I know about this: When you type the "." and there no complete
              > > > match was inserted (showing the longest common text in this example),
              > > > Vim assumes you are extending the text to reduce the list of matches.
              > > > Thus the completion still starts at "BlahBlah".
              > > >
              > > > You need to stop completion somehow, e.g., with a space and backspace.
              > > >
              > > > This is not a nice way to work. I thought of having all punctuation
              > > > characters stop completion, but that breaks completion of items where
              > > > punctuation can be part of the match (e.g., () for functions).
              > > >
              > >
              > > Ah, that makes sense. What about an option for specifying what
              > > characters end the completion?
              > >
              > > setlocal completedelim+=.
              > >
              > > or something similar?
              >
              > It's too complicated already, adding another option will mainly cause
              > more users to get confused. Also, I wouldn't know what to set it to for
              > C.

              It's not that confusing. This is not a good reason for not implementing
              something like 'completedelim'. A better reason would be that nobody
              feels like implementing it and documenting it. So far there are three
              options starting with "complete". This is complicated? I thought
              Vim/Emacs are ultra configurable... and the menu/completion system is a
              big feature.

              If it were up to me, I would have an option for what characters end the
              completion, and also what characters select the current completion and
              then end the completion... or something like that. Maybe not. At least
              something like completedelim.

              --Matt

              >
              > --
              > ARTHUR: I've said I'm sorry about the old woman, but from the behind you
              > looked ...
              > DENNIS: What I object to is that you automatically treat me like an inferior...
              > ARTHUR: Well ... I AM king.
              > "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/ \\\
              > \\\ download, build and distribute -- http://www.A-A-P.org ///
              > \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
            • Eric Van Dewoestine
              ... I thought about this a bit more today, and I agree that adding a new option is not the proper solution. Not because it would confuse users, but because
              Message 6 of 7 , May 1, 2006
              • 0 Attachment
                > >
                > > It's too complicated already, adding another option will mainly cause
                > > more users to get confused. Also, I wouldn't know what to set it to for
                > > C.
                >
                > It's not that confusing. This is not a good reason for not implementing
                > something like 'completedelim'. A better reason would be that nobody
                > feels like implementing it and documenting it. So far there are three
                > options starting with "complete". This is complicated? I thought
                > Vim/Emacs are ultra configurable... and the menu/completion system is a
                > big feature.
                >
                > If it were up to me, I would have an option for what characters end the
                > completion, and also what characters select the current completion and
                > then end the completion... or something like that. Maybe not. At least
                > something like completedelim.

                I thought about this a bit more today, and I agree that adding a new
                option is
                not the proper solution. Not because it would confuse users, but because
                the set of characters that end a completion could depend on the completion
                method, so setting them at the filetype level wouldn't work.

                For example, the standard keyword completion (<c-n> and <c-p>) only spans word
                characters. Any non-word character should end the completion. Conversely, a
                user defined, or omni completion function may span back over non-word
                characters.

                Without knowing anything about how you've implemented the code completion
                internally, I'd guess that perhaps you could let the completion function
                decide when to start a new completion by invoking the completion function
                again and comparing the original starting column position with the new one.
                If they differ, then the function has deemed that it no longer considers the
                non-word character part of the original completion.

                You've mentioned a few times how the code completion logic is getting
                complicated, but is that a good reason for leaving in known issues? Perhaps
                after you have released vim70, vim71 should get a bit of an overhaul in this
                area now that you've encountered a broader range of use cases. While I find
                the current behavior I described in my original email very annoying, I still
                wouldn't consider it a show stopper for the final release of vim70. However,
                it would be a shame to never fix it just because it's "complicated".

                --
                eric
              • Bram Moolenaar
                ... It s not that it should not be fixed, it s that adding more options/features/commands/whatever is not a good fix. -- Eye have a spelling checker, it came
                Message 7 of 7 , May 2, 2006
                • 0 Attachment
                  Eric Van Dewoestine wrote:

                  > You've mentioned a few times how the code completion logic is getting
                  > complicated, but is that a good reason for leaving in known issues?
                  > Perhaps after you have released vim70, vim71 should get a bit of an
                  > overhaul in this area now that you've encountered a broader range of
                  > use cases. While I find the current behavior I described in my
                  > original email very annoying, I still wouldn't consider it a show
                  > stopper for the final release of vim70. However, it would be a shame
                  > to never fix it just because it's "complicated".

                  It's not that it should not be fixed, it's that adding more
                  options/features/commands/whatever is not a good fix.

                  --
                  Eye have a spelling checker, it came with my PC;
                  It plainly marks four my revue mistakes I cannot sea.
                  I've run this poem threw it, I'm sure your please to no,
                  It's letter perfect in it's weigh, my checker tolled me sew!

                  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                  /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                  \\\ download, build and distribute -- http://www.A-A-P.org ///
                  \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
                Your message has been successfully submitted and would be delivered to recipients shortly.