From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Platform independent graphical display for Emacs Date: Sat, 25 Dec 2021 13:23:01 +0200 Message-ID: <9c04ef31-96e0-1874-7385-633435a28b5f@yandex.ru> References: <87ilvgwfor.fsf@telefonica.net> <83a6grx1o9.fsf@gnu.org> <834k6zwvi1.fsf@gnu.org> <87h7azilmu.fsf@yahoo.com> <87sfujh4a2.fsf@yahoo.com> <877dbuhm6j.fsf@yahoo.com> <87tueyg5gc.fsf@yahoo.com> <83y24asbh4.fsf@gnu.org> <83tuexqh7w.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26552"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Cc: luangruo@yahoo.com, stefankangas@gmail.com, drew.adams@oracle.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 25 12:25:03 2021 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 1n15Ad-0006iX-2b for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Dec 2021 12:25:03 +0100 Original-Received: from localhost ([::1]:46914 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n15Aa-0003Rk-VA for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Dec 2021 06:25:00 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:47888) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n159u-0002ll-9Z for emacs-devel@gnu.org; Sat, 25 Dec 2021 06:24:18 -0500 Original-Received: from [2a00:1450:4864:20::42a] (port=46029 helo=mail-wr1-x42a.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n159s-0000Kp-4G; Sat, 25 Dec 2021 06:24:18 -0500 Original-Received: by mail-wr1-x42a.google.com with SMTP id v7so21908375wrv.12; Sat, 25 Dec 2021 03:24:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=V0YsA88/BrzQ0Dc1dl7XxthS+NTz4L67LO8Djh2xf4Q=; b=bwL3eDQSEL1pzI6hNZqozbIV7FQy4US7BThdU7GdxiJoJLx4Iaw58+QBaB8sZSWAo7 jg9wGhsX/j91/IEiCzAHzqksvIVGCSXB7HKwU+R840L4JA8VWCtSjQlMum/ZdGElKGDY ok6q3nMDn8SHMuIY1INb9ekZYviWz4s/pbuWDUGI71iYNrxGD8DUXl5ttgyIaNjJsTfH tHuFzfu3ooJN56GbNxGgXD2eOSjGiG3purGdRX/gLLmA1Wm9N3Hqb7Y/7lhyR4HSuzum Ayyimu3ahTKwqvzeVCKsTqR44RHyVYcGW0bW14Bw0GeKMxrp0Img/NgzX7rax8/Nwnwn U/jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=V0YsA88/BrzQ0Dc1dl7XxthS+NTz4L67LO8Djh2xf4Q=; b=ySepEeawl0ln8WxfYiPrpfxYxFUHKK1jZe8mYm5DnfvUW2b52oGgHyHHIzjICM7d0V FKNL6Lun+oFQjX5kyAfR8CxI2MAFsOrdLrPNVCwsl0XrvavccSnXpd9G876OlMBjdI0Y QldvFfjN1uRLr5ZQ6KuZpRkMYYQDfytB02aqY2KvZyer+IX9QPcLWF5D3aH6iOM9tV+O sH8su6I8MF0g/HhXpokdsPTGd8V05vtPQej6ewYjLh/NjoQe64PMDKPGTJeM6xSM6knW BFA7WNleT5DebvpmYrGKisozz+hIuhb2rIGpuANo6DABt0zmu05Rv5KGUaB+SC57fYOG x3/Q== X-Gm-Message-State: AOAM533BwfOEAyvf06fRkGE4j1hAnv6QglnuvGjfeMnIbfHiT37WFL8W eBUW+kTAIGDyDpG7MmJpbaNlymAgFaA= X-Google-Smtp-Source: ABdhPJwjKzr5jSZHa6JqyW6JPSkLg5N2EnBoRXafWilYIp6op7nOWnAZLNNYvxlOBxj834i4nHxglA== X-Received: by 2002:adf:d1ef:: with SMTP id g15mr7128585wrd.47.1640431454022; Sat, 25 Dec 2021 03:24:14 -0800 (PST) Original-Received: from [10.112.109.103] ([185.209.196.172]) by smtp.googlemail.com with ESMTPSA id z22sm10170197wmp.40.2021.12.25.03.24.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Dec 2021 03:24:13 -0800 (PST) In-Reply-To: <83tuexqh7w.fsf@gnu.org> Content-Language: en-US X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::42a (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=raaahh@gmail.com; helo=mail-wr1-x42a.google.com X-Spam_score_int: -8 X-Spam_score: -0.9 X-Spam_bar: / X-Spam_report: (-0.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.196, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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" Xref: news.gmane.io gmane.emacs.devel:283195 Archived-At: On 25.12.2021 10:25, Eli Zaretskii wrote: >> On 24.12.2021 10:33, Eli Zaretskii wrote: >>>> That said, all of this would obviously be a lot of work and until and >>>> unless someone starts such work this is all rather academic. >>> Not only that, I'd hesitate to accept such a contribution, because its >>> long-term maintenance would most probably be a constant burden, >> >> How it that different from a BeOS port, or a PGTK port, or etc? Where >> the general policy has been (I think?) that we accept such contributions >> as long as there interest from the author in maintaining it, and some >> probable interest the users. > > The suggestion, as I understood it, was to drop all the other toolkits > and leave only this proposed one. That was its main "selling point". > If we decide to have just one toolkit, then having that unmaintained > would be a serious problem for the future of Emacs. Before we could do that, we'd need to have this port functional first, and the problem with dropping all others would be in reaching a consensus across emacs-devel (at least) that the new one is better than the others. And it maintained/maintainable, of course. That should pretty much guarantee that it will be maintained. But the odds of reaching that point are pretty slim, of course, given that we don't lack in different viewpoints here. >> I would hate to discourage someone from taking the initiative a trying >> to create a better "no-toolkit" port which supports font scaling, for >> example. > > The suggestion was not to improve the no-toolkit configuration and > leave all the supported toolkits in place. The suggestion was to drop > all the others. > > I have nothing in principle against improving the no-toolkit > configuration. I do think that _adding_ another no-toolkit > configuration would be undesirable, because it would make the > proverbial "spaghetti of Emacs code" even harder to understand and > maintain. (I don't think such a suggestion is on the table, but since > you seem to say I misunderstood the suggestion, perhaps I've > misunderstood that as well.) I would at least hope that switching to another no-toolkit configuration (and removing the current one soon after) is on the table. After getting enough consensus, naturally. It might become feasible to remove a number of them, though. If my hunch is right that people have been holding on to no-toolkit, or Motif, or Lucid, because they each have some pet bug which is present on newer toolkit ports, but not on their chosen one. >> Worst-case scenario, we'd just have to drop that "port", wouldn't we? > > We cannot just "drop" the only toolkit we have. > >> Like some people said previously, Emacs feels similar in spirit to >> another popular FLOSS project: Blender. Community of professionals, >> keyboard-driven interface, power and customizability. >> >> Blender never used an existing GUI toolkit. And I think it looks pretty >> good (even though I hope it has grown a light-bg theme by now): >> >> https://docs.blender.org/manual/en/latest/_images/editors_preferences_section_interface.png >> https://b3d.interplanety.org/wp-content/upload_content/2016/09/01-4.jpg >> >> Of course, the Blender community is much larger and better funded, but >> OTOH the number of different UI elements we'd need to support is much >> smaller as well. > > I'm not saying it's impossible, I'm just saying we don't have such > talent on board. Maybe Blender does, which would be understandable, > given the focus of the project. Our experience is that GUI experts in > our ranks are very rare and far in-between, and there are no reasons > to believe this will change. Having a port like that developed could get us +1 such expect. >> And we could tap into some existing community talent by having a lot of >> the UI logic implemented in Lisp. Similarly to how a number of recent >> web browser projects have their UIs implemented with JS+HTML. > > I think this hope is misguided, because Emacs Lisp was not designed to > be a UI programming language, it was designed as a text-processing > language. So it would need significant extensions to get closer to > your dream. There is not much in JS that would make it a UI language. Other Lisps compile to it without problems. Other editors had been written in lisp as well (such a LightTable -- in ClojureScript). Perhaps better concurrency story would make it a tad easier (e.g. better stdlib for working with threads, or a counterpart to Web Workers), but IIRC when LightTable was developed, JavaScript had neither.