From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Ligatures Date: Tue, 19 May 2020 20:00:02 +0300 Message-ID: <83r1vf7td9.fsf@gnu.org> References: <20200517124125.000013a4@web.de> <97C7EAB7-10AB-4702-ABC8-EB6C1C50ABDB@gnu.org> <20200517165953.000044d2@web.de> <83lflqblp0.fsf@gnu.org> <83ftbybio3.fsf@gnu.org> <83zha69xs2.fsf@gnu.org> <83367x9qeq.fsf@gnu.org> <875zcs32fv.fsf@Otto.invalid> <83eerg80u6.fsf@gnu.org> <834ksc7za9.fsf@gnu.org> <83wo586inp.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="123040"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stromeko@nexgo.de, emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 19 19:00:54 2020 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 1jb5bo-000Vsd-Ge for ged-emacs-devel@m.gmane-mx.org; Tue, 19 May 2020 19:00:52 +0200 Original-Received: from localhost ([::1]:58768 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jb5bn-0005Dy-HR for ged-emacs-devel@m.gmane-mx.org; Tue, 19 May 2020 13:00:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60768) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jb5b6-0004K3-SM for emacs-devel@gnu.org; Tue, 19 May 2020 13:00:08 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:56098) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jb5b4-0000EU-FM; Tue, 19 May 2020 13:00:06 -0400 Original-Received: from [176.228.60.248] (port=2584 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jb5b2-0002ce-QH; Tue, 19 May 2020 13:00:05 -0400 In-Reply-To: (message from Pip Cet on Tue, 19 May 2020 16:16:53 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:250968 Archived-At: > From: Pip Cet > Date: Tue, 19 May 2020 16:16:53 +0000 > Cc: Stromeko@nexgo.de, emacs-devel@gnu.org > > Sorry, I genuinely don't understand what the problem is. There's no need to argue. There's a TODO item regarding ligature support, and I just updated it with the ideas from this discussion. You, or anyone else, are welcome to work on some or all of that. I think good ligature support in Emacs is long overdue; that is one of the reasons we added HarfBuzz support and are steadily moving towards making it the default font backend. Any advances in the direction of letting Emacs use advanced features of modern fonts are welcome. > draw_glyphs is called by draw_phys_cursor_glyph, so all we need is a > line or two of extra code in draw_phys_cursor_glyphs to set > row->clip to the rectangle surrounding the subglyph the cursor is > on. No further change of the display engine is required for that, is > it? Feel free to ignore me. I may be completely wrong about this. Please disregard what I said and just code away what you think is needed to implement this. > > And then there's the popular use case where nothing > > changes except the cursor position, in which case no text is redrawn > > at all. > > Except for the glyphs the cursor is on, right? Those are redrawn by > draw_phys_cursor_glyph, or am I missing something here? Basically, yes, draw_phys_cursor_glyph. But there are other functions related to that, and which ones need to be changed for this "partial" cursor drawing to work, I really don't know/remember, sorry. You need to read the code. > > We will need to merge faces, > > which is slower than the current simple but effective method, which > > completely sidesteps the issue. > > I believe performance concerns are an entirely different subject (put > briefly, my opinion is that we've painted ourselves into a corner by > micro-optimizing fast loops over an essentially inefficient basic > design). The current design is that faces are realized lazily and cached for subsequent use, because realizing a face is expensive. It makes no sense to realize a face each time we blink the cursor. No matter what you think about the current design, code which does unnecessary calculations is bad code. Gerd Moellmann, which designed and implemented the current display engine, isn't stupid or incompetent, quite the contrary.