Re: [patch] Clean up Mac code
I wrote:
> 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.
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.
/// 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.
Re: [patch] Clean up Mac code
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 -- -- 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.
Re: [patch] Clean up Mac code
On Sat, Apr 22, 2017 at 1:14 PM, Kazunobu Kuriyama <
kazunobu.kuriy...@gmail.com> wrote:
> 2017-04-23 0:02 GMT+09:00 Manuel Ortega :
>
>> On Sat, Apr 22, 2017 at 9:11 AM, Kazunobu Kuriyama <
>> kazunobu.kuriy...@gmail.com> wrote:
>>
>>> 2017-04-21 1:48 GMT+09:00 Bram Moolenaar :
>>>
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:
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
--
--
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.
Re: [patch] Clean up Mac code
On Sat, Apr 22, 2017 at 1:14 PM, Kazunobu Kuriyama < kazunobu.kuriy...@gmail.com> wrote: > 2017-04-23 0:02 GMT+09:00 Manuel Ortega : > >> On Sat, Apr 22, 2017 at 9:11 AM, Kazunobu Kuriyama < >> kazunobu.kuriy...@gmail.com> wrote: >> >>> 2017-04-21 1:48 GMT+09:00 Bram Moolenaar : >>> 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 -- -- 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.
Re: [patch] Clean up Mac code
2017-04-23 0:02 GMT+09:00 Manuel Ortega : > On Sat, Apr 22, 2017 at 9:11 AM, Kazunobu Kuriyama < > kazunobu.kuriy...@gmail.com> wrote: > >> 2017-04-21 1:48 GMT+09:00 Bram Moolenaar : >> >>> >>> >>> 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 conf
Re: [patch] Clean up Mac code
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
Re: [patch] Clean up Mac code
On Sat, Apr 22, 2017 at 9:11 AM, Kazunobu Kuriyama < kazunobu.kuriy...@gmail.com> wrote: > 2017-04-21 1:48 GMT+09:00 Bram Moolenaar : > >> >> >> 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 -- -- 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.
Re: [patch] Clean up Mac code
2017-04-21 1:48 GMT+09:00 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?
> 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
>
>
> --
> 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)
>
> /// 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.
Re: [patch] Clean up Mac code
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)
/// 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.
Re: [patch] Clean up Mac code
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 : > > 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 : > > > 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 tr
Re: [patch] Clean up Mac code
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 : > > 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? > (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 -- 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/// \\\
Re: [patch] Clean up Mac code
2017-04-19 21:31 GMT+09:00 Kazunobu Kuriyama : > 2017-04-17 18:19 GMT+09:00 Kazunobu Kuriyama > : > >> This is a followup to https://groups.google.com/foru >> m/#!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 : >> > 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. (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 > -- -- 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.
Re: [patch] Clean up Mac code
2017-04-17 18:19 GMT+09:00 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 : > > 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 -- -- 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. mac-cleanup-update01.patch.gz Description: GNU Zip compressed data
Re: [patch] Clean up Mac code
* Kazunobu Kuriyama [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 :
> > 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.
Re: [patch] Clean up Mac code
2017-04-18 2:49 GMT+09:00 Marvin Renich :
> * Kazunobu Kuriyama [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 :
> > > 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.
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
>
> --
> --
> 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.
>
--
--
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.
Re: [patch] Clean up Mac code
On Mon, Apr 17, 2017 at 10:41 AM, Kazunobu Kuriyama <
kazunobu.kuriy...@gmail.com> wrote:
> 2017-04-17 23:24 GMT+09:00 Manuel Ortega :
>
>> On Mon, Apr 17, 2017 at 5:19 AM, Kazunobu Kuriyama <
>> kazunobu.kuriy...@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
> --
>> --
>> 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.
>>
>
> --
> --
> 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.
>
--
--
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.
Re: [patch] Clean up Mac code
* Kazunobu Kuriyama [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 : > > 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 -- -- 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.
Re: [patch] Clean up Mac code
2017-04-17 23:24 GMT+09:00 Manuel Ortega : > On Mon, Apr 17, 2017 at 5:19 AM, Kazunobu Kuriyama < > kazunobu.kuriy...@gmail.com> wrote: > >> This is a followup to https://groups.google.com/foru >> m/#!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 > 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+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- 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.
Re: [patch] Clean up Mac code
On Mon, Apr 17, 2017 at 5:19 AM, Kazunobu Kuriyama < kazunobu.kuriy...@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 -- -- 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.
[patch] Clean up Mac code
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 : > 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 -- -- 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. mac-cleanup.patch.gz Description: GNU Zip compressed data
