From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Platform independent graphical display for Emacs Date: Sat, 25 Dec 2021 15:08:17 +0100 Message-ID: <87bl14srou.fsf@telefonica.net> References: <87ilvgwfor.fsf@telefonica.net> <87h7azilmu.fsf@yahoo.com> <87sfujh4a2.fsf@yahoo.com> <877dbuhm6j.fsf@yahoo.com> <87tueyg5gc.fsf@yahoo.com> <83y24asbh4.fsf@gnu.org> <83tuexqh7w.fsf@gnu.org> <9c04ef31-96e0-1874-7385-633435a28b5f@yandex.ru> <83lf08rk27.fsf@gnu.org> <87o854swp2.fsf@telefonica.net> <87lf0898b7.fsf@yahoo.com> <87k0fssufl.fsf@telefonica.net> <83bl14rfbd.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3214"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) To: emacs-devel@gnu.org Cancel-Lock: sha1:OnXOun8JR809I24g1SnOCy0QoyQ= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 25 15:09:54 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 1n17kA-0000hZ-DO for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Dec 2021 15:09:54 +0100 Original-Received: from localhost ([::1]:43390 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n17k8-0003Uj-CE for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Dec 2021 09:09:52 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:47800) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n17iq-0002e6-9m for emacs-devel@gnu.org; Sat, 25 Dec 2021 09:08:32 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]:48142) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n17io-0000Rz-Ek for emacs-devel@gnu.org; Sat, 25 Dec 2021 09:08:32 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1n17im-0009gy-9h for emacs-devel@gnu.org; Sat, 25 Dec 2021 15:08:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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:283227 Archived-At: Eli Zaretskii writes: >> A closer look at Skia makes me think that it is not a good candidate for >> Emacs, for several reasons. But Skia was just an example, we (or, better >> said, the OP) can examine what other options are available. > > Yes, examples are being thrown here and there without any relevance, > just to make a point in a dispute, it seems. It doesn't help to have > a useful discussion. It also happens that people make a big fuss over minor details instead of dicussing the meat of the matter. I don't think the outcome of this "dispute" depends on an example of what it could be used. BTW, on the Skia-Emacs inadequacy issue, I would not be sure about what part to blame the most. >> > Please explain in detail what the new graphical capabilities are, and >> > how using a different graphics library will help. >> >> We could turn the frame into a canvas. Take >> display-fill-column-indicator for instance. Instead of faking a line >> with characters, we could simply draw the line as a graphic object. > > If you think this kind of enhancement could materialize just by > changing the *term backends of the Emacs display, you don't have a > clear idea about the relevant architecture aspects of that. It is > nigh impossible to do something like that without the knowledge of > xdisp.c and dispnew.c. I'm telling you that as the single person > around here who has any kind of practical experience in implementing > something like that: the TTY menus do something very similar, and that > code gets away by the skin of its teeth, and would be probably simply > impossible with GUI display. > > Throwing around such ideas without any real knowledge is simply > irresponsible. Someone might believe you and spend some non-trivial > time trying to implement that. You are overthinking something that's actually very simple: locating the x coordinate of the n-th column and drawing a vertical line from top to bottom of the window on each redisplay. Any sane graphics system can do that simple, trivial thing. If it is difficult to do it in Emacs, that only demonstrates how limited the display engine is on its capabilities. If I were the hacker implementing the proposal, I would start with the data structures that hold what needs to be shown and with a surface: then, do the rendering. I know it is not as straightfordward as just throwing a bunch of text on a textbox, but what I've seen on the sources and your claims makes me think that any attempt at reusing the legacy code (the one that actually paints the frame's contents) would be a waste of time. You are talking as if the complexity, quirks and limitations of Emacs' display engine were something good, something to be preserved, when it is quite the contrary, ever more when so few people understands it. By your description, the current display engine is a big liability and any proposal that could end with replacing it with something comprehensible by mere mortals should be welcome.