Kazunobu Kuriyama wrote:
> > > [TL;DR] I wish you rethink about this. It seems there's
> > misunderstanding
> > > about the proposed patch. Since I thought it was not the one on my
> > pert, I
> > > didn't address it to the feedback from Marvin. But you still rase
> > similar
> > > concerns. Now I'm going to try to address them at full length. Since
> > > it's pretty long, please read it at your convenient time.
> >
> > Sorry, this is too much to read. Let's summarize.
> >
> > First of all, we need to keep all the existing values for has().
> > Otherwise plugins break. So keep has('gui_mac').
>
>
> I'll keep intact the description of gui_mac in eval.txt. Then, what should
> we do with evalfunc.c:5670 where "gui_mac" is set as a member of has_list[]
> when FEAT_GUI_MAC is defined? My proposal was to remove it together with
> the ifdef block. Will we keep it there as-is or keep it there yet
> replacing FEAT_GUI_MAC with 0 or a newly designated preprocessor symbol,
> say SUPPORT_DISCONTINUED?
Wait, are you saying that FEAT_GUI_MAC would never be defined? I
thought that was still working if Carbon is available. I suppose that's
only on older systems.
Unfortunately os_mac.txt is totally unhelpful. It points to macvim.org
without mentioning anything about what version one gets there and for
which system. Also, the code names are not explained. E.g., what is
Darwin? I believe it's the same as OS X.
Why don't we start with listing versions of Mac OS and what versions of
Vim one can build on it. I guess we only support OS X. Mac OS 9 was
released in 1999, OS X in 2001. Even my very old Powerbook G4 has OS X.
I managed to make it startup again. It has the GUI with Vim 7.2. When I
have time I'll try later versions.
For MacVim there is only one version, right? We should figure out what
macros are relevant for it.
> > I can't remember why we had has('mac') return false on any Mac OS.
> > Also having it return true for OS/X is most likely OK.
>
> Let's make has('mac') work just the way people expect. As I proposed
> previously, the meaning of has('macunix') won't change.
>
> > The terms "with darwin" and "without darwin" are very confusing. There
> > is no help for "darwin". Cleaning that up sounds like a good idea.
>
> OK, I'll add some explanation on the darwin feature to os_mac.txt, and make
> links between that and the terms.
Thanks.
> > For the preprocessor symbols: Let's first list all the possible ways Vim
> > can be compiled for the Mac. For as far as that matters (I suppose the
> > ppc vs intel choice only matters for compiler flags). The
> > --disable-darwin configure argument changes a few things.
>
> Still, prior to making the suggested list, I think we should first remove
> the code relevant to Mac OS 9 and the Carbon GUI. Please allow me to
> reiterate them:
>
> version7.txt:108 (2005-12-06, 241a8aaa48):
> "The support for Mac OS 9 has been removed."
>
>
> src/configure.ac:2231 (2010-07-14, 164fca39bd):
> "AC_MSG_RESULT(auto - Carbon GUI is outdated - disable GUI support)"
>
> They are backlogs overdue.
Mac OS 9 probably is irrelevant. But Carbon might still work. My old
Powerbook has OS X 10.4 (Tiger). I believe it was supported up to OX X
10.8, so that's a wide range of systems.
> > How about Carbon? On my Mac air it appears not to work, Quickdraw.h is
> > missing.
>
> They say that Carbon wasn't updated to support 64-bit. So current Carbon
> Vim is the one only for someone who wants to run a 32-bit Vim 8.0 in a
> 64-bit environment for one reason or another. I'm definitely the last
> person of this kind.
>
> And, as you noticed, our build system hasn't maintained in a way to support
> it.
>
> I think Carbon Vim was destroyed in three phases: First, the Carbon code
> was alienated from the codebase when the darwin feature is merged there on
> 2010-07-14. Next, OS X 10.8 has deprecated most Carbon APIs on 2012-07-24.
> Lastly, when OS 10.9 brought us a breakage regarding Cabon.h and
> AvailabilitMacros.h, we made an effort to maintain the Cocoa code but no
> effort for the Carbon code at any rate.
Hmm, so the Carbon code might already be broken? I haven't heard
complaints, so perhaps it's not worth fixing.
> IIRC, we haven't received any report, patch or request on the breakage
> relevant to the Carbon code so far.
>
> in conclusion, unless someone is willing to work for that, we are no longer
> able to maintain it. Personally, I think it's nearly impossible to restore
> it.
How about Cocoa support? Is that only in MacVim?
> > Anyway, I think this change should be split into smaller pieces to make
> > it easier to see what changes.
>
> So my current plain consists of four phases:
>
> (1) Removal of MACOS_CLASSIC related code and adjustments of the build
> system.
That makes sense.
> (2) Removal of FEAT_GUI_MAC related code and adjustments of the build
> system.
This is Carbon support, right? I wonder if we can make this work.
How do we check that we don't remove anything that MacVim needs?
> (3) Making a list of all the possible ways Vim can be build for Mac. Based
> on that, optimize the build system for Mac if possible.
I would do this first, perhaps with some gaps for doesn't work.
> (4) Correct the meaning of the feature list item 'mac'.
>
> Each phase has its own patch and will be accompanied with document update.
Thanks for working on this!
--
Trees moving back and forth is what makes the wind blow.
/// Bram Moolenaar -- [email protected] -- 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
