* Kazunobu Kuriyama <kazunobu.kuriy...@gmail.com> [170418 00:15]:
> The proposed changes are rather fixes to address a certain issue than those
> that possibly break existing scripts.
>
> The issue is this: Currently, 'mac' does not cover all versions of vim
> running on Mac. To be more specific, vim configured with --disable-darwin
> gives 0 to has('mac').
>
> To address the issue, a new feature list item called 'osx' was introduced
> about a year ago. With that, the following condition covers all possible
> vim instances running on Mac:
>
> has('mac') || has('osx')
>
> Although this is logically correct, it looks clumsy and is turned out to be
> error-prone.
>
> Naturally, people does not expect that there's a case where has('mac')
> returns 0 for a vim actually running on Mac. The proposed patch would
> eliminate this counter-intuitive case.
Okay, SGTM.
> Also, we are now in the process of improving the test coverage. Through
> the process, we sometimes came across the cases where a newly written test
> failed inadvertently for darwin-disabled vim due to missing has('osx').
>
> If all test writers were familiar with Mac, it would be quite reasonable to
> ask them not to forget that. In reality, however, they are not. We need
> to provide a feature list item easier to use for test writers to write
> tests which are expected to work well on Mac even if they are not on Mac to
> write them. The proposed patch would help those people.
>
> The --disable-darwin configuration is highly unlikely to be used by package
> managers and non-dev users, because that configuration is meant to kill the
> clipboard service from the system. So I think dropping 'osx' won't make
> much trouble because those who know both --disable-darwin and has('osx')
> and understand their implications have already had a working knowledge as
> to how to handle trouble caused by them.
I think this is a reasonable justification for your proposed change.
> 2017-04-18 2:49 GMT+09:00 Marvin Renich <m...@renich.org>:
> > I think for this to work, the existing names should
> > be left as is and marked as deprecated, and then add new names, such as
> > mac_any, mac_unix, and mac_osx with the new meanings.
>
> Now we come to know adding new names does not necessarily address an issue
> satisfactorily and would cause trouble later, as we've seen a case with
> 'osx'. That's another reason why the patch is of 10k SLOC instead of usual
> 0.1k for this sort of changes. We need to neutralize the root cause of
> name proliferation, too :)
I definitely agree that name proliferation should be avoided when
possible, but it is less important than preventing breakage of existing
scripts. Documenting the old names as deprecated with an explanation of
why using them is bad would be preferable to breaking changes, but your
justification above is sufficient to assuage my concerns in this
particular case.
Thanks for working on this and also for taking the time to explain your
reasoning for the design.
...Marvin
--
--
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.
