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: Tick Reduction Date: Mon, 22 Nov 2021 19:21:36 +0200 Message-ID: <83pmqsp0m7.fsf@gnu.org> References: <87bl2hyzca.fsf@gnus.org> <834k88woaj.fsf@gnu.org> <878rxkv980.fsf@gnus.org> <87sfvpmtl8.fsf@gnus.org> <83pmqtqvj5.fsf@gnu.org> <87bl2dmnfa.fsf@gnus.org> <83mtlxquh7.fsf@gnu.org> <877dd1mlsd.fsf@gnus.org> <83k0h1qss5.fsf@gnu.org> <8735npmkm5.fsf@gnus.org> <83h7c5qpag.fsf@gnu.org> <87czmtl2uv.fsf@gnus.org> <83fsrpqog1.fsf@gnu.org> <87wnl1jnfa.fsf@gnus.org> <83czmtqnl7.fsf@gnu.org> <87h7c5jmbg.fsf@gnus.org> <838rxhqmqv.fsf@gnu.org> <878rxhjlot.fsf@gnus.org> <874k85jlmq.fsf@gnus.org> <87v90khaa8.fsf@gnus.org> <83zgpwp7v2.fsf@gnu.org> <87tug4fdn7.fsf@gnus.org> 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="5453"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, stefankangas@gmail.com, dgutov@yandex.ru To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 22 18:22:32 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 1mpD1U-0001CP-KK for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Nov 2021 18:22:32 +0100 Original-Received: from localhost ([::1]:49776 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mpD1T-0005zW-Ca for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Nov 2021 12:22:31 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:34162) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mpD0T-0005IP-Ff for emacs-devel@gnu.org; Mon, 22 Nov 2021 12:21:29 -0500 Original-Received: from [2001:470:142:3::e] (port=42544 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mpD0S-000645-Ox; Mon, 22 Nov 2021 12:21:28 -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=o0qvK2xfdq9gYF6ySGrdcvnPomfyETHWxA3yyGuCz78=; b=P9H2N9JFl48uEuK8Mv1x pH3/S8ez1C/mfAxfyt9NQHnAs/iL8zzKOTROI0XlfvgzMNd2tk+E20ZR8igX2OrVl7g4fFEb1AzRJ Pin35vpinUPhwXrn0TiROVjdRZJROrz+vV2F2+pl3of2Kp8+XU7wQeyXPZAtTFvzbV+LvmqWz3lXE FKBbbQ3Y/C9rscjutk2r3hL5MeC6aNiA8gnp+WbGSKx4eFzYxR35RmVZFo5g8783cEoLZPSGzSUc8 rgCUgBjB2DrbPU/FOSFa2diYaYcKO8rthaEYJn5KfMnzSDvuHFp/meTlJgD462u1rp62WeF3F47b5 DD/1OmvsXIuFdA==; Original-Received: from [87.69.77.57] (port=1809 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 1mpD0S-00022g-Eb; Mon, 22 Nov 2021 12:21:28 -0500 In-Reply-To: <87tug4fdn7.fsf@gnus.org> (message from Lars Ingebrigtsen on Mon, 22 Nov 2021 15:50:20 +0100) 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:279922 Archived-At: > From: Lars Ingebrigtsen > Cc: dgutov@yandex.ru, stefankangas@gmail.com, emacs-devel@gnu.org > Date: Mon, 22 Nov 2021 15:50:20 +0100 > > I think it's generally useful. > > > If it's the former, we need to talk about the design, because the way > > you wrote the code, it violates several protocols of the display > > engine, and that needs to be fixed first (and will probably also fix > > the problems you have with the cursor). > > Sure, talk away. 😀 This is my first attempt at implementing something > in the display engine (as opposed to tweaking bits), so as much advice > as possible will be helpful. For starters, here's a thought: why not make this feature a variant of the 'display' property, rather than inventing a new kind of property? We already have similar variants of 'display': (height HEIGHT) and (raise FACTOR), and this one sounds similar enough. The advantage of doing that is that you will then have much of the infrastructure and the framework into which to drop your additional code: the handle_display_prop function, the handle_single_display_spec function, and the code there which shows how this stuff is done. You will also have display_prop_end function, which will help you know where the text with this property ends (so you know where to produce the stretch glyph). In short: the processing of 'display' properties is already well integrated into the overall design of the display engine, so adding there one more variety should be relatively easy. And one other important thing: never call append_FOO_glyph directly. Instead, call produce_FOO_glyph. That's because produce_FOO_glyph already takes care of many things that you otherwise will have to do manually (and make mistakes). For example, this: > +static enum prop_handled > +handle_min_width_prop (struct it *it) > +{ > + if (STRINGP (it->string) || !it->glyph_row) > + return HANDLED_NORMALLY; is unacceptable: when it->glyph_row is NULL, it usually means we are emulating redisplay without producing glyphs, but the data in 'it' still needs to be maintained as if we did, because otherwise stuff like vertical-motion and its callers will stop working. You will see in produce_stretch_glyph that it does get this case correctly.