From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning Date: Wed, 30 Nov 2022 18:23:39 +0200 Message-ID: <83iliwjtro.fsf@gnu.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21636"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, bjorn.bidar@thaodan.de, emacs-devel@gnu.org To: xenodasein@tutanota.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 30 17:25:12 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 1p0PtX-0005RB-O8 for ged-emacs-devel@m.gmane-mx.org; Wed, 30 Nov 2022 17:25:11 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p0Pse-0000zm-8Y; Wed, 30 Nov 2022 11:24:16 -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 1p0Psb-0000zc-5L for emacs-devel@gnu.org; Wed, 30 Nov 2022 11:24:13 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0PsZ-0006ZF-Ul; Wed, 30 Nov 2022 11:24:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=8xU4QWhRd0zqO5WJtqxc9HFKJX4zL9920oEyNfZ3Tag=; b=YVojtE5M4fe7+W6HGQ8R RIDzBPRu0Mg+F4jcRnMjuIq8/Cx0NUt7Ow4NN6hTC3GpkJ4Hada50Pfo5vBt9TxGTdma+97KEwTdo jorbRBGyHKkMWS+hCQqXcIbNfAXaGyVOqmSLj4l1ULO4LoeAlQg8n6CMyIr2J3ihurhODiVgTUUxO JacjTeAUfHMob9OdRg8Qbt8BruBEXm5i7I3UDIlLIyBmS+tPSQ1ziShQHj8IXS7V/hzSRbbE62P+P vpKOmhPVkiUkHXoEiucp0ds+rKnSezfdJBOViEB9W55UgGqht5awphtK3YWP1szk1huZxGk/WpOjR 7hu6WqiWZbm+Yw==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0PsZ-00015C-8f; Wed, 30 Nov 2022 11:24:11 -0500 In-Reply-To: (emacs-devel@gnu.org) 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:300772 Archived-At: > Date: Wed, 30 Nov 2022 12:51:07 +0100 (CET) > Cc: Björn Bidar , emacs-devel@gnu.org > From: xenodasein--- via "Emacs development discussions." > > You must keep in mind that big contributions like this must have a > foundation if there will be any hope of them even happening.  For > example I can almost imagine the answers if I suggested separating > some translation units instead of using #ifdef's every five lines, > so I won't don't worry.  Or take as example the recent discussion on > macros.  It won't make much of a difference indeed if some line is > a function or a macro, issue is the resistance to even simple changes > like that; it implies the impossibility of something not as simple. > You can say no it doesn't, regardless that is the picture it paints. > I remember Eli requesting not to change the location of some function > on the grounds that it will now be harder to find where it is. 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 will 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). For a recent example, see treesit.c. So this rant of your is completely unclear to me.