[patch] Clean up Mac code

[Kazunobu Kuriyama]

This is a followup to https://groups.google.com/forum/#!topic/vim_dev/5RFo3q8xvfo where we talked about the feature list items relevant to Mac:

2017-04-09 21:58 GMT+09:00 Bram Moolenaar <Br...@moolenaar.net>:

>  We should make the feature list a bit more clear about what

those features mean.

>

> I now have:

>

> gui_mac                 Compiled with Macintosh GUI.

> mac                     Any Macintosh version of Vim, but not all OS X.

> macunix                 Compiled for OS X, with darwin

> osx                     Compiled for OS X, with or without darwin

Proposal

-------------

My proposal is to change them as follows:

'gui_mac' will be abolished by discontinuing maintaining the Carbon GUI code and dropped from the list.

The rest of the items will be changed for eval.txt as follows:

mac         Any macOS versions of Vim

macunix     Compiled for macOS with pasteboard support (default)

osx         (Deprecated.  Use "mac" instead)

Not to mention, macOS implies Mac OS X and OS X.

Personally, I think the item 'osx' can also be dropped on this occation if we don't worry much about the backwards compatibility of that particular item.

Rationale

-------------

Next, let me explain how I came to the conclusion for each item.

(1) gui_mac

In src/configure.ac:2231--2232, we have had

auto) AC_MSG_RESULT(auto - Carbon GUI is outdated - disable GUI support)

        SKIP_CARBON=YES ;;

since 2010-07-14 (164fca39b).  Now that time has passed enough for transition, I propose that we discontinue maintaining the code and drop it from the codebase.

(2) mac/osx

Currently, 'mac' is set to 1 (evalfunc.c:5493) when MACOS is defined (vim.h:103).

MACOS is defined when either MACOS_X_UNIX or MAC_CLASSIC is defined, but the

latter is no longer used by the current build system other than passing -Dmacintosh to the configure script from the command line manually (vim.h:93--104).

As a result, 'mac' is effectively a synonym of 'macunix' these days.

My proposal is to drop the MAC_CLASSIC semantics from 'mac', and to have it play the same role as that of the current 'osx' does, in addition to the MACOS_X_UNIX semantics.

(3) macunix

IMHO, the "darwin feature" is a sort of misnomer.  "Darwin" is the name of an operating system upon which macOS is based.  So both "without darwin" and "--disable-darwin" sound unjustifiably demolishing to Mac users.  On this occasion, I propose changing the description in eval.txt and making it more specific.  On macOS, what is known as clipboard in our community is called pasteboard.  

That said, since both the default --enable-darwin option and the MACOS_X_UNIX flag play a crucially important role for the MacVim build system, keeping them as-is is probably the best choice for now.

Patch

--------

The attached patch was made for my ideas above to take shape.

Though the patch is big in size and broad in range, it was actually made in a pretty straightforward manner.  For the convenience of reviewers, leaving a note about the procedure I took might be helpful for review and future reference:

(1) Adjust the code relevant to MAC_CLASSIC so that the codebase will be made independent of it.

(2) Now that MAC_CLASSIC is eliminated, MACOS and MACOS_X are synonym.  In particular, noting that MACOS_X_UNIX implies MACOS_X,

        #if defined(MACOS) && !defined(MACOS_X_UNIX)

is identically false.  Based on those observations, replace MACOS with MACOS_X.

(3) Now that MAC_CLASSIC and MACOS are eliminated, the source code of the Carbon GUI is logically disconnected from the rest of the cadebase.  Remove all the code relevant to the GUI from both the set of source files and the build system.

(4) Do the proposed changes and update the documents accordingly.

As usual, any comment is welcome.  If you find any problem with the patch, please let me know.

Best regards

Kazunobu Kuriyama

[Manuel Ortega]

On Mon, Apr 17, 2017 at 5:19 AM, Kazunobu Kuriyama <kazunobu...@gmail.com> wrote:

This is a followup to https://groups.google.com/forum/#!topic/vim_dev/5RFo3q8xvfo where we talked about the feature list items relevant to Mac:

  On macOS, what is known as clipboard in our community is called pasteboard.  

This is false. In Mac-land, it is called the "clipboard", and has been thus for at least 26 years.

If you go into "Mac Help" from the Help menu of the Finder on Sierra, and search for "pasteboard", you get one result, and in the text of the body of that result it is clear that "clipboard" is the real Mac term.  If you search for "clipboard", you get several results, including some that don't contain "clipboard" but are about copying and pasting.  If in Preview.app you Cmd-C a region of a photo, the Edit menu gives you the option "New from clipboard".  Etc., etc., etc.

In the Apple *developer* docs, what is known in user-land as "the clipboard" is sometimes called the "pasteboard".  But to be intelligible to Mac *users*, Vim should call it what *users* call it.  It is called the "clipboard".

-Manny

[Kazunobu Kuriyama]

Ah, you're right.  I was somehow bound to os_macosx.m too much where the clipboard interface is implemented using NSPasteboard and thus seemingly confused.

How about changing the description in eval.txt from

    macunix  Compiled for macOS with pasteboard support (default) 

to

  macunix  Compiled for macOS with clipboard support (default)

Do you think it's OK for our users?

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

[Marvin Renich]

* Kazunobu Kuriyama <kazunobu...@gmail.com> [170417 05:19]:

> This is a followup to
> https://groups.google.com/forum/#!topic/vim_dev/5RFo3q8xvfo where we talked
> about the feature list items relevant to Mac:
>
> 2017-04-09 21:58 GMT+09:00 Bram Moolenaar <Br...@moolenaar.net>:
> > We should make the feature list a bit more clear about what
> those features mean.
> >
> > I now have:
> >
> > gui_mac Compiled with Macintosh GUI.
> > mac Any Macintosh version of Vim, but not all OS X.
> > macunix Compiled for OS X, with darwin
> > osx Compiled for OS X, with or without darwin
>
>
> Proposal
> -------------
>
> My proposal is to change them as follows:
>
> 'gui_mac' will be abolished by discontinuing maintaining the Carbon GUI
> code and dropped from the list.
>
> The rest of the items will be changed for eval.txt as follows:
>
> mac Any macOS versions of Vim
> macunix Compiled for macOS with pasteboard support (default)
> osx (Deprecated. Use "mac" instead)
>
> Not to mention, macOS implies Mac OS X and OS X.
>
> Personally, I think the item 'osx' can also be dropped on this occation if
> we don't worry much about the backwards compatibility of that particular
> item.

Bram usually does not make changes that have a reasonable chance to
break existing scripts. I'm not a Mac user, but it seems to me that
changing the meaning of existing feature names is very likely to break
existing scripts. 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.

This is just a suggestion, as it is Bram's decision.

...Marvin

[Manuel Ortega]

On Mon, Apr 17, 2017 at 10:41 AM, Kazunobu Kuriyama <kazunobu...@gmail.com> wrote:

2017-04-17 23:24 GMT+09:00 Manuel Ortega <manny...@gmail.com>:

On Mon, Apr 17, 2017 at 5:19 AM, Kazunobu Kuriyama <kazunobu...@gmail.com> wrote:

How about changing the description in eval.txt from

    macunix  Compiled for macOS with pasteboard support (default) 

to

  macunix  Compiled for macOS with clipboard support (default)

Do you think it's OK for our users?

That part is OK.

Line 175 of the patch contains a typo ("MAXOS").

-Manny

[Kazunobu Kuriyama]

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.

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 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 :)

This is just a suggestion, as it is Bram's decision.

...Marvin

Thanks,

Kazunobu 

[Marvin Renich]

* Kazunobu Kuriyama <kazunobu...@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 <mr...@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

[Kazunobu Kuriyama]

2017-04-17 18:19 GMT+09:00 Kazunobu Kuriyama <kazunobu...@gmail.com>:

This is a followup to https://groups.google.com/forum/#!topic/vim_dev/5RFo3q8xvfo where we talked about the feature list items relevant to Mac:

2017-04-09 21:58 GMT+09:00 Bram Moolenaar <Br...@moolenaar.net>:

>  We should make the feature list a bit more clear about what

those features mean.

>

> I now have:

>

> gui_mac                 Compiled with Macintosh GUI.

> mac                     Any Macintosh version of Vim, but not all OS X.

> macunix                 Compiled for OS X, with darwin

> osx                     Compiled for OS X, with or without darwin

The attached is an update of the proposed patch, newly including

(1) Corrections based on the feedback by Manuel Ortega.

(2) Removal of a piece of code enclosed with MAC_OS_CLASSIC in main.c

(3) Removal of a piece of code enclosed with TARGET_API_MAC_OSX in main.c

(4) Corrections to/removals of the source code comments to make them consistent with the proposed patch. 

Thanks to Marvin Renich, I was given a good chance to explain my ideas in detail.  Nonetheless, if there's still something left to be made clear, please ask me for that.

Kazunobu

[Kazunobu Kuriyama]

2017-04-19 21:31 GMT+09:00 Kazunobu Kuriyama <kazunobu...@gmail.com>:

2017-04-17 18:19 GMT+09:00 Kazunobu Kuriyama <kazunobu...@gmail.com>:

This is a followup to https://groups.google.com/forum/#!topic/vim_dev/5RFo3q8xvfo where we talked about the feature list items relevant to Mac:

2017-04-09 21:58 GMT+09:00 Bram Moolenaar <Br...@moolenaar.net>:

>  We should make the feature list a bit more clear about what

those features mean.

>

> I now have:

>

> gui_mac                 Compiled with Macintosh GUI.

> mac                     Any Macintosh version of Vim, but not all OS X.

> macunix                 Compiled for OS X, with darwin

> osx                     Compiled for OS X, with or without darwin

The attached is an update of the proposed patch, newly including

(1) Corrections based on the feedback by Manuel Ortega.

(2) Removal of a piece of code enclosed with MAC_OS_CLASSIC in main.c

(3) Removal of a piece of code enclosed with TARGET_API_MAC_OSX in main.c

Ah, this may sound quite strange.  I should have given a bit more explanation.  Allow me to do that now.

Although TARGET_API_MAC_OSX is defined in the system header file /usr/include/ConditonalMacros.h and set to 1 there for OS X, the header is never included into any of Vim's source directly or indirectly.   As a result, the code enclosed with the constant macro remains unseen from any compiler even if it is compiled on an OS X machine.

Furthermore, as can be seen from the comment given to the code, it is for the Carbon GUI.

Consequently, we can safely remove the code even if it is marked for OS X.

[Bram Moolenaar]

Why not use MACOS everywhere?

> (3) Now that MAC_CLASSIC and MACOS are eliminated, the source code of the
> Carbon GUI is logically disconnected from the rest of the cadebase. Remove
> all the code relevant to the GUI from both the set of source files and the
> build system.
>
> (4) Do the proposed changes and update the documents accordingly.
>
> As usual, any comment is welcome. If you find any problem with the patch,
> please let me know.

We have to make sure this is backwards compatible. Removing any of the
feature names is out of the question. Changing their meaning could be
problemous for plugins.

I still have an old Powerbook, it should be possible to build Vim on it.
Does that still work after these changes?

--
ARTHUR: Well, I AM king...
DENNIS: Oh king, eh, very nice. An' how'd you get that, eh? By exploitin'
the workers -- by 'angin' on to outdated imperialist dogma which
perpetuates the economic an' social differences in our society! If
there's ever going to be any progress--
The Quest for the Holy Grail (Monty Python)

/// Bram Moolenaar -- Br...@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 ///

[Kazunobu Kuriyama]

Bram,

[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.

Owing to the previous phase, MAC_CLASSIC has already been eliminated from the source at this phase.  Nevertheless, there still remain not a few pieces of code covered implicitly with that macro through MACOS (vim.h:102--104).

The purpose of this phase is to eliminate them by removing pieces of code truly specific to MAC_CLASSIC while keeping ones for MACOS_X_UNIX, by distinguishing one from another one by one by inspection.  This is the most hardest part of the job.

Note that, at this phase, while MACOS_X represents only a single possibility (MACOS_X is true if and only if MACOS_X_UNIX is true), there're three different possibilities for MACOS (MACOS is true if either MACOS_X_UNIX is true or MAC_CLASSIC true or both. 

Then, to get the job done, it goes on like this:

If one comes across a snippet like

#if MACOS_X

....

#endif

he doesn't need to do anything for that because he knows the snippet has to be kept for his purpose.

On the other hand, if one comes across a snippet like

#if MACOS

...

#endif

he has to make a decision which case the code is for, MAC_CLASSIC, MACOS_X_UNIX or both.  If one decides to keep it, replace MACOS with MACOS_X; otherwise, remove it.

This makes the job not only easier but also helpful for review and maintenance.  If I adopted MACOS instead of MACOS_X, reviewers and maintainers would always have to keep the three different possibilities in mind and first examine consistency between the ifdef block and its content, and then justify the consequences the block brings to the whole source code.

As for the MACOS_X case, they only need to check consistency for a single case, effectively, only to examine the block content itself.  If they find a problem with it, then they can easily spot which patch is to be blamed and when the problem was introduced (my patch!!).  For the MACOS case, they would need to query the whole commit history and examine every relevant commit one by one.

Furthermore, once the proposed patch is proved to work fine, one can replace MACOS_X with MACOS with ease of ":bufdo %s/pat/str/" at any time when one find himself no longer needs to care about MAC_CLASSIC at any rate and thus knows there's no unmanageable risk with such a batch processing.  If one adopted MACOS from the beginning, that wouldn't be the case.

> (3) Now that MAC_CLASSIC and MACOS are eliminated, the source code of the
> Carbon GUI is logically disconnected from the rest of the cadebase.  Remove
> all the code relevant to the GUI from both the set of source files and the
> build system.
>
> (4) Do the proposed changes and update the documents accordingly.
>
> As usual, any comment is welcome.  If you find any problem with the patch,
> please let me know.

We have to make sure this is backwards compatible. 

I'm actually on the same page as you all.

I'm wondering, however, how the proposed patch is against that general policy.

True, gui_mac, mac, macunix and osx are all four names listed in feature-list, and thus they are called 'feature'.  They are, however, definitely different from other feature items as can be visually checked with the :version command.  

They are different from items designated with (+) or (-).   They rather represent configuration at build time than settings which may vary at runtime.  I'm wondering what backward compatibility means for them which are made hard-coded at build time.  I do think they are enough to show only the facts how the vim in question was configured and built.

Rather, what I'm doing is to try to correct things: If a vim is build for Mac , its has('mac') should always return non-zero regardless of --disable-darwin being used or not; one could also argue that has('mac') returning zero for non-darwin version is an obvious bug.

If backwards compatibility is still an issue of the proposed patch, please try it and run the resulting vim with the existing test suite (N.B. The patch does not include any update for the test suite.  So, simply doing 'make test' will do for the purpose).  

Then, you'll see that the vim with the "new" meanings of mac, macunix, and osx clears all the existing tests written with the current meanings of them in the expected way, and conclude that the proposed patch fulfills the backward compatibility compliance at least for the well-known case.  What could be more expected than that?  In practice, I think that's sufficient.

This is not accidental but rather intentional, because one of the goals of the patch is to keep "has('mac') || has('osx')" invariant before and after the merge of the patch.

 

 

Removing any of the
feature names is out of the question. 

 

It's OK to me to keep 'osx' as is.  Since my latest patch still reserves it, no change is needed for that.  

As for gui_mac, let's recall a precedent example about the GTK GUI. 

While we already dropped GTK+ 1.0 support, we still have gui_gtk.  But the item has changed its meaning.  It no longer means GTK+ 1.0 support but that for both GTK+ 2 and GTK+ 3.  

In addition, the survival was seemingly made possible because there was a succeeding GUI, namely, the GTK+ 2 GUI, when gui_gtk lost its inherent meaning.  

This is not the case for gui_mac.  I'm wondering what's the point to let it take up some space in eval.txt:

   gui_mac    Support discontinued.

doesn't look cool and doesn't seem to be useful.

Changing their meaning could be
problemous for plugins.

As I wrote previously , I estimate the possibility is quite low.  Rather, as there's still no good understanding established about has('mac') and has('osx') even among us, I often suffered from test failure due to wrongly written tests and was forced to investigate the cause of it by suspending my other work.

To me, it is the fact that the current has('mac')  brings losses to my work for Vim development.  It's absolutely better for me to fix this real issue instead of worrying about possible future breakage which I don't believe in. 

I still have an old Powerbook, it should be possible to build Vim on it.
Does that still work after these changes?

If it's a Mac OS X machine, that should be possible unless you ask the Carbon GUI.  As for an OS 9 machine, version7.txt:108 says: "The support for Mac OS 9 has been removed." 

Nevertheless, there's still things I have to note about the current codebase.  

In vim.h, we define MACOS_CLASSIC if another macro called 'macintosh' is already defined somewhere.  In main.c, we have an ifdef block with MAC_OS_CLASSIC (sic).  If that's not a typo, it proves how poorly the Mac code has been maintained so far, doesn't it?

I guess those two macros, macintosh and MAC_OS_CLASSIC, come from system header files of classic Mac, because the remnants of them are still can been seen in /usr/include/tidy in current Mac.  

Arguably, one can say the classic Mac code is still alive.

It appears to me, however, that the current build system no longer supports build on that classic platform because 'make' on a fresh 'vim/src' automatically invokes the configure script and that invocation prevents defining a constant macro named UNIX properly.   This is likely to cause a build or runtime error.  IMHO, this is another evidence of poor maintenance.  

That said, I may be wrong; Vim can actually be compiled on class Mac, though.  I can't see if it's possible or not reading Makefile and configure.ac at glance.  That might be another maintenance issue.

Regards,

Kazunobu

[Bram Moolenaar]

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 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.

The terms "with darwin" and "without darwin" are very confusing. There
is no help for "darwin". Cleaning that up sounds like a good idea.

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.

How about Carbon? On my Mac air it appears not to work, Quickdraw.h is
missing.

Anyway, I think this change should be split into smaller pieces to make
it easier to see what changes.


--
The question is: What do you do with your life?
The wrong answer is: Become the richest guy in the graveyard.
(billionaire and Oracle founder Larry Ellison)

[Kazunobu Kuriyama]

2017-04-21 1:48 GMT+09:00 Bram Moolenaar <Br...@moolenaar.net>:

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?

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.

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.

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.

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.

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.

(2) Removal of FEAT_GUI_MAC related code and adjustments of the build system.

(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.

(4) Correct the meaning of the feature list item 'mac'.

Each phase has its own patch and will be accompanied with document update.

Kazunobu

[Manuel Ortega]

On Sat, Apr 22, 2017 at 9:11 AM, Kazunobu Kuriyama <kazunobu...@gmail.com> wrote:

2017-04-21 1:48 GMT+09:00 Bram Moolenaar <Br...@moolenaar.net>:

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.

I seem to remember, from a while back, that "disabling darwin" has a bigger effect than just disconnecting Vim from the macOS clipboard.  Something about it messed up (believe it or not) the precomposition (or lack thereof) of unicode, particularly when one did something like ":r !some-cmd".  I think there was a report about this on the vim_mac list a long time ago.

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.

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.

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.

I think you are underestimating the Carbon build.  The Carbon GUI is only broken for recent versions of macOS, where there is independently no reason to ask for it because there is MacVim which is infinitely superior.  There is no "work needed to restore it", because there is no need to restore it, because it builds fine on 10.8 and under (and will even run on macOS Sierra): https://sourceforge.net/projects/macosxvim/files.  As far as I know it works just fine even on macOS 10.4 and 10.5.

Maybe the reason there haven't been bug reports is because the people that have a reason to use it are using it on a machine for which it still works.  Why would anyone be using a machine that's 32 bit and with an older macOS?  Because the machines still work fine for doing work in a text editor, even though they're not good for internet videos or photoshop.

On top of this, people on 10.7 and less have been ruthlessly dumped by MacVim.  (You can bet it won't be long before the trigger-happy MacVim devs dump 10.8 and 10.9).  This means those people would have no Vim GUI whatsoever if you dump the Carbon GUI.  (The X11 GUI on the Mac is worse than nothing, which is not Vim's fault, but is because of the X11 emulators.)

It may be that when all is said and done Carbon should still be dumped anyway, but it is not true that (a) nobody uses it, or (b) that nobody *could* use it, or (c) that keeping it would require a lot of work.

-Manny

[Bram Moolenaar]

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.

[Kazunobu Kuriyama]

2017-04-23 0:02 GMT+09:00 Manuel Ortega <manny...@gmail.com>:

On Sat, Apr 22, 2017 at 9:11 AM, Kazunobu Kuriyama <kazunobu...@gmail.com> wrote:

2017-04-21 1:48 GMT+09:00 Bram Moolenaar <Br...@moolenaar.net>:

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.

I seem to remember, from a while back, that "disabling darwin" has a bigger effect than just disconnecting Vim from the macOS clipboard.  Something about it messed up (believe it or not) the precomposition (or lack thereof) of unicode, particularly when one did something like ":r !some-cmd".  I think there was a report about this on the vim_mac list a long time ago.

Wasn't that issue fixed later?  I don't see any glitch with --disable-darwin build for these 6 years...

 

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.

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.

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.

I think you are underestimating the Carbon build.  The Carbon GUI is only broken for recent versions of macOS, where there is independently no reason to ask for it because there is MacVim which is infinitely superior.  There is no "work needed to restore it", because there is no need to restore it, because it builds fine on 10.8 and under (and will even run on macOS Sierra): https://sourceforge.net/projects/macosxvim/files.  As far as I know it works just fine even on macOS 10.4 and 10.5.

Alas, the reason why I mentioned the exact versions and dates was to avoid this sort of misunderstanding...

Maybe the reason there haven't been bug reports is because the people that have a reason to use it are using it on a machine for which it still works.  Why would anyone be using a machine that's 32 bit and with an older macOS?  Because the machines still work fine for doing work in a text editor, even though they're not good for internet videos or photoshop.

On top of this, people on 10.7 and less have been ruthlessly dumped by MacVim.  (You can bet it won't be long before the trigger-happy MacVim devs dump 10.8 and 10.9).  This means those people would have no Vim GUI whatsoever if you dump the Carbon GUI.  (The X11 GUI on the Mac is worse than nothing, which is not Vim's fault, but is because of the X11 emulators.)

Believe or not, the GTK+ 3 GUI was fully developed on XQuartz running on OS X.  Actually, almost all of recent implementation changes in the X11-based GUIs (Athena, Motif, GTK+ 2 and 3) were all developed and tested, and the resulting patches were sent to vim_dev.  XQuartz is not an emulator, but a full-fledge implementation of X11 for OS X.

I do wish someone on Linux comes up and works for the GUIs, taking over the role I'm now playing for Vim.  Till then, I want to continue working with Mac.  For that purpose, I want to make my work more efficient and productive.  That's my primary reason why I'm now trying to improve the code of Vim for Mac, though I have little complaint about the performance and functionality of the current Vim.

Recently, I often com across a lot of pictures of Vim running on Mac and Mac-related Vim questions at user forums on the Internet.  Though I don't have any of statistics, it seems that vimmers on Mac have been rapidly increasing in number.  Maybe, code and documents that are well taken care of can be helpful to gain their confidence in Vim.  That's my secondary reason, though I regard it as a by-product of my primary motivation.

TBH, I rather feel like working for them and myself than people invisible from me, though I don't deny the existence of them at all.

Kazunobu

It may be that when all is said and done Carbon should still be dumped anyway, but it is not true that (a) nobody uses it, or (b) that nobody *could* use it, or (c) that keeping it would require a lot of work.

-Manny

--

[Manuel Ortega]

On Sat, Apr 22, 2017 at 1:14 PM, Kazunobu Kuriyama <kazunobu...@gmail.com> wrote:

2017-04-23 0:02 GMT+09:00 Manuel Ortega <manny...@gmail.com>:

On Sat, Apr 22, 2017 at 9:11 AM, Kazunobu Kuriyama <kazunobu...@gmail.com> wrote:

2017-04-21 1:48 GMT+09:00 Bram Moolenaar <Br...@moolenaar.net>:

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.

I seem to remember, from a while back, that "disabling darwin" has a bigger effect than just disconnecting Vim from the macOS clipboard.  Something about it messed up (believe it or not) the precomposition (or lack thereof) of unicode, particularly when one did something like ":r !some-cmd".  I think there was a report about this on the vim_mac list a long time ago.

Wasn't that issue fixed later?  I don't see any glitch with --disable-darwin build for these 6 years...

 

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.

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.

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.

I think you are underestimating the Carbon build.  The Carbon GUI is only broken for recent versions of macOS, where there is independently no reason to ask for it because there is MacVim which is infinitely superior.  There is no "work needed to restore it", because there is no need to restore it, because it builds fine on 10.8 and under (and will even run on macOS Sierra): https://sourceforge.net/projects/macosxvim/files.  As far as I know it works just fine even on macOS 10.4 and 10.5.

Alas, the reason why I mentioned the exact versions and dates was to avoid this sort of misunderstanding...

What misunderstanding is that?  You listed versions and dates and then, despite the fact that the Carbon GUI is usable for older Macs, declared that we should get rid of it---on the grounds that (1) it doesn't work anymore and would be nearly impossible to "restore", and (2) that the Carbon GUI is only for people with 64 bit Macs who nevertheless want a 32bit Vim GUI (and that (3) you are *definitely* the only such person anyway).

(2) and (3) are false, and (1) doesn't apply in the slightest to older Macs (10.4-10.6 at *least*, maybe even up to 10.8), which are not ancient or obscure compared to the sort of stuff that Vim generally bends over backwards to support.

-Manny

[Manuel Ortega]

On Sat, Apr 22, 2017 at 1:14 PM, Kazunobu Kuriyama <kazunobu...@gmail.com> wrote:

2017-04-23 0:02 GMT+09:00 Manuel Ortega <manny...@gmail.com>:

On Sat, Apr 22, 2017 at 9:11 AM, Kazunobu Kuriyama <kazunobu...@gmail.com> wrote:

2017-04-21 1:48 GMT+09:00 Bram Moolenaar <Br...@moolenaar.net>:

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.

I seem to remember, from a while back, that "disabling darwin" has a bigger effect than just disconnecting Vim from the macOS clipboard.  Something about it messed up (believe it or not) the precomposition (or lack thereof) of unicode, particularly when one did something like ":r !some-cmd".  I think there was a report about this on the vim_mac list a long time ago.

Wasn't that issue fixed later?  I don't see any glitch with --disable-darwin build for these 6 years...

No, it was not.  I'm not sure if it's a bug, but Vim behaves differently regarding Unicode precomposition depending on whether --disable-darwin is passed.

If I `touch` some nonACII filenames like "föo" and "bár" (in a terminal operating in utf-8), and then fire up vim in that directory where the touches happened, and then do:

   :let @a = glob("*") | put a

Then doing a `ga` (or `g8`) over the multibyte characters will display something different depending on whether --disable-darwin was passed or not.

If --disable-darwin is passed during build, then:

  * `ga` over the "ö" in "föo" shows:

      <o>  111,  Hex 6f,  Octal 157 < ̈> 776, Hex 0308, Octal 1410

  * `g8` over that same character shows: 6f + cc 88

If --disable-darwin is NOT passed during build, then the same operations show:

  * `ga`: <ö> 246, Hex 00f6, Octal 366

  * `g8`: c3 b6

Again, I don't know whether this is an actual *bug* (or *why* it's happening), but it just isn't true that the only difference between --disable-darwin or --enable-darwin is the clipboard.  There is more at work, and it should be documented to the extent anyone can figure out what's going on.

-Manny

[Christian Brabandt]

On So, 23 Apr 2017, Kazunobu Kuriyama wrote:

> I do wish someone on Linux comes up and works for the GUIs, taking
> over the role I'm now playing for Vim.  Till then, I want to continue
> working with Mac.  For that purpose, I want to make my work more
> efficient and productive.  That's my primary reason why I'm now trying
> to improve the code of Vim for Mac, though I have little complaint
> about the performance and functionality of the current Vim.

And that is really appreciated! I am glad that you are there and can
look into gui specific features and bugs as I don't feel competent
enough to do so, so I am happy that you do. So let me thanks for all the
effort you are putting into maintaining the GUI stuff.

> TBH, I rather feel like working for them and myself than people
> invisible from me, though I don't deny the existence of them at all.

Understandable.

Mit freundlichen Grüßen
Christian
--
Ein schwacher Verstand ist wie ein Mikroskop, das Kleinigkeiten
vergrößert und große Dinge nicht erfaßt.
-- Lord Chesterfield

[Bram Moolenaar]

Unfortunately, it looks like the harddisk died just now. So I won't be
able to try out things on OS X 10.4. I hope someone else has an older
OS X version to verify the Carbon code still works.

--
If your life is a hard drive,
Christ can be your backup.