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: Wed, 24 Nov 2021 19:05:32 +0200 Message-ID: <83fsrl8owz.fsf@gnu.org> References: <87bl2hyzca.fsf@gnus.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> <83pmqsp0m7.fsf@gnu.org> <87k0gzyy8k.fsf@gnus.org> <835ysjoupv.fsf@gnu.org> <8735nnyob1.fsf@gnus.org> <83y25fneeh.fsf@gnu.org> <87pmqrx7rh.fsf@gnus.org> <83tug3ndaj.fsf@gnu.org> <874k81vmlf.fsf@gnus.org> <83sfvl8wjw.fsf@gnu.org> <87o869y0v2.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11943"; 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 Wed Nov 24 18:10:55 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 1mpvnL-0002tG-6e for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Nov 2021 18:10:55 +0100 Original-Received: from localhost ([::1]:40618 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mpvnK-0006Jx-0P for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Nov 2021 12:10:54 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:53380) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mpviD-0007SX-CC for emacs-devel@gnu.org; Wed, 24 Nov 2021 12:05:37 -0500 Original-Received: from [2001:470:142:3::e] (port=38148 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 1mpviC-0007Z4-CL; Wed, 24 Nov 2021 12:05:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=YE2uk5MTuCQ80j6vGCSAtVHi+NkrkSRM0fZk2uTS8lA=; b=S5xLZv9tH2X9 kqBlL2X5k8csCn/JoraoJSVsc2VTexo97AWUgUQGDJ7F1E4zYwGEVaC7St9sl6A7qCdd2mGisi8PS SvgFsnKDLP27+8YzNIu87ZSsEJRBAUlrLyFCxg6wPXbBqkgO3P9TIT5bQGE1q3LTqTcdnSgDeRUUs zAynniZGIQCTsHuskxcTkt1FkcR62eNBtZXXhcgzhaz6enpTqgRbXKfPCD0O+4AMVL8ut9eU3kPhJ BGr25ljeNw+E6oG2LPl22DyWaTOFTedM5RB2EX+Z7zMaG1XREENAbXNk292f2oIGvY5Y2GpcOxqxM k0HV5Cag0N36pQd7kBzZ2A==; Original-Received: from [87.69.77.57] (port=2113 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 1mpvi9-000839-If; Wed, 24 Nov 2021 12:05:36 -0500 In-Reply-To: <87o869y0v2.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 24 Nov 2021 17:28:17 +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:280021 Archived-At: > From: Lars Ingebrigtsen > Cc: dgutov@yandex.ru, stefankangas@gmail.com, emacs-devel@gnu.org > Date: Wed, 24 Nov 2021 17:28:17 +0100 > > >> 1) Should the stretch have been inserted "before the foo ended", i.e., > >> with that face extending to the end of the range? > > > > You are saying that the stretch doesn't use the same face as the > > characters "covered" by this property? If so, why not use the same > > face ID? If that's not what you are saying, then what are you saying? > > I'm asking, I'm not saying. OK, but then I don't think I see a problem. The display code will keep using the same face until something changes it. So if you don't touch it->face_id in your code, the stretch will be displayed in the same face as the text covered by this property. Is that what you wanted to ask? Does that answer your question? > >> 2) To identify a range, we need an identity > > > > You are saying "a range", here and in the documentation you installed, > > but you never explain what that means in this context. Can you > > explain what you mean by that, and why do you need to identify that > > range? > > "A group of consecutive characters". And it needs to be identified, > because that's the thing that has a minimum width. You mean, the text "covered" by this property? Btw, why don't you just record in the iterator the position where it ends when you first see the property, instead of trying to identify that by comparing property values? The iterator structure has a member called 'position' for this purpose. > > Then, if it _is_ a string, I don't understand the test for bufpos == 0 > > vs bufpos > BEGV in the case of a buffer, and I also don't understand > > the reverse condition of the property equality. Can you explain what > > is going on here and why? > > This doesn't deal with strings at all. It's display_string (i.e., the > mode line) or a buffer. Adding support for strings, too, might be nice. Sorry, I don't understand: the functions which call display_min_width are general-purpose display code, they are used for displaying both buffer text and Lisp strings. In fact, displaying the mode line already means that strings are supported, because the mode line is constructed from Lisp strings, not from buffer text. In any case, can you please explain what the test bufpos == 0 tries to test? I'd like to understand the logic there.