From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Fill column indicator functionality Date: Sat, 09 Mar 2019 16:10:11 +0200 Message-ID: <838sxo87gc.fsf@gnu.org> References: <20190206222524.zic6idgs2vkglg7h@Ergus> <8736p0nznz.fsf@tcd.ie> <837eebsmaj.fsf@gnu.org> <87sgwvco1l.fsf@Ergus.i-did-not-set--mail-host-address--so-tickle-me> <83r2cel3qf.fsf@gnu.org> <20190211165636.ch5x4wb2ibdt2dzy@Ergus> <83ef8el03u.fsf@gnu.org> <20190308185744.a4vnfoab5wdvqyny@Ergus> <83y35p871q.fsf@gnu.org> <20190309132207.w2ho3j6p5on6fyzw@Ergus> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="54714"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 09 15:10:45 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.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h2cgW-000E7t-5R for ged-emacs-devel@m.gmane.org; Sat, 09 Mar 2019 15:10:44 +0100 Original-Received: from localhost ([127.0.0.1]:59539 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h2cgU-0005pU-BX for ged-emacs-devel@m.gmane.org; Sat, 09 Mar 2019 09:10:42 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:47710) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h2cgE-0005kt-JW for emacs-devel@gnu.org; Sat, 09 Mar 2019 09:10:28 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58749) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h2cgE-0004Uy-5e; Sat, 09 Mar 2019 09:10:26 -0500 Original-Received: from [176.228.60.248] (port=1754 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h2cgD-00018D-Df; Sat, 09 Mar 2019 09:10:25 -0500 In-reply-to: <20190309132207.w2ho3j6p5on6fyzw@Ergus> (message from Ergus on Sat, 9 Mar 2019 14:22:09 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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:233967 Archived-At: > Date: Sat, 9 Mar 2019 14:22:09 +0100 > From: Ergus > Cc: emacs-devel@gnu.org > > >You are on the right track. But I'd suggest to do this inside the > >function extend_face_to_end_of_line. It is called near that label, > >but you will see that it's called in several more places; I expect at > >least some of them to need the same changes. > > > Hi Eli, I just finished a working version (pretty simple as a proof of > concept). That works in terminal mode. But in graphical mode we should > look for another approach because extend_face_to_end_of_line returns in: > > if (FRAME_WINDOW_P (f) > && MATRIX_ROW_DISPLAYS_TEXT_P (it->glyph_row) > && face->box == FACE_NO_BOX > && FACE_COLOR_TO_PIXEL (face->background, f) == FRAME_BACKGROUND_PIXEL (f) > #ifdef HAVE_WINDOW_SYSTEM > && !face->stipple > #endif > && !it->glyph_row->reversed_p) > return; > > So it don't write until the line end. Yes, you need to add one more condition to that 'if', so that it doesn't return when this feature is in effect. > In graphical mode maybe it is better to do this change writing directly > a vertical line in the windows' frame background. I don't think we can do this in Emacs, the background is just a color for us. > That way it will be maybe more efficient because we only do it > once. If it were possible, it still could not be done once, because every redisplay would have to redraw it. > But I don't know if this is possible-recommended. It's not possible with what we have in Emacs today. > BTW: Is it possible to generate a single wider glyph instead of doing a > loop?. Yes, of course: you produce a single stretch glyph of a suitable width. Look at what the code does in the "row->reversed_p" case. > >Which data structures? there are quite a few of them, so please be > >more specific. > > > glyph <-> it: why this looks so complex? For 2 main reasons: . the 'it' structure needs to keep track of several state variables, which affect more than one glyph, and it needs to do that without relying on the glyphs, because sometimes these functions are called with it->glyph_row set to NULL (when we need to simulate display without displaying anything, see move_it_to . the 'it' structure instance is discarded once the glyphs are produced, so if we need to record information about the glyphs, we need to keep it with the glyphs themselves > Because "it" has too many properties I can't understand their > functionalities and sometimes I think I could reinvent the wheel. The comments in dispextern.h should help. If they are not enough, we can add more comments, but you need to point out the missing information.