On Thu, Sep 15, 2016 at 11:22 AM, Kazunobu Kuriyama
<kazunobu.kuriy...@gmail.com> wrote:
> 2016-09-15 17:46 GMT+09:00 Tony Mechelynck <antoine.mechely...@gmail.com>:
>>
>> On Thu, Sep 15, 2016 at 9:45 AM, Kazunobu Kuriyama
>> <kazunobu.kuriy...@gmail.com> wrote:
>> > 2016-09-15 7:41 GMT+09:00 Tony Mechelynck
>> > <antoine.mechely...@gmail.com>:
>> >>
>> >> exists() result is sometimes misleading for a command.
>> >>
>> >> Example (with GTK3 gvim linked with GTK 3.16.7):
>> >>     :echo exists(':tearoff')
>> >>         2
>> >>     :tearoff &Help
>> >>         E319: Sorry, the command is not available in this version
>> >>
>> >> So for example the following code in my vimrc would produce the exact
>> >> error which it is meant to avoid:
>> >>
>> >>     au GUIEnter * if exists(':tearoff') == 2 | exe 'tearoff &Help' |
>> >> endif
>> >>
>> >> If the :tearoff command is disabled in GTK3 gvim, then IMHO
>> >> exists(':tearoff') ought to return 0, not 2.
>> >
>> >
>> > I looked into that a bit and found that it was not specific to GTK3.
>> >
>> > The same thing happens with the latest GTK2 GUI and that of 7.4.1401,
>> > the
>> > one just prior to the GTK3 patch inclusion.
>> >
>> > I tried to do a bisect search to find which patch introduced that
>> > regression, but failed due to a header file relocation on OS X as of
>> > 10.9,
>> > Mavericks.  I was unable to build vim older than 7.4.62.  Nonetheless, I
>> > confirm that the same regression was also seen with that version.
>> >
>> > Looks it has been there unnoticed for a long time.
>> >
>> > As for GTK3, if the GUI is linked against GTK+ 3.4 or later, tear-off
>> > menus
>> > are disabled, as written in 'h: tear-off-menus'.
>> >
>> > So, fixing the issue is quite easy for GTK >= 3.4; it can be fixed using
>> > a
>> > version check.  But I'm not sure what I can do for the rest for now.
>>
>> A version check? And, in a script (a plugin maybe) written to run on
>> any version of Vim on any OS, how do I check the GTK version?
>> has('gui_gtk3') will say if I am on GTK3 or not, but GTK 3.2 or GTK
>> 3.16? How can this script determine it in some simple manner? In
>> either case I might be on any Vim version supporting GTK3 so testing
>> v:version wouldn't help.
>
>
> I meant by 'a version check' a preprocessor directive which... probably...is
> added to ex_cmds.h to  disable ';:tearoff' in order to suppress the false
> error message for GTK >= 3.4.  I was talking about what I could do for
> fixing the issue.  Not that imposing anything on anyone.

Ah, sorry. I thought you meant keep Vim (temporarily) as-is and do
some check in my scripts. I suppose that checking the GTK version in
configure is possible and that some #ifdef or similar could be
contrived so that exists(':tearoff') should retun zero if and only if
trying to use :tearoff would trigger an E319 exception.

Maybe this might work as an interim measure (catch the error a
posteriori instead of a priori):

if has('autocmd')
  au GUIEnter *
    \ try
      \ | exe 'tearoff &Help'
    \ | catch /^Vim\%((\a\+)\)\=:E319/
    \ | endtry
endif

>
>>
>> If exists() worked like I feel it ought to, I could simply check
>> exists(':tearoff'), then if zero the command is not available and if
>> == 2 it is, which is what I understand from ":help exists()" that it
>> ought to do. But in the case considered, exists(':tearoff') is 2, and
>> yet the :tearoff command is not present. I call that a bug. How can I
>> now trust _any_ test for :if exists(':excommandname') == 2 | etc. for
>> any :excommandname? If it returns false, OK, the command is not there;
>> but if it returns true, maybe the command is not there anyway!
>
>
> As I explained, the bug appears to be a long outstanding non-trivial one,
> and the VCSs we've used seemingly don't help me much to identify which patch
> introduced the regression.  I spent not a few time for your report already,
> and was thinking of how to find my spare time for investigating huge old
> commit logs and mail archives.

Mmm...

>
> Best regards,
> Kazunobu
>
>>
>> Best regards,
>> Tony.
>>
>> >
>> > Best regards,
>> > Kazunobu
>> >
>> >>
>> >>
>> >>
>> >> Best regards,
>> >> Tony.
>> >>

Best regards,
Tony.

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui