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: Fri, 15 Mar 2019 09:30:19 +0200 Message-ID: <83d0ms1to4.fsf@gnu.org> References: <20190309132207.w2ho3j6p5on6fyzw@Ergus> <838sxo87gc.fsf@gnu.org> <20190311104814.kp2nv6arv47hcykz@Ergus> <83y35l4ee0.fsf@gnu.org> <20190312152928.73o4b5fk4paz7wm5@Ergus> <834l883w15.fsf@gnu.org> <20190312192017.fkfd4h5gsbdue5q3@Ergus> <83imwm3fxf.fsf@gnu.org> <20190313200225.dpqrw7xthkj47fqw@Ergus> <83bm2e35a1.fsf@gnu.org> <20190314030224.l5zseslncw3xc5ox@Ergus> <835zsm2c2s.fsf@gnu.org> <303612d8-e691-f753-84c9-f462d88262b6@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="11775"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 15 08:30:59 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 1h4hIx-0002to-Eh for ged-emacs-devel@m.gmane.org; Fri, 15 Mar 2019 08:30:59 +0100 Original-Received: from localhost ([127.0.0.1]:51157 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h4hIw-00044z-FT for ged-emacs-devel@m.gmane.org; Fri, 15 Mar 2019 03:30:58 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:33728) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h4hIj-00042a-LQ for emacs-devel@gnu.org; Fri, 15 Mar 2019 03:30:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h4hIf-0006mk-FW; Fri, 15 Mar 2019 03:30:41 -0400 Original-Received: from [176.228.60.248] (port=3699 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h4hIb-0001IV-UQ; Fri, 15 Mar 2019 03:30:38 -0400 In-reply-to: <303612d8-e691-f753-84c9-f462d88262b6@gmail.com> (message from =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel on Thu, 14 Mar 2019 14:58:07 -0400) 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:234152 Archived-At: > From: Clément Pit-Claudel > Date: Thu, 14 Mar 2019 14:58:07 -0400 > > Sorry for jumping in late without having followed the whole discussion. Here's a naive question: is there any reason to use an actual glyph from a face to draw that line, rather than just a continuous line? That's a good question. Indeed, it would be possible to implement this with a single thin line being drawn, but I think such an implementation would have several disadvantages: . It will need to be implemented separately for each window-system (X, w32, NS), and for TTY frames. By contrast, the implementation discussed here is in a single place, is independent of the display kind, and is very simple and localized. . Using a glyph makes it easier to support some fancy customizations. For example, suppose that someone would like to have the indicator be a dotted line, or to have a more prominent appearance -- all they'd need to do is find a suitable character, such as ▍ or ▓, and be done. With the continuous line implementation, we'd need to implement the corresponding textures in the code, before it could be supported. . Using the continuous line would cause complications wrt redisplay optimizations. Redisplay of text is highly optimized in Emacs, and frequently needs to update only a small portion of the window. The problem is what to do about the indicator line when only some portions are redrawn. A naïve idea of redrawing the entire line would cause it to flicker on each keypress. (The divider avoids this problem because it is drawn where no characters can ever overwrite it, so it only needs to be redrawn when the window dimensions change, something that is rare and causes a complete redrawing of the entire window anyway.) We could instead arrange for redrawing only portions of the line that overlap the glyphs which are actually redrawn, but then we'd need to write code for detecting those portions. By contrast, using the glyph-based implementation we get this for free, because the redisplay optimizations already know how to avoid redrawing glyphs that didn't change. We also get for free support for R2L text, something that would again require separate code with the continuous line idea. The continuous line idea does have one advantage: it seamlessly supports lines of variable height. But that use case is rare, and I think we will be able to support them with the glyph-based implementation as well. Does this answer your question?