From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alex Gramiak Newsgroups: gmane.emacs.devel Subject: Re: Removing the usage of X structures (or their names) in independent code Date: Thu, 09 May 2019 10:26:44 -0600 Message-ID: <87woizd263.fsf@gmail.com> References: <875zqkdzfc.fsf@gmail.com> <83d0ksgo1h.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="55970"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 09 18:27:20 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hOlt9-000ETC-QR for ged-emacs-devel@m.gmane.org; Thu, 09 May 2019 18:27:19 +0200 Original-Received: from localhost ([127.0.0.1]:57568 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOlt8-0006b3-La for ged-emacs-devel@m.gmane.org; Thu, 09 May 2019 12:27:18 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38959) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOlsV-0006ZE-Re for emacs-devel@gnu.org; Thu, 09 May 2019 12:26:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hOlsU-00049z-RS for emacs-devel@gnu.org; Thu, 09 May 2019 12:26:39 -0400 Original-Received: from mail-pf1-x435.google.com ([2607:f8b0:4864:20::435]:43929) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hOlsU-00049F-LU; Thu, 09 May 2019 12:26:38 -0400 Original-Received: by mail-pf1-x435.google.com with SMTP id c6so1575553pfa.10; Thu, 09 May 2019 09:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=Wkk02zpt1PDQEGuxmvcnX/2/1CfXcZEpC4GjgmghojM=; b=LcpI4iA443u+BAwLQIKyXIi24HHPIRfKNbJfdAq3OyQ0txJI5FjrmnurIzQ7jyj1TY dEg9kPUFuQ3ZdnVjpQbxesiSxxblR/DAAkE+xH7dP+p/pMkwNitJcid0dmO+ASFJvT6h YGph6GDvwSm16EKDLm6yRJH1qVoVGwmPd95OG83B6y47NV0hRH9iJq2BCfi5uC+Ao33p XAMHX2B8dUsOAWGe6ccBlOh30LBLpAuQotPu2AgtiLII+yp42SkcQAg4KhmyOU9XTGc6 h0bJhGKOo8FlKaHYQ/hqmwc9gK+X3HEe0zdPUuMbPqfDPiHwDDfzIqrXFxZfxHqTiXyW lScg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=Wkk02zpt1PDQEGuxmvcnX/2/1CfXcZEpC4GjgmghojM=; b=iq0s74CmDiOlSzLg5kAewsbKvii0DR2SWS7x7d2Ap2XuEcSWYjUbgE+iC8yDj71tr2 6XRbMMZVOU25r9mznCXSM3gdrt65FYb4ZMTL3j0LAaqvCXTGwgTjURnunuqMzwROV794 sc4Rg3up6LuTgbNrjizaHkzN1km09um7enahl5gAljH6eXXTO87B0gREc0DYiFfZ1hBl DwHkCWuV+iqGmnw+pOsSRcOb/E+GG6vaZN2bMqgNau+XyndZLH7XN5g30FXvh1uh6vUk 3Bv8c5tOOKGo8M4CVBeFdEPpUjm0Zmxo0I/MmUcUaSl02/GdGVvmpLRcf2yPj8oLE3ag EkRw== X-Gm-Message-State: APjAAAU7hC8H8ysIPKvhX0Uvx2+OjrghTbUjIbbsx6HMDGm1pu/kUeoc or9k69CfHwv1er5RQRETC9IQkOaE X-Google-Smtp-Source: APXvYqxeJpQzS1krtAw6Bj/gP1Ps4tvjRa59jC+TnvW5xyIioin+NPMHg+wM89ZXjr7xflRuTxoWag== X-Received: by 2002:aa7:93ba:: with SMTP id x26mr6479754pff.238.1557419197153; Thu, 09 May 2019 09:26:37 -0700 (PDT) Original-Received: from lylat ([2604:3d09:e37f:1500:1a72:4878:e793:7302]) by smtp.gmail.com with ESMTPSA id b9sm3141279pgj.94.2019.05.09.09.26.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 09 May 2019 09:26:36 -0700 (PDT) In-Reply-To: <83d0ksgo1h.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 09 May 2019 09:06:02 +0300") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::435 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:236338 Archived-At: Eli Zaretskii writes: >> From: Alex Gramiak >> Date: Wed, 08 May 2019 22:28:23 -0600 >> >> Numerous internal procedures in Emacs that aren't tied to X expect and >> use structures with the same name as X structures: e.g., XColor, >> XGCValues, GC, XRectangle, XChar2b, Display, Pixmap, Cursor. >> >> This poses an issue when attempting to use a non-X backend to Emacs that >> conditionally uses X itself: name clashes occur between the structures >> intended for use in the independent Emacs code and the internal X >> structures. Workarounds using the preprocessor exist but are ugly and >> fragile. >> >> What would be the preferred way to fix this situation? Two options are >> to use typedefs for these structures like XImagePtr_or_DC, or to use >> unions. Everything else being equal, I would prefer the union approach. > > Why do you prefer a union? It uglifies the code and makes it harder > to read and understand. OTOH, having a backend-independent type (what > you call "typedef") is much cleaner. The union approach would be more future-proof (if the goal of multiple backends at once is realized), and I find it neater than having different types per backend. I would consider the union approach as having a "backend-independent type"; in the union approach, all backends of Emacs would have that union as the type, whereas in the typedef approach each backend pastes its own type into the generic parts of the code. The above goal is still far away, so it wouldn't be terrible to use typedefs in the interim. >> Alternatively, for structures like XColor, there could be new generic >> structures that all the backends share, but that would involve some >> overhead on the X side for conversion. > > If that new structure is defined as (for example) > > typedef XColor EColor; > > then there's no overhead at all: you could simply assign an EColor to > XColor or even use the former directly in APIs that want the latter. Right, I meant overhead in the case of defining a new structure rather than defining a new name for the structure. For example: struct EColor { uint16_t red; uint16_t blue; uint16_t green; uint16_t alpha; /* Who knows, maybe? */ unsigned long long pixel; }; Which would need to be converted to XColor on the X backend. > For more complex situations, see what we do with 'struct font' and > 'struct FOOfont' for font backend FOO. Could you point me to somewhere specific for this? I'm unsure to what you're referring. In any case, would you prefer using names like EColor, EPixmap, EGC, or Emacs_Color, Emacs_Pixmap, Emacs_GC?