Re: findfile() results are inconsistent
On 7/25/06, Mikolaj Machowski [EMAIL PROTECTED] wrote: Dnia wtorek, 25 lipca 2006 02:14, Eric Van Dewoestine napisał: 1. We are in /home/mikolaj:: echo findifile(b, 1;) 1/b You are giving findfile() a relative path to search, so it is returning a relative result. Result is the same regardless to path in second argument. Yes, my mistake. From the vim docs: When the found directory is below the current directory a relative path is returned. Otherwise a full path is returned. 1) 1/b is below your current directory so a relative path is returned as described in the documentation. 2) 3) In these examples the result is not at or below the current directory. So, the results are still consistent with the documented behavior. Regarding ';', the docs imply that it forces a search upwards, but should probably state that explicitly. -- eric
Re: findfile() results are inconsistent
Results of findfile() are inconsistent: The results seem consistent to me. /home/mikolaj/a /home/mikolaj/1/b /home/mikolaj/2/c /home/mikolaj/3/d /home/mikolaj/3/4/e 1. We are in /home/mikolaj:: echo findifile(b, 1;) 1/b You are giving findfile() a relative path to search, so it is returning a relative result. 2. We are in /home/mikolaj/2:: echo findifile(b, /home/mikolaj/1;) /home/mikolaj/1/b You are giving findfile() an absolute path to seach, so it is returning an absolute result. 3. We are in /home/mikolaj/3/4:: echo findifile(d, /home/mikolaj/3/4;) /home/mikolaj/3/d Once again you supply an absolute path, so it returns an absolute result. If you need to expand a relative result to its absolute path or strip off portions of an absolute result, you can always use fnamemodify(). -- eric
Suggested Enhancement- New Command :tcd
I would like to suggest the addition of a new command -
:tcd[!] {path}
This command would be like :cd and :lcd, but instead of changing the
global or window relative directory, :tcd would change the directory
for the current tab resulting in all currently open windows on that
tab and any new windows opened on the tab having the supplied
directory as their new current working directory.
I think this command would be extremely useful when editing files from
one project in one tab and files from another project in another tab.
Currently this functionality could be implemented via a plugin, but
inclusion as a built in vim command would make for a more elegant
solution and would not require users to download any separate files to
utilize it.
--
eric
should :silent be suppressing autocmds?
Should prepending :silent to a command be suppressing an autocommand? Neither the docs for autocommands nor the docs for :silent indicate this is the intended behavior. For example: using the following the autocommand is executed as expected with the desired output vim -u NONE -c set nocompatible | set verbose=10 | autocmd BufWinEnter test_file echom 'Test file opened.' -c edit test_file however, after adding :silent, the autocommand does not fire and there is no output vim -u NONE -c set nocompatible | set verbose=10 | autocmd BufWinEnter test_file echom 'Test file opened.' -c silent edit test_file -- eric
Re: Change wildmode w/ 'longest' to be behave like completeopt w/ 'longest'
The default setting, wildmode=full , highlights (if anything) what it
actually completes. If you repeatedly hit the right-arrow key, it will
cycle through all full matches and what you had typed. See :help
'wildmode' for the various other possibilities. Whatever you see
highlighted on the statusline, what is filled-in is what you see on the
command-line. If longest is included, it's not necessarily a full
match. The purpose of that is to allow incremental completion.
Yes, I understand the purpose and usage of wildmode. My suggestion is
that the wildmode 'longest' should behave like the completeopt
'longest' where an entry is only highlight if that highlighted text is
actually inserted into the buffer, or command line in this case.
As of now , the behavior of 'longest' is inconsistent across the two
vim options ('completeopt' and 'wildmenu').
--
eric
Re: [vim7] a strange behavior of completeopt
I reported this same issue to the mailing list a week or two ago. Bram 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). The same bug affects file name completion and presumably others as well: /uC-XC-F/bC-N Result with completeopt-=longest /usr/bin/ with '/usr/bin/' as only suggestion. Result with completeopt+=longest /usr/b with no suggestions. -- eric
Re: QuickFixCmdPost
On 4/24/06, Eric Van Dewoestine [EMAIL PROTECTED] wrote: I'll move it then. Please try it out with the next snapshot. Appears to be working as expected. Actually, I've found one small issue with this... If the executed make command results in one or more errors added to the quickfix, and the QuickFixCmdPost subsiquently calls setqflist([]), then when the make command finishes, vim displays the error message No Errors. It appears that prior to invoking the QuickFixCmdPost, vim has already decide that it is going to show the first error, if any, and after the QuickFixCmdPost, it does not check the qf list first to see if there is still an error to display. -- eric
Change wildmode w/ 'longest' to be behave like completeopt w/ 'longest'
When starting vim as follows vim -u NONE -c set nocompatible | set wildmenu | set wildmode=longest:full,full if you perform :eTab you get a list of commands starting with 'e' and the command line is unchanged (still only contains 'e'). The only issue, is that the first entry in the list is highlighted, but the command line does not contain that text. The fact that the entry is highlighted should indicate that the text is on the command line and a cr will execute that command (like how ins-completion works). -- eric
Re: QuickFixCmdPost
Do you mean that the autocommand removes all matches? Well, somehow I
think it's good to give the message then. But perhaps it's just another
execuse to give this deep error message :-).
Yes, the autocommand may remove all entries from the quickfix list.
My underlying issue is that I run junit tests from vim and I want to
add a qf entry for every failed test case. The problem is that I
cannot find a way to only match failed junit tests and still grab the
necessary text for the qf error message.
Ex.
[junit] Running org.foo.BarTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 1.361 sec
[junit] Running org.foo.BazTest
[junit] Tests run: 2, Failures: 2, Errors: 1, Time elapsed: 0.305 sec
Given the above output I should have one qf entry
{'filename': 'org.foo.BazTest', 'text': 'Tests run: 2, Failures: 2,
Errors: 1, Time elapsed: 0.305 sec'}
But as far as I can tell there is no way for me to set the
'errorformat' such that the first 2 lines are not matched as an error
but the second one is AND I can still use the 'Tests run ...' as the
text for the qf result.
So, as a workaround I have an autocmd which filters out successfull
tests, and as such, may end up removing all entries from the qf list.
While, it's not a huge deal that the user recieves the No Errors
message, it does imply that something may be broken.
--
eric
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
completeopt: menu|menuone + longest = bug?
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 Blc-xc-n or p.Tc-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: Blc-xc-n.Tc-n Results in: BlahBlah.T Vim Message = Back at original Subsiquent c-n calls have no effect. Case 2: Blc-xc-p.Tc-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
Re: QuickFixCmdPost
I'll move it then. Please try it out with the next snapshot. Appears to be working as expected. thanks guys. -- eric
Re: Code completion and entries with duplicate 'word' attributes.
Allowing duplicate entries is not that difficult. Perhaps adding an item to the dictionary for this is sufficient. Let's use dup for that. Just tested this with the latest snapshot... works like a champ. thanks for the quick turn around. -- eric
Re: Code completion and entries with duplicate 'word' attributes.
On 4/21/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Eric Van wrote: It appears that code completion is removing any entries that have duplicate 'word' attributes. For completion results not using the dictionary format I fully agree that duplicates can safely be removed, but when using the dictionary format two or more entries sharing the same 'word' attribute should not be considered duplicates. For instance, performing code completion on the following java code String name = ... name.toC-XC-U My code completion function returns a list with the following entries: kind: 'f', word: 'toCharArray', menu: 'toCharArray() char[] - String' kind: 'f', word: 'toString', menu: 'toString() String - String' kind: 'f', word: 'toUpperCase', menu: 'toUpperCase() String - String' kind: 'f', word: 'toUpperCase', menu: 'toUpperCase(Locale locale) String - String' kind: 'f', word: 'toLowerCase', menu: 'toLowerCase() String - String' kind: 'f', word: 'toLowerCase', menu: 'toLowerCase(Locale locale) String - String' But vim removes the 4th and 5th entry since they have the same 'word' value as the entry before them (at least I assume that is why they are removed). As a user I then never get to see that String has a toUpperCase and toLowerCase that take a Locale as an argument. So I suggest either removing duplicate checking when results are in the dictionary format, or at the very least, check the 'menu' attribute along with the 'word' attribute to determine if an entry is a duplicate, however that may or may not work for everyone. Thoughts? Comments? Since we are talking about completion, there is only one word to be completed toLowerCase. That it can have different arguments doesn't matter for inserting toLowerCase. You could have a function name ten times and need to type CTRL-N ten times to get to another word. I suggest you put alternate function arguments together with one word. Thus toLowerCase would have a menu item and info that shows both possible forms of arguments. Should vim be dictating this? I've never used an IDE that behaved in this fashion. If vim leaves duplicate handling up to the script developer then we can decide which form is most appropriate for the situation, and perhaps provide our own configuration for letting the user decide which they prefer. While I agree that providing the sigurature for all variations in a single 'info' would work, what about if I want to use 'info' for a description of the method? If I have ten variations how much is the user going to have to sift through to get a description of the method their looking for? Instead of Ctrl-N x amount of times, they have to exit completion mode, switch to the preview window and begin searching. Which do think would be more convient? To Martin: http://eclim.sourceforge.net A new release should be out in the next week or two once I resolve some of these completion peculiarities. -- eric
