From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: xenodasein--- via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning Date: Wed, 30 Nov 2022 17:56:39 +0100 (CET) Message-ID: References: <87cz99l4td.fsf@thaodan.de> <87v8n1w7cf.fsf@yahoo.com> <87wn7gc53k.fsf@thaodan.de> <87r0xnx4fs.fsf@yahoo.com> <87edtncvss.fsf@thaodan.de> <87ilizwbkw.fsf@yahoo.com> <87cz94vjgl.fsf@yahoo.com-NI70zP3----9> <83iliwjtro.fsf@gnu.org> Reply-To: xenodasein@tutanota.de Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27314"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, bjorn.bidar@thaodan.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 30 17:57:17 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p0QOa-0006oF-LY for ged-emacs-devel@m.gmane-mx.org; Wed, 30 Nov 2022 17:57:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p0QO5-0002Tw-AT; Wed, 30 Nov 2022 11:56:45 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0QO3-0002Sa-Lt for emacs-devel@gnu.org; Wed, 30 Nov 2022 11:56:43 -0500 Original-Received: from w4.tutanota.de ([81.3.6.165]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0QO2-0003vQ-2Z; Wed, 30 Nov 2022 11:56:43 -0500 Original-Received: from tutadb.w10.tutanota.de (unknown [192.168.1.10]) by w4.tutanota.de (Postfix) with ESMTP id DF39910602F9; Wed, 30 Nov 2022 16:56:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1669827399; s=s1; d=tutanota.de; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=hFmj4slTEPqYrSmv4ZscooWWA8mMtJSsR66bwCd+2/w=; b=g0TyhG8d7EaUFJz+LPkUpx9JQjY7DAs0ozOaMHZM15IRddPDSpe+Y3jaPmqZG6m4 id3ZnNdaFgnKNcjWMPRJKGpcOZrqiRCek+5qBSJa1JYaoU2pMqPmQaVPGgs+x6fapP0 lZGLHd/aWIxvHOw5Gki+bSR5m7cWI0oireT6W+CxpAqQ2vV40JpKXL3ktaeeti3o830 273N0dSf1cba2+l8mTjlnd7QFCm9J1ADwCf7FnGLGxfURs2XwM+CpM3qM9V8uMEirn+ E5D+HfqXsYvkNWIZLQk/aDyMxTrZcrbUkkXg3qpTKnLgpCV4l53cphKq9Y7W0jw3CTi y7C7D8hHhg== In-Reply-To: <83iliwjtro.fsf@gnu.org> Received-SPF: pass client-ip=81.3.6.165; envelope-from=xenodasein@tutanota.de; helo=w4.tutanota.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:300775 Archived-At: Nov 30, 2022, 16:23 by eliz@gnu.org: > I don't understand how separating some translation units or > changing/replacing macros are related to development of any significant > feature in Emacs. Any such significant new feature will have tons of new > code which you can factor as you see fit; if you do a clean job, no one w= ill > argue with how you define functions and macros. And in any such new code= , I > don't see how it matters whether, say, MATRIX_ROW_BOTTOM_Y is a macro or = a > function: you just use it and that's it. > > IOW, adding important new features to Emacs doesn't need to change how we > use our infrastructure and whether something is a macro or not. They are > completely orthogonal issues. Our low-level functions and macros don't > prevent anyone from adding features, and in case a function or a macro > really needs to be refactored or accept additional arguments to enable a = new > feature, no one will object (again, provided that you do a clean job). F= or > a recent example, see treesit.c. > > So this rant of your is completely unclear to me. > I also repeatedly say adding completely new things like treesitter is encouraged, because someone(tm) will maintain them supposedly. Problem is tackling what's already in there, which happens almost never compared the former.=C2=A0 Overhauling display is going to require that, I'd love to see how it would go without touching the infrastructure or without the friction I've seen with simple mention of it before even changing code.=C2=A0 If someone attempts that it would make it simpler to believe you, because I am discouraged to take the first step.