From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.devel Subject: Re: Question about display engine Date: Sun, 1 Sep 2019 14:26:28 +0200 Message-ID: <20190901122628.aynhzwwpvqbgyydh@Ergus> References: <83lfvdd5f7.fsf@gnu.org> <83woexb3yu.fsf@gnu.org> <160dfd3f-60d4-8758-df65-2165c552f39e@gmx.at> <83zhjrakf9.fsf@gnu.org> <2aff0873-5d18-a4a0-eada-1ad0e632e753@gmx.at> <83mufr9gya.fsf@gnu.org> <03a80221-5222-9b8b-86a1-67cef18df463@gmx.at> <83zhjp937v.fsf@gnu.org> <8acd9fc1-e6ce-9a86-cfb6-e00a672c154a@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="50189"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: Eli Zaretskii , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 01 14:26:50 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i4OwT-000CwP-V3 for ged-emacs-devel@m.gmane.org; Sun, 01 Sep 2019 14:26:50 +0200 Original-Received: from localhost ([::1]:57232 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i4OwS-0005q0-AL for ged-emacs-devel@m.gmane.org; Sun, 01 Sep 2019 08:26:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53851) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i4OwL-0005po-Bb for emacs-devel@gnu.org; Sun, 01 Sep 2019 08:26:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i4OwJ-00071f-0k for emacs-devel@gnu.org; Sun, 01 Sep 2019 08:26:40 -0400 Original-Received: from sonic305-20.consmr.mail.ir2.yahoo.com ([77.238.177.82]:41886) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i4OwI-0006zq-6V for emacs-devel@gnu.org; Sun, 01 Sep 2019 08:26:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1567340796; bh=c4uLrCT3oFDCz0rt0WvFyLNKkM0wBB6II/hFtbaV97M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=t52hWlspXu+wJIZJoTViImUUY8r5NKYGRNSmLZhgzYy4QfpT3+FSIsw8ltcTs3I8Czxe1DTrBA7JyyIpDEH/mESRY55ZECfpuSp9SlFDVLYEMGigvHr0FtRe9HX0xrvf856dvY9OZQHLCEdJFxdD84FPzDS45O1uEyt1yYfG9cNqt+MEqsA+U43jy79fXNszxCwBkkZ4O2ZEbmRxvnJYdINiNhkmJeIkvEcoUNJcSUrbwk27KNh1qJrZ3+RfNZMFEoLosCC56KrRrwiIde0sMk5NJcW7hWCgnhYhZ6F0j9SvgIQaF/jcFYhTW2lD2bDx6Y0fi2OlfJ4M3J/mnCXL8w== X-YMail-OSG: D6l7trQVM1nmsbG0SsZRIKQfHSLU.gucZfzudaflo7qTKBNdCv08xxgt6Khy2SL fXiA0WLb5kezwD1atvuYBGLWv8Alo0qiuhFqRJ1VxcaelS87iIuq_zkCwgsAjDoSsSj7fv0yOIMq QAfF73mUAyb88D66H4JYgQGhP74bcU.J8vb8tfDgqesBauCUb3txNVwuCDEFnDk4WIpCgZ.HeQO3 OcFEaAlS5XkYOTuFCMlA76wSU6lsqyotRaqouY74np2k4sE2EQ3JWEHjOy2YuogPfHw9BrH0abep uln6yslMukzXKCBX2fYyaeDrUG6Z0Kugf9wvtTEHNwlV7Rw0Jk2GLoavRr9FNDlCXRcFLixcC6gK rpdVDQcCRkjcBStDZ4MWOQjjs_zboB_8YixFyW0vch6PEoUEj8jsDKT49iEVRH8Sr6bQgVuXls_a rB68gab4ulFH30w6MWdlM6W8wOpY3l2uXzRsUyo4ZvyG7.Gl_qajbavzfgWzbrXSsWBa9hdG88Mh OP92cDNSevDODicfUtbTrwOpt01JV7J8Khi.RKbUC.xRXj8fyWaZ6EXPICkonxtUQKd8vY81aroo bgTmnLUssI6K7tlhrdYuw.tfiNtes7cpQltjCZtw3OvyZx_w9B3kqCJF7oEmokVM9TPwKWSgvHNg UQh_zrw5m9DJRaVqESuF8oS5KEYwgwnKlZ2SbfCcokNCLkVHaNBKec2Nqo2bP5uiBPiiGrePX773 OMANaOwC9IjJrmdb7eqpsCj28eyvbiUSyrlMDVov_sj5UCB2cAxMFfMoOgXE8yzvtG1KXc1nbz5f _phpuwByycbcmPQChbROnaIYluhwSfW7SVE5eOgkUy Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ir2.yahoo.com with HTTP; Sun, 1 Sep 2019 12:26:36 +0000 Original-Received: by smtp414.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9be958ec108c29f2396010d9b4e440d9; Sun, 01 Sep 2019 12:26:35 +0000 (UTC) Content-Disposition: inline In-Reply-To: <8acd9fc1-e6ce-9a86-cfb6-e00a672c154a@gmx.at> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 77.238.177.82 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:239748 Archived-At: Hi Marting and Eli: I have been thinking about this a little bit more and it seems like we are trying to replicate a behavior that is already there. If we had an extra face pointer within the face struct initialized to null (or default face), and then when we merge and the extend attribute is set we initialize it to the current merged face and we transmit that pointer from merge to merge until we have a new face with :extend, so we merge then those two... I think when we reach the end of the line we will have there already all the information we need. Lets say we have a sequence of consecutive merges (a,b,c,d,e); but only b and d have :extend. At the end we will have in the merges: (a, a+b, a+b+c, a+b+c+d, a+b+c+d+e) but with this pointers in them: (nul, b, b, b + d, b + d) Which for me it seems to be what we expect to have right? Does it makes sense? On Sun, Sep 01, 2019 at 10:14:06AM +0200, martin rudalics wrote: >>> To put this into praxis, the face merger would maintain a shadow copy >>> of the background value. That shadow value would not get overwritten >>> when merging in the :background attribute of a face that does not have >>> the :extend attribute set. Eventually, we would wind up with two, >>> possibly distinct values of the background to realize - one for the >>> normal and the shadow value for the extended background. >> >> The face merger doesn't maintain any state, so I don't think this is >> easily done. > >The background would be stored in an extend_background slot of the >face vector (or maybe even a separate extend_vector) which would >contain the part of the state responsible for handling the background. > >>> Note: We could also try to find out whether there _is_ another stop >>> position before the next EOL after merging faces and, if there's none, >>> realize the extended face eagerly, but I'm not sure whether this idea >>> can be incorporated easily. >> >> Right. > >IIUC next_interval is newline agnostic. The 'auto-composition-mode' >check does look for a newline within the next 1000 characters (around >line 3761 of xdisp.c) so we maybe could use that. > >>> BTW: One problem with Ergus' proposal is that hacks like the one >>> proposed for Bug#15934 won't work any more. For that bug, we could >>> obviously set the :extend attribute of the respective highlight line >>> face but all instances in the wild using the same hack already would >>> be affected by our change. >> >> Yes, of course. > >So we should probably provide a :no-extend attribute, extend face >attributes by default and explicitly not extend some attributes like >underline and box. > >martin >