2016-07-27 17:01 GMT+09:00 Manuel Ortega <mannyvim...@gmail.com>:
> On Wed, Jul 27, 2016 at 3:51 AM, Manuel Ortega <mannyvim...@gmail.com>
> wrote:
>
>> On Wed, Jul 27, 2016 at 2:51 AM, Manuel Ortega <mannyvim...@gmail.com>
>> wrote:
>>
>>> On Tue, Jul 26, 2016 at 5:17 PM, Bram Moolenaar <b...@moolenaar.net>
>>> wrote:
>>>
>>>>
>>>>
>>>> " Switch syntax highlighting on when the terminal has colors or when
>>>> using the
>>>> " GUI (which always has colors).
>>>> if &t_Co > 2 || has("gui_running")
>>>> syntax on
>>>>
>>>
>>> Wait a sec. If "syntax on" is done here, then won't it be impossible to
>>> use "set guioptions+=M" in the user's .vimrc and have it work? The docs
>>> say that in order for that to work, it must be done "before switching on
>>> syntax or filetype recognition". But if syntax is turned on here, by the
>>> time the "set go+=M" in his .vimrc is encountered it will be too late,
>>> right?
>>>
>>
>> Indeed, that is the case (I tried it). If you put "syntax on" in the
>> system vimrc, then the user cannot use "set go+=M". I think this is a
>> good reason to remove "syntax on" from the proposal. If it's left in, you
>> might as well just eliminate "M" as one of the guioptions, because it's
>> totally unusable unless it goes in the local machine's system vimrc, which
>> many users will not be able to change, or will not want to tweak it every
>> time they build a new Vim.
>>
>
> If "syntax on" is in the system vimrc as proposed, then I can't seem to
> find any way *at all* to disable the loading of the system menu.vim (short
> of unacceptable hacks like bash-aliasing 'vim' to 'vim -u ~/.vimrc'.)
>
> Not only that, but the variables in menu.vim intended to be settable by
> the user to stop certain segments from loading, i.e.,
>
> let did_install_default_menus = 1
> let no_buffers_menu =1
> let did_install_syntax_menu = 1
>
> ... have no effect in the user's vimrc because menu.vim is already loaded
> by the system vimrc's "syntax on".
>
> Please, please, remove "syntax on" from the proposal. There is no way for
> the user to undo its side-effects.
>
> -Manny
>
Hi,
After having read your argument through, I’m still for ‘syntax on’.
After all, the problem boils down to this: How many GUI users do they
actually set go=+M?
My bet is that the number is nearly zero.
If our system menu were of such less importance that one could kill it at
will, it would not be worth being called “the system menu.”
IOW, as long as our system menu has a substantial role in our GUIs,
allowing the users to set go+=M doesn’t make sense at all.
Rather, eliminating the M option would be the right way to go.
I think ‘syntax on’ as well as ‘filetype plugin indent on’ constitutes the
core of Bram’s proposal and speaks out in an effective way about what the
coming default changes are all about.
I’m afraid its withdrawal will only make people wonder why Vim 8 falls
short that way.
Best regards,
Kazunobu Kuriyama
> --
> --
> 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.
>
--
--
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.
