2016-02-25 18:46 GMT+03:00 Nikolay Aleksandrovich Pavlov <[email protected]>: > 2016-02-25 17:21 GMT+03:00 h_east <[email protected]>: >> Hi Nikolai, >> >> 2016-2-25(Thu) 22:58:19 UTC+9 ZyX: >>> 2016-02-25 16:30 GMT+03:00 h_east: >>> > Hi mattn! >>> > >>> > 2016-2-25(Thu) 21:50:37 UTC+9 mattn: >>> >> On Thursday, February 25, 2016 at 9:07:46 PM UTC+9, h_east wrote: >>> >> > Hi, >>> >> > >>> >> > I think Nikolai's patch is simple and better. Looks good for me. >>> >> > This is perfect when adding a test :-) >>> >> > >>> >> > mattn> >>> >> > Detailed error will be output in get_tv_string_buf_chk(). >>> >> >>> >> No. When the option is passed neither a nor r, it should be error, I >>> >> think. >>> > >>> > I see. >>> > Is attached patch OK? >>> >>> As I said earlier if you want to filter out all incorrect strings this >>> should also have `&& act[1] == NUL` condition. Also consider the case >>> when user used `setqflist([], '')`, it will display “E475: Invalid >>> argument: ”. Now guess what argument it meant, this error message >>> looks more like a bug then like a reference to `''`. >> >> It will be able to grasp when you see help. >> Vim's document is very good. > > What I will be able to grasp? Consider setloclist(0, [], ''): to see > the problem in help file without any pointers from the error message I > need > > 1. :h setloclist() > 2. Verify that `0` is indeed a valid window number in this context. > This is in second paragraph. > 3. <C-]> on setqflist() because setloclist() documentation does not > contain anything useful. > 4. Verify that [] is indeed a valid argument. This is two paragraphs, > a table, and another four paragraphs below. Super: see how many time > you have wasted for this. > 5. Another two paragraphs below there is actually a paragraph about > {action}. It lists three possible values, but they are scattered over > the paragraph in place of being arranged into a table, so to get a > list of possible values in mind you need to read the whole paragraph. > Double super. And nobody said explicitly that these are the only > accepted values, even though this is logical?.. no, in the current > state of your patch `'at'` is also accepted, but is not in a list. > > Now please write what you will do if you see “Exxx: Invalid action > argument: ” after doing `setloclist(0, [], '')`, pretending that you > do not know what is the problem. > > Of course, you probably will not write `setloclist(0, [], '')`, but > you will `setloclist(winnr, constructed_list, action)` (`action` has > high chances of being a string literal though). This makes debugging > with e_invarg2 even more interesting, especially if you had an opinion > that `''` is a valid action (e.g. because it worked in your previous > Vim version) and thus will check other arguments first. > > Clear message “Invalid *action* argument” points right to the argument > which contains error, unclear “Invalid argument” requires checking all > arguments to `set*list()` functions.
Does not matter how good the help is, it can never replace the proper error message. Help can teach what tutorials can’t. Help contains a reference. Help may be the final argument. But using help to determine *where* is the problem is a just a huge waste of time when you have a Vim which knows where is the problem exactly and for sure, just you need to make it tell you. And add point `0.` above: “I know that `:h E475` is an absolutely useless piece of shit (it even talks about invalid arguments to *Ex commands* while here it means invalid argument to a *function*), so am not checking `:h E475`; and I also know that `:call` will not give this error for my code, so am not checking `:h :call`.” Otherwise there are two other locations to check which also do not contain anything useful, and even are misleading because `:h E475` will point you to `:h :call` by talking about Ex commands. > >> >> Thanks. >> -- >> Best regards, >> Hirohito Higashi (a.k.a. h_east) >> >> -- >> -- >> 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 [email protected]. >> For more options, visit https://groups.google.com/d/optout. -- -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
