Nextstep build uses iso-latin by default. WHY?

Nextstep build uses iso-latin by default. WHY?

[Angelo Graziosi]

Changes between Feb. 10 and Feb. 27 have modified the default behavior 
of the NS build on OSX (at least on master).

Now (with no ~/.emacs.d nor other initialization files), "C-x C-f 
foo.txt" creates foo.txt with iso-latin-1. For ages it was similar to 
the behavior on GNU/Linux.

I don't understand why you adopted this change..

How can I restore the previous behavior?

   Angelo

Re: Nextstep build uses iso-latin by default. WHY?

[Eli Zaretskii]

> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Date: Fri, 11 Mar 2016 21:27:05 +0100
> 
> Now (with no ~/.emacs.d nor other initialization files), "C-x C-f 
> foo.txt" creates foo.txt with iso-latin-1. For ages it was similar to 
> the behavior on GNU/Linux.

What is your locale, as known to Emacs when it starts?

> I don't understand why you adopted this change..

It was discussed here:

  http://lists.gnu.org/archive/html/emacs-devel/2016-02/msg00000.html
  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22392

Why do you think Emacs should use a UTF-8 locale in your case?

> How can I restore the previous behavior?

If you only want to have the files' default encoding be UTF-8, add
this to your ~/.emacs:

  (setq-default buffer-file-coding-system 'utf-8)

If you want to override your entire locale with UTF-8, do this:

  (set-locale-environment "utf-8")

Re: Nextstep build uses iso-latin by default. WHY?

[Angelo Graziosi]

Il 11/03/2016 21:49, Eli Zaretskii ha scritto:
>> From: Angelo Graziosi <angelo.graziosi@alice.it>
>> Date: Fri, 11 Mar 2016 21:27:05 +0100
>>
>> Now (with no ~/.emacs.d nor other initialization files), "C-x C-f
>> foo.txt" creates foo.txt with iso-latin-1. For ages it was similar to
>> the behavior on GNU/Linux.
>
> What is your locale, as known to Emacs when it starts?
>
>> I don't understand why you adopted this change..
>
> It was discussed here:
>
>    http://lists.gnu.org/archive/html/emacs-devel/2016-02/msg00000.html
>    http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22392
>
> Why do you think Emacs should use a UTF-8 locale in your case?

I use OSX since 2011 and the behavior of Emacs has always been that 
way.. I have a MBP in which OSX is in Italian but the keyboard is US.

 From Terminal:

$ locale
LANG="it_IT.UTF-8"
LC_COLLATE="it_IT.UTF-8"
LC_CTYPE="it_IT.UTF-8"
LC_MESSAGES="it_IT.UTF-8"
LC_MONETARY="it_IT.UTF-8"
LC_NUMERIC="it_IT.UTF-8"
LC_TIME="it_IT.UTF-8"
LC_ALL=

but (getenv "LANG") shows 'it_IT'...

BTW, I have also GNU/Linux Mint 17.3 (Mate) (in dual boot with W7) on a 
PC with US keyboard (I would say the same model of MBP). It is in 
Italian and from Terminal,

$ locale
LANG=it_IT.UTF-8
LANGUAGE=
LC_CTYPE="it_IT.UTF-8"
LC_NUMERIC="it_IT.UTF-8"
LC_TIME="it_IT.UTF-8"
LC_COLLATE="it_IT.UTF-8"
LC_MONETARY="it_IT.UTF-8"
LC_MESSAGES="it_IT.UTF-8"
LC_PAPER="it_IT.UTF-8"
LC_NAME="it_IT.UTF-8"
LC_ADDRESS="it_IT.UTF-8"
LC_TELEPHONE="it_IT.UTF-8"
LC_MEASUREMENT="it_IT.UTF-8"
LC_IDENTIFICATION="it_IT.UTF-8"
LC_ALL=

but here the behavior is what I expect..

>
>> How can I restore the previous behavior?
>
> If you only want to have the files' default encoding be UTF-8, add
> this to your ~/.emacs:
>
>    (setq-default buffer-file-coding-system 'utf-8)
>
> If you want to override your entire locale with UTF-8, do this:
>
>    (set-locale-environment "utf-8")
>

OK,
  Angelo.

Re: Nextstep build uses iso-latin by default. WHY?

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Date: Fri, 11 Mar 2016 23:18:48 +0100
> 
>  From Terminal:
> 
> $ locale
> LANG="it_IT.UTF-8"
> LC_COLLATE="it_IT.UTF-8"
> LC_CTYPE="it_IT.UTF-8"
> LC_MESSAGES="it_IT.UTF-8"
> LC_MONETARY="it_IT.UTF-8"
> LC_NUMERIC="it_IT.UTF-8"
> LC_TIME="it_IT.UTF-8"
> LC_ALL=
> 
> but (getenv "LANG") shows 'it_IT'...

But the problem is not in the Emacs session started from the
terminal, is it?  AFAIR, the change was only for session that didn't
begin from the shell.

Re: Nextstep build uses iso-latin by default. WHY?

[Angelo Graziosi]

Il 12/03/2016 07:54, Eli Zaretskii ha scritto:
>> Cc: emacs-devel@gnu.org
>> From: Angelo Graziosi <angelo.graziosi@alice.it>
>> Date: Fri, 11 Mar 2016 23:18:48 +0100
>>
>>   From Terminal:
>>
>> $ locale
>> LANG="it_IT.UTF-8"
>> LC_COLLATE="it_IT.UTF-8"
>> LC_CTYPE="it_IT.UTF-8"
>> LC_MESSAGES="it_IT.UTF-8"
>> LC_MONETARY="it_IT.UTF-8"
>> LC_NUMERIC="it_IT.UTF-8"
>> LC_TIME="it_IT.UTF-8"
>> LC_ALL=
>>
>> but (getenv "LANG") shows 'it_IT'...
>
> But the problem is not in the Emacs session started from the
> terminal, is it?  AFAIR, the change was only for session that didn't
> begin from the shell.
>

When Emacs starts from the Dock (i.e. not from the shell) it "sees" 
LANG=it_IT and not LANG=it_IT.UTF-8 as when it starts from the shell..

Stefan Monnier wrote:
> The OSX environment has always had a very strong bias towards utf-8, so
> in the absence of a strong indication that something else than utf-8 is
> desired, we should always use utf-8 on that platform.


   Angelo

Re: Nextstep build uses iso-latin by default. WHY?

[Stefan Monnier]

> If you only want to have the files' default encoding be UTF-8, add
> this to your ~/.emacs:
>   (setq-default buffer-file-coding-system 'utf-8)

The OSX environment has always had a very strong bias towards utf-8, so
in the absence of a strong indication that something else than utf-8 is
desired, we should always use utf-8 on that platform.


        Stefan

Re: Nextstep build uses iso-latin by default. WHY?

[Alan Third]

On Fri, Mar 11, 2016 at 05:41:11PM -0500, Stefan Monnier wrote:
> > If you only want to have the files' default encoding be UTF-8, add
> > this to your ~/.emacs:
> >   (setq-default buffer-file-coding-system 'utf-8)
> 
> The OSX environment has always had a very strong bias towards utf-8, so
> in the absence of a strong indication that something else than utf-8 is
> desired, we should always use utf-8 on that platform.

I asked a question about this before the changes were made, but nobody
seemed to know the answer. I guess you maybe just missed the thread.

Forcing Emacs to use UTF-8 would be trivial, we're currently pulling
the locale value from the OS, and as far as I can tell it's always
returned as something like "en_GB" rather than "en_GB.UTF-8". We can
just append ".UTF-8" to the string before running setenv.

My biggest concern about that is that I don't know if there are
situations where [NSLocale localeIdentifier] will return ".UTF-8" or
something else.

Here's a patch to force UTF-8:

src/nsterm.m (ns_init_locale): Append .UTF-8 to locale string.
---
 src/nsterm.m | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index b796193..afb3357 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -596,8 +596,15 @@ ns_init_locale (void)
 
   @try
     {
+      /* It seems OS X should probably use UTF-8 everywhere.
+         'localeIdentifier' does not specify the encoding, and I can't
+         find any way to get the OS to tell us which encoding to use,
+         so hard-code '.UTF-8'. */
+      NSString *localeID = [NSString stringWithFormat:@"%@.UTF-8",
+                                     [locale localeIdentifier]];
+
       /* Set LANG to locale, but not if LANG is already set. */
-      setenv("LANG", [[locale localeIdentifier] UTF8String], 0);
+      setenv("LANG", [localeID UTF8String], 0);
     }
   @catch (NSException *e)
     {
-- 
Alan Third

Re: Nextstep build uses iso-latin by default. WHY?

[Stefan Monnier]

> My biggest concern about that is that I don't know if there are
> situations where [NSLocale localeIdentifier] will return ".UTF-8" or
> something else.

We could look for a "." and only add ".utf-8" if there isn't a "." already.

> Here's a patch to force UTF-8:

Looks OK to me.  Thanks,


        Stefan

Re: Nextstep build uses iso-latin by default. WHY?

[Alan Third]

On Sun, Mar 20, 2016 at 03:11:23PM +0000, Alan Third wrote:
> Here's a patch to force UTF-8:

Hi, Can someone please commit the patch? I don't have write access to
the repository. I can resend it if neccessary.

--
Alan Third

Re: Nextstep build uses iso-latin by default. WHY?

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

Hi Alan!


> Hi, Can someone please commit the patch? I don't have write access to
> the repository. I can resend it if neccessary.
>

Done!

Thanks for working on this!

    -- Anders

Ps. As I have mentioned before -- anyone interested in working on the NS
port is more than welcome to do so!

[-- Attachment #2: Type: text/html, Size: 635 bytes --]

Re: Nextstep build uses iso-latin by default. WHY?

[Toon Claes]

> On 08 Apr 2016, at 15:57, Anders Lindgren <andlind@gmail.com> wrote:
> 
> Ps. As I have mentioned before -- anyone interested in working on the NS port is more than welcome to do so!

Hi Anders,

I might be interested.
What do you expect from us?

Regards,
Toon

Re: Nextstep build uses iso-latin by default. WHY?

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1618 bytes --]

> > Ps. As I have mentioned before -- anyone interested in working on the
NS port is more than welcome to do so!

> I might be interested.
> What do you expect from us?


It all depends on your ambition level, of course... ;-)

To make a long story short. The maintainer before me did a very good job
for a number of years. When I found out that he had retired, I took over,
as I had some knowledge of the NS code base having implemented
multi-monitor support and support for auto-hiding the menu bar.

Unfortunately, I don't have to time to do all of the heavy lifting myself
any more. However, I have no plans to leave the Emacs world. Ideally, I
would like to find a group of people interested in the NS port, this would
allow us to share the work and to have people to discuss things with.

Things that is "expected" of you are:

* Fixing bugs. For example, making sure the Emacs frames are resized and
placed properly in various situations, that fringe icons are rendered
correctly etc.
* Eye-balling patches from other developers (like Alans locale patch)
* Make sure the NS interface support many (if not all) features Emacs
expect it to have
* Add OS X-specific features (while still respecting the FSF policy that
features should not only be available on non-free systems)
* Refactor and documenting the code
* Add tests (it's a good place to document corner cases and it reduces the
"what breaks if I change this" anxiety)
* To learn new things and having fun doing it!

A good start is reading "nextstep/README" and the NS port wishlist found in
"etc/TODO" under the heading "NeXTstep port".

    -- Anders

[-- Attachment #2: Type: text/html, Size: 1871 bytes --]

Re: Nextstep build uses iso-latin by default. WHY?

[John Wiegley]

>>>>> Anders Lindgren <andlind@gmail.com> writes:

> Unfortunately, I don't have to time to do all of the heavy lifting myself
> any more. However, I have no plans to leave the Emacs world. Ideally, I
> would like to find a group of people interested in the NS port, this would
> allow us to share the work and to have people to discuss things with.

Plus, your maintainer will be eternally grateful to you, since this is the
port that I use daily now, and every bit of polish is felt on a continual
basis. :)

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Nextstep build uses iso-latin by default. WHY?

[Toon Claes]

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

Anders Lindgren <andlind@gmail.com> writes:

> * Add OS X-specific features (while still respecting the FSF policy
> that features should not only be available on non-free systems) 

Well, recently I switched from Railwaycat's Mac port
(at https://github.com/railwaycat/mirror-emacs-mac) to the official
Emacs version (installed using Homebrew).
I never understood why Railwaycat's changes are not merged to the
official repo, but is it because of that FSF policy?

I really would like to help make the official Emacs work better on OS X,
but if I understand it correctly, not everything is allowed?

But I'll start going through the bugs to see where I can help and so try
to getter a better understanding of the source code.


---
Toon Claes
toon@iotcl.com
PGP key fingerprint = AA9A A457 F944 B972 83D4  A177 3114 3A82 D32B 3897

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

Re: Nextstep build uses iso-latin by default. WHY?

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 2149 bytes --]

Hi!


> > * Add OS X-specific features (while still respecting the FSF policy
> > that features should not only be available on non-free systems)
>
> Well, recently I switched from Railwaycat's Mac port
> (at https://github.com/railwaycat/mirror-emacs-mac) to the official
> Emacs version (installed using Homebrew).
> I never understood why Railwaycat's changes are not merged to the
> official repo, but is it because of that FSF policy?
>

That is only part of the story. But, yes, the "mac" port has more freedom
as it's not official FSF software.

The "mac" port originates from an Emacs implementation on Mac OS Classic
whereas the NS port comes from NextSTEP, before the two were merged with OS
X. Amazingly, both are still being actively maintained. Internally,
however, they are totally different, the "mac" port is written in C based
on the Carbon API, while the NS port is implemented in Objective-C and use
the Cocoa API. This makes it hard to simply "merge" a feature fromt the
"mac" port to the NS port, and vice versa.


I really would like to help make the official Emacs work better on OS X,
> but if I understand it correctly, not everything is allowed?
>

Yes, that is correct. A recent example is that support for fonts with
colors has been disabled awaiting it being supported on a free system.

However, there are many ways we can make Emacs on OS X better without
breaking the FSF policy.


But I'll start going through the bugs to see where I can help and so try
> to getter a better understanding of the source code.
>

Welcome aboard!

The bug database is hard to navigate -- it's hard to find NS-specific bugs
since there is way of tagging a bug as NS- or OS X-specific and the search
function doesn't work so well (e.g. searching for "MAC" match every bug
containing the word "eMACs"...). I suggest that you start by looking at
recent unresolved bugs (like bug#22973) or the issues listed in etc/TODO.

Feel free to ask me questions, either directly, or by starting a generic
"NS port" thread here at emacs-devel. (In the future, if more people would
join, we could have a dedicated NS port mailing list.)

    -- Anders

[-- Attachment #2: Type: text/html, Size: 3360 bytes --]

Regexp search in debbugs (was: Nextstep build uses iso-latin by default. WHY?)

[Michael Albinus]

Anders Lindgren <andlind@gmail.com> writes:

> Hi!

Hi,

> The bug database is hard to navigate -- it's hard to find NS-specific
> bugs since there is way of tagging a bug as NS- or OS X-specific and
> the search function doesn't work so well (e.g. searching for "MAC"
> match every bug containing the word "eMACs"...). I suggest that you
> start by looking at recent unresolved bugs (like bug#22973) or the
> issues listed in etc/TODO.

You could search for regexp in the debbugs database. Install the debbugs
package from GNU ELPA, and perform the following command:

M-x debbugs-gnu-search <RET> [RX] ^mac$ <RET> package <RET> emacs <RET> <RET>

<RET> means the return key. "[RX] ^mac$" is the query you have to enter
(w/o apostrophes). It's a little bit strange syntax; read the debbugs
user guide for further explanation. "package" and "emacs" limit the
search to Emacs related problems; debbugs hosts also bugs for other GNU
projects.

It will take a while to search, then you get 2006 hits, where the word
"mac" has been used in the bug messages (case insensitive). This
includes all closed and archived bugs. In order to filter them out,
press x (the key "x"), and you will see 428 still open bugs, which
contain the word "mac".

> -- Anders

Best regards, Michael.

Re: Regexp search in debbugs

[Lars Magne Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> You could search for regexp in the debbugs database. Install the debbugs
> package from GNU ELPA, and perform the following command:
>
> M-x debbugs-gnu-search <RET> [RX] ^mac$ <RET> package <RET> emacs <RET> <RET>

You can also just `M-x debbugs-gnu' and then use the `/' command to
limit to the bugs that have a matching regexp in the subject.  (This is
what I do when triaging bugs.)

`/ \bns\b|\bmac\b' should find quite a few of the relevant open bugs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Nextstep build uses iso-latin by default. WHY?

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 14 Apr 2016 11:31:26 +0200, Anders Lindgren <andlind@gmail.com> said:

> The "mac" port originates from an Emacs implementation on Mac OS
> Classic whereas the NS port comes from NextSTEP, before the two were
> merged with OS X. Amazingly, both are still being actively
> maintained. Internally, however, they are totally different, the
> "mac" port is written in C based on the Carbon API, while the NS
> port is implemented in Objective-C and use the Cocoa API.

As of Emacs 24.5-based version, the Mac port contains Objective-C LOC
as much as the NS port does.

$ wc -l macappkit.?
    1153 macappkit.h
   15285 macappkit.m
   16438 total

$ wc -l ns*
    3015 nsfns.m
    1542 nsfont.m
     202 nsgui.h
     449 nsimage.m
    1960 nsmenu.m
     599 nsselect.m
     926 nsterm.h
    7811 nsterm.m
   16504 total

Of course, the Mac port also contains C code as well as Objective-C
code, but mostly not on the Carbon API.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Nextstep build uses iso-latin by default. WHY?

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 14 Apr 2016 11:31:26 +0200, Anders Lindgren <andlind@gmail.com> said:

> The "mac" port originates from an Emacs implementation on Mac OS
> Classic whereas the NS port comes from NextSTEP, before the two were
> merged with OS X. Amazingly, both are still being actively
> maintained. Internally, however, they are totally different,

This is true.

> the "mac" port is written in C based on the Carbon API, while the NS
> port is implemented in Objective-C and use the Cocoa API.

But this is not.  At least, the Mac port uses the following
Objective-C Cocoa APIs/frameworks that are not used in the NS port:

  Core Animation
  Core Image
  OSAKit
  PDFKit (for rendering PDF data via `image-io' or `imagemagick' image types)
  WebKit (for rendering SVG data via `svg' image type)

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Nextstep build uses iso-latin by default. WHY?

[Stefan Monnier]

> But this is not.  At least, the Mac port uses the following
> Objective-C Cocoa APIs/frameworks that are not used in the NS port:

>   Core Animation
>   Core Image
>   OSAKit
>   PDFKit (for rendering PDF data via `image-io' or `imagemagick' image types)
>   WebKit (for rendering SVG data via `svg' image type)

I'd love to see some further consolidation between the two ports (like
we've seen recently with the macfont.m, IIUC).


        Stefan

Re: Nextstep build uses iso-latin by default. WHY?

[John Wiegley]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I'd love to see some further consolidation between the two ports (like we've
> seen recently with the macfont.m, IIUC).

Me too, very much.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Nextstep build uses iso-latin by default. WHY?

[Stefan Monnier]

> I never understood why Railwaycat's changes are not merged to the
> official repo, but is it because of that FSF policy?

No, that policy doesn't have anything to do with it (tho of course,
that policy means that the mac port got changes which we wouldn't want
to include in Emacs).

The reason is mostly historical: the mac port is based on the macosx
support that was present in older Emacsen.  At some point that code
ended up without anyone willing to maintain it, whereas there was
a newer macosx port available using the a newer API, which also happened
to be the API used in GNUstep.  So that alternative port had everything
going for it: actively maintained, using a newer API with a brighter
future (the API that Emacs was using at that point had an uncertain
future), and it supported not only macosx but also GNUstep.

So Emacs switched to that "NS" port.  More or less around that same
time, Yamamoto Mitsuharu started to work on the "old" code and adapt it
to the newer version of the old API.  And here we are.

There's no point in Emacs coming with two different macosx ports, so
incorporating Yamamoto Mitsuharu's version into Emacs would mean
dropping the current "ns port" and that comes with various downsides
as well.

My main disappointment with all this story is that the GNUstep port
never really work(s|ed).  It's worked just enough that Jan managed a few
times to fix some problems on the macosx port by reproducing them and
fixing them in GNUstep.


        Stefan

Re: Nextstep build uses iso-latin by default. WHY?

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:

> There's no point in Emacs coming with two different macosx ports, so
> incorporating Yamamoto Mitsuharu's version into Emacs would mean dropping
> the current "ns port" and that comes with various downsides as well.

A major point in favor of switching to Mitsuharu's version would be that he
actively maintains it, whereas our only active NS port maintainer recently
stepped down.

I wouldn't even mind there being two build flavors, if each were actively
maintained; but barring that, I'd prefer something that comes with a
maintainer.

It used to be the case in 24.x that the NS port was unusable in some ways
(poor sub-process communication made working with GDB untenable, for example),
and as such, Mac Port was something of a necessity. But the 25.x code seems to
have resolved that, so now I don't notice as much difference between the two.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Nextstep build uses iso-latin by default. WHY?

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 14 Apr 2016 08:35:19 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

> So Emacs switched to that "NS" port.  More or less around that same
> time, Yamamoto Mitsuharu started to work on the "old" code and adapt
> it to the newer version of the old API.  And here we are.

Could you expand what it means by "the newer version of the old API"
more concretely?  Compling the NS port with the recent SDK gives
warnings about the use of deprecated API, but the Mac port does not.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Nextstep build uses iso-latin by default. WHY?

[Stefan Monnier]

>> So Emacs switched to that "NS" port.  More or less around that same
>> time, Yamamoto Mitsuharu started to work on the "old" code and adapt
>> it to the newer version of the old API.  And here we are.
> Could you expand what it means by "the newer version of the old API"
> more concretely?

IIUC your port derives from the carbon port.  I don't have a good grasp
of the various APIs involved, but my understanding is that the carbon
port was using an API which was being deprecated and you replaced some
parts of it (or maybe all of it, for all I know) to use a newer API
which was the "moral successor" of the old API.  That's what I meant by
"newer version of the old API".

> Compling the NS port with the recent SDK gives warnings about the use
> of deprecated API, but the Mac port does not.

I didn't mean to imply that the ns port uses a more
recent/uptodate/modern API than your port.  Just that your port uses
a more recent API than the carbon port.

Regarding those warnings: does that mean that the whole "NS" API used
by the NS port is being deprecated, or just that a few of its functions
are being deprecated, but the Emacs code hasn't yet been updated
correspondingly (for lack of manpower, or to maintain compatibility with
older macosx versions, or with GNUstep)?


        Stefan

Re: Nextstep build uses iso-latin by default. WHY?

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

>
> Regarding those warnings: does that mean that the whole "NS" API used
> by the NS port is being deprecated, or just that a few of its functions
> are being deprecated, but the Emacs code hasn't yet been updated
> correspondingly (for lack of manpower, or to maintain compatibility with
> older macosx versions, or with GNUstep)?
>

The Cocoa API used by the NS port is the preferred API for writing OS X
applications. The warnings are related to individual functions, I presume.

Unfortunately, I haven't spotted those warnings myself since I apparently
haven't been using the latest version of the development tools.

    -- Anders

[-- Attachment #2: Type: text/html, Size: 957 bytes --]

Re: Nextstep build uses iso-latin by default. WHY?

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 14 Apr 2016 19:26:16 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>>> So Emacs switched to that "NS" port.  More or less around that
>>> same time, Yamamoto Mitsuharu started to work on the "old" code
>>> and adapt it to the newer version of the old API.  And here we
>>> are.
>> Could you expand what it means by "the newer version of the old
>> API" more concretely?

> IIUC your port derives from the carbon port.  I don't have a good
> grasp of the various APIs involved, but my understanding is that the
> carbon port was using an API which was being deprecated and you
> replaced some parts of it (or maybe all of it, for all I know) to
> use a newer API which was the "moral successor" of the old API.
> That's what I meant by "newer version of the old API".

Though the transition to (the predecessor of) the Mac port, almost all
uses of the deprecated parts of Carbon APIs are replaced with Cocoa
AppKit (mostly for GUI) and C APIs such as Core Foundation, Core Text,
Core Graphics, Image I/O frameworks.  Serious OSX/iOS(and tvOS?)
developers would never agree on calling these C APIs "the newer
version of the old API".  Would you call cairo as the newer version of
the old Xlib drawing API?

It is true that the Mac port uses some functions in the Carbon
framework, but only for fine control over low-level stuffs such as
Carbon Events and Apple Events, and they are not deprecated.

>> Compling the NS port with the recent SDK gives warnings about the
>> use of deprecated API, but the Mac port does not.

> I didn't mean to imply that the ns port uses a more
> recent/uptodate/modern API than your port.  Just that your port uses
> a more recent API than the carbon port.

I was concerned that your previous message might give a wrong
impression that the Mac port is using a (newer version, but) old API.
Some seem even think it uses Carbon instead of Cocoa for GUI, though
you can no longer build Carbon GUI apps with recent SDKs.

In reality, besides some eye-candy features such as emoji, 2x images,
or Core Animations, it's been adopting several unnoticable ones such
as Automatic Reference Counting, Objective-C generics, and non-main
thread drawing via Grand Central Dispatch behind the scenes.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Nextstep build uses iso-latin by default. WHY?

[Angelo Graziosi]

Il 11/03/2016 21:49, Eli Zaretskii ha scritto:
>
> If you want to override your entire locale with UTF-8, do this:
>
>    (set-locale-environment "utf-8")
>
This seems to work fine.


Thanks,
Angelo.