From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.devel Subject: Re: Mac OS Sierra tab feature breaks C-x 5 2 Date: Wed, 12 Jul 2017 23:20:57 +0200 Message-ID: References: <191BFCA3-3C5B-4A75-8985-A958E638ADCE@gmail.com> <20170706174204.GA19121@breton.holly.idiocy.org> <20170706221637.GA19607@breton.holly.idiocy.org> <20170710195220.GA21900@breton.holly.idiocy.org> <20170712182321.GA23391@breton.holly.idiocy.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c04ee445e998a055425644e" X-Trace: blaine.gmane.org 1499894469 30197 195.159.176.226 (12 Jul 2017 21:21:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 12 Jul 2017 21:21:09 +0000 (UTC) Cc: Paul Michael Reilly , Jean-Christophe Helary , Emacs-Devel devel To: Alan Third Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 12 23:21:05 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dVP4C-0007bM-UO for ged-emacs-devel@m.gmane.org; Wed, 12 Jul 2017 23:21:05 +0200 Original-Received: from localhost ([::1]:56046 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVP4I-00082Q-Ie for ged-emacs-devel@m.gmane.org; Wed, 12 Jul 2017 17:21:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53633) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVP4A-00081L-Ts for emacs-devel@gnu.org; Wed, 12 Jul 2017 17:21:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dVP49-0002nX-MP for emacs-devel@gnu.org; Wed, 12 Jul 2017 17:21:02 -0400 Original-Received: from mail-ua0-x22f.google.com ([2607:f8b0:400c:c08::22f]:33126) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dVP49-0002kX-Go for emacs-devel@gnu.org; Wed, 12 Jul 2017 17:21:01 -0400 Original-Received: by mail-ua0-x22f.google.com with SMTP id g13so3659275uaj.0 for ; Wed, 12 Jul 2017 14:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4FfxhBCX5HnFMiPEIU2P49EyQXc+eqTkTwOwIBpeN7E=; b=kyyekwLWmz9Fcl5kFdxGKLI1trURQt9jx8pD6Z8syHGiJBmDtzvVZexDFvoD/04Dlw 76Nd9+uj/9o8PKOMQCeeYkuzlDq/EM01OPsIHGpRhzJwh/L12/voawC6/x8VY8lbd7CY Tf1XqajVliUfBsvRJxL4zGBidXobhvT97f7HMbn2uWdwvJLfOOQFeh8VxZH/tE6xvCJw umdqPJtXlBs/Uw/ABHA32fthKXNbuhuaNNHNLtECjk4bnBHXVKTgX7NfO0xXWXFF4L3P w/r+0HkaCe9d5McdzVE+FvU1G3qU/romDViZAl3Rd1NCtvjXPynwmShNPZU6ukXKpqLW YJ1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4FfxhBCX5HnFMiPEIU2P49EyQXc+eqTkTwOwIBpeN7E=; b=kJHSB3ZDbt6UY/ZasktyDvE8nr8qqvelwcFf4PUgveVrWDNydZiIDtSMKmUGw0M2LF vld4tcljSok9Ck1yrvVJATozZ0IguhU26tKj3GEiq1i6MRRBYXl8QlpGlwxybttOp926 yV8HDa3wtpu9M813ETSuXKMUyZVA+dTjX5S/sEJ6thGS/Ggi9kpleWlh/MddRbzCid67 2vL4RitxF0fZ1Ot75EgbxyVDFeDVg7xgf/u3uD8kGIP522eZbEVujWPMTC33FguS9k8q xi45gwRkIjrMcZdspCU719RfbBUum/+vh3XC7KkvPywGmSwM7XgZdEZICFjaE9LeEN1t IcNA== X-Gm-Message-State: AIVw111NQl7saUNVYPkb7R/YzDKq/k5gceVCGiLxRUIT67jhKayNeFAX EqSPh5O22x1LAihjZAWZxAcGj5DlVw== X-Received: by 10.159.32.3 with SMTP id 3mr380824uam.67.1499894457995; Wed, 12 Jul 2017 14:20:57 -0700 (PDT) Original-Received: by 10.31.180.65 with HTTP; Wed, 12 Jul 2017 14:20:57 -0700 (PDT) In-Reply-To: <20170712182321.GA23391@breton.holly.idiocy.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400c:c08::22f X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:216560 Archived-At: --94eb2c04ee445e998a055425644e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Yeah, I=E2=80=99m not sure about this either. It strikes me as a bit susp= ect, > but I don=E2=80=99t know that the alternatives are going to be any better= . > > We could disable the warning: > > #pragma clang diagnostic push > #pragma clang diagnostic ignored "-Wobjc-method-access" > if ([win respondsToSelector: @selector(setTabbingMode:)]) > [win setTabbingMode: NSWindowTabbingModeDisallowed]; > #pragma clang diagnostic pop > > which is, I think, the right thing to do, but that=E2=80=99s quite messy > looking, and I suspect we=E2=80=99ll have to do the same for the gcc warn= ing. > I don=E2=80=99t know if we=E2=80=99d then have to do some #ifdef stuff to= separate the > clang and gcc stuff. This has the potential to get REALLY messy. > It's possible to encapsulate pragmas into preprocessor macros using the _Pragma construct. In fact, config.h contains similar stuff, c.f. _GL_INLINE_HEADER_BEGIN and _GL_INLINE_HEADER_END. Another possibility is to cast `win` to `id`, which I=E2=80=99d guess would > look like: > > [(id)win setTabbingMode: NSWindowTabbingModeDisallowed]; > I still get the same warning, so this is not a solution. By the way, while digging around I came across a lot of stuff saying > `@selector(setTabbingMode)` should give a warning if `setTabbingMode` > doesn=E2=80=99t exist. Are you seeing one? > No, no warning is issued about that. I believe that there are a number of #ifdef:s that could be rewritten in this way, so we need something ergonomically. (If we could get rid of all such ifdef:s there would not be a need for OS-version specific binaries.) Given the options, I would say that a solution along the lines of _GL_INLINE_HEADER_BEGIN would be best. The pros are: * All the messy bits can be located in one place, and it can easily be updated to match future compiler versions. (Should some compiler start to warn about, say, `@selector(setTabbingMode)`, that too could be incorporated in the macros.) * There is a natural location to place documentation and to describe the situation * In the code that use the macros, there is a signal to the reader that something special is going on * It's possible to write formal tests, ensuring the macros work as intended= . Unlike _GL_INLINE_HEADER_BEGIN, we should not use a leading underscore, as such identifiers are reserved for the compiler itself. Maybe NS_SILENCE_MISSING_METHOD_WARNING_BEGIN and -_END? The end result would look like: NS_SILENCE_MISSING_METHOD_WARNING_BEGIN if ([win respondsToSelector: @selector(setTabbingMode:)]) [win setTabbingMode: NSWindowTabbingModeDisallowed]; NS_SILENCE_MISSING_METHOD_WARNING_END -- Anders --94eb2c04ee445e998a055425644e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=
Yeah, I=E2=80=99m not sur= e about this either. It strikes me as a bit suspect,
but I don=E2=80=99t know that the alternatives are going to be any better.<= br>
We could disable the warning:

=C2=A0 =C2=A0 #pragma clang diagnostic push
=C2=A0 =C2=A0 #pragma clang diagnostic ignored "-Wobjc-method-access&q= uot;
=C2=A0 =C2=A0 =C2=A0 if ([win respondsToSelector: @selector(setTabbingMode:= )])
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [win setTabbingMode: NSWindowTabbingModeDisallo= wed];
=C2=A0 =C2=A0 #pragma clang diagnostic pop

which is, I think, the right thing to do, but that=E2=80=99s quite messy looking, and I suspect we=E2=80=99ll have to do the same for the gcc warnin= g.
I don=E2=80=99t know if we=E2=80=99d then have to do some #ifdef stuff to s= eparate the
clang and gcc stuff. This has the potential to get REALLY messy.

It's possible to encapsulate pragmas into pre= processor macros using the _Pragma construct. In fact, config.h contains si= milar stuff, c.f. _GL_INLINE_HEADER_BEGIN=C2=A0and _GL_INLINE_HEADER_END.


Another possibility is to cast `win` to `id`, which I=E2=80=99d guess would=
look like:

=C2=A0 =C2=A0 [(id)win setTabbingMode: NSWindowTabbingModeDisallowed];=

I still get the same warning, so this = is not a solution.


By the way, while digging around I came across= a lot of stuff saying
`@selector(setTabbingMode)` should give a warning if `setTabbingMode`
doesn=E2=80=99t exist. Are you seeing one?

<= div>No, no warning is issued about that.

I be= lieve that there are a number of #ifdef:s that could be rewritten in this w= ay, so we need something ergonomically. (If we could get rid of all such if= def:s there would not be a need for OS-version specific binaries.)


Given the options, I would say that a= solution along the lines of _GL_INLINE_HEADER_BEGIN would be best. The pro= s are:

* All the messy bits can be located in one = place, and it can easily be updated to match future compiler versions. (Sho= uld some compiler start to warn about, say, `@selector(setTabbingMode)`, th= at too could be incorporated in the macros.)
* There is a nat= ural location to place documentation and to describe the situation
* In the code that use the macros, there is a signal to the read= er that something special is going on
* It's possible t= o write formal tests, ensuring the macros work as intended.

<= /div>
Unlike _GL_INLINE_HEADER_BEGIN, we should not use a leading under= score, as such identifiers are reserved for the compiler itself. Maybe NS_S= ILENCE_MISSING_METHOD_WARNING_BEGIN and -_END? The end result would look li= ke:

=C2=A0 =C2=A0 =C2=A0 NS_SILENCE_MISSING_METHOD= _WARNING_BEGIN
=C2=A0 =C2=A0 =C2=A0 if ([win respondsToSelector: = @selector(setTabbingMode:)])
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [win setTabbing= Mode: NSWindowTabbingModeDisallowed];
=C2=A0 =C2=A0 =C2=A0 NS_SILEN= CE_MISSING_METHOD_WARNING_END

=C2=A0 =C2=A0 --= Anders

--94eb2c04ee445e998a055425644e--