Manuel Ortega 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.
Thanks for mentioning this.
I don't think the solution is to not enable syntax highlighting, but
do this in another way. But how?
The trick to do something in an ftdetect script smells like a hack.
Perhaps part of the defaults can be set before loading the .vimrc, so
that they can be overruled, and others can be done after loading the
.vimrc, so that they can be disabled.
Could also move loading menu.vim out of filetype.vim, but it's hard to
predict what side effects this has. E.g. if someone enables filetype
detection and then deletes a menu. That would break.
Another solution: When there is a .vimrc, then don't load startup.vim.
Rely on the user already have his preferences in the .vimrc.
Thus only apply these better defaults when the user doesn't have his own
settings. Ah, I see Ben also had this idea.
The more I think about it, the more this seems like a good solution:
- If the user has a .vimrc, use that.
- If there is no .vimrc, use the default .vimrc.
- When a new user creates a .vimrc, he can source the default one or
copy it. It's possible to do settings before this, such as adding 'M'
to 'guioptions'.
That way anybody which already has a .vimrc isn't bothered by different
defaults. 100% backwards compatible.
New users will get better defaults. When using Vim on a new system it
also has better defaults.
Only those who really want the Vi defaults or the Vim 7 defaults would
need to create a .vimrc and set 'compatible' or 'nocompatible'.
There is some confusion for users who create their .vimrc for the
first time and don't know about the default vimrc. That can be
documented and once discovered it's easy to fix.
--
Sorry, no fortune today.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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.
