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.
2017-04-20 4:42 GMT+09:00 Bram Moolenaar <b...@moolenaar.net>: > > Kazunobu Kuriyama 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: > > > > 2017-04-09 21:58 GMT+09:00 Bram Moolenaar <b...@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. > > Why not use MACOS everywhere? > 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 > > -- > 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 -- 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.
