Re: completeopt: menu|menuone + longest = bug?
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 -- [EMAIL PROTECTED] -- 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///
Re: completeopt: menu|menuone + longest = bug?
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 -- [EMAIL PROTECTED] -- 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///
Re: exists(*Foo!garbage) = 1 ?
On Tue, May 02, 2006 at 12:13:37AM +0200, Bram Moolenaar wrote: Charles Campbell wrote: Bram Moolenaar wrote: The problem of changing something like this is that all scripts that are included in the release need to be checked for effects. And there are lots of scripts now. I wouldn't be surprised if, for example, the netrw plugin stops working properly. In perusing netrw, I believe that all the netrw usages of exists(*func) give exists() a full function name; ie. they don't depend on its just being a prefix. So, I expect that netrw should work ok with such a change. Bad example... I meant that there are scripts that are too big to check. I tried :vimgrep /exists[^)]*\*/ $VIMRUNTIME/**/*.vim :cl and found that there are 111 matches. If all we are worried about is exists(*string) where string contains non-'isk' characters, then I am willing to check them. I bet there are very few. HTH --Benji Fisher
Re: completeopt: menu|menuone + longest = bug?
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
gvim + X + geometry + set line + cttrl-f + folding (whew!) : a bug
Hello! This one appears to be a ctrl-f (and ctrl-b) bug. Here's the setup: (using Linux,vim-7.0g, huge) .vimrc : set nocp .gvimrc : set lines=21 no .vim/ directory. Now, for the problem: gvim -geometry 139x22+0+4 netrw.vim 11jspace zcr 4jspace6k4j ctrl-f Note that the ctrl-f does not advance a page; instead, the cursor returns to the top line (which is a fold). Similar misbehavior happens with a ctrl-b. I have to use hit ctrl-e several times to move the folds off the top; then, ctrl-f works again. Regards, Chip Campbell
