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 15:54:41 +0200 Message-ID: <83zhpwz1i6.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> <83d0ms1to4.fsf@gnu.org> 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="38916"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Alp Aker Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 15 15:30:22 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 1h4nqn-0009zo-Fa for ged-emacs-devel@m.gmane.org; Fri, 15 Mar 2019 15:30:21 +0100 Original-Received: from localhost ([127.0.0.1]:56223 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h4nqm-0007ir-7Q for ged-emacs-devel@m.gmane.org; Fri, 15 Mar 2019 10:30:20 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h4nSi-000389-Si for emacs-devel@gnu.org; Fri, 15 Mar 2019 10:05:32 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40815) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h4nIb-000222-1h; Fri, 15 Mar 2019 09:55:01 -0400 Original-Received: from [176.228.60.248] (port=4084 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h4nIa-0000B3-1Z; Fri, 15 Mar 2019 09:55:00 -0400 In-reply-to: (message from Alp Aker on Fri, 15 Mar 2019 09:00:59 -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:234157 Archived-At: > From: Alp Aker > Date: Fri, 15 Mar 2019 09:00:59 -0400 > > > 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. > > I believe a simpler implementation is possible:  Where Ergus's > implementation uses a char glyph, it could also use a line-height image > glyph. How do you produce a line-height tall image glyph? Maybe I'm missing something, but I think we can only display image glyphs whose height is fixed and determined by the image, or by its slice whose dimensions are determined by a suitable display property, i.e. computed in advance of redisplay. But in any case, if such an image with dynamically computed height can be produced reasonably easily by the display engine itself, what you propose is a trivial extension of the code presented here: we just need to replace the character glyph by an image glyph. > the implementation for graphical and > text frames would be the same except for the choice of glyph. No, the implementation for the text-mode frame will always need to be (slightly) different , because it doesn't support images and it implements the stretch glyph as a series of space-character glyphs. > > . 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. > > If we use an image glyph on each line, the customizations would apply > only to the construction of that XPM image Maybe I'm again missing something, but how can a Lisp program (i.e. user customizations) produce an XPM image of unlimited height? If the height is fixed, the image will be unable to produce vertical lines taller than its height, in order to support tall lines. Btw, I don't think we can assume universal XPM support: Emacs can support platforms that only provide monochrome bitmapped images, no XPM. E.g., if I remove or rename the XPM DLL, Emacs on Windows still shows the tool-bar icons, albeit ugly monochrome versions of them. > It's straightforward to define XPM bitmaps in code, so this would > allow even more flexibility than using font characters. I'm sure users will find customizing a character much easier than customizing an image. In any case, I wouldn't give up on allowing a character, even if we do support images, because there's no reason to restrict users to images. For example, a suitable selection of a character could produce identical displays on GUI and TTY frames, something that an image could never do. > > . 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. > > Unless I'm mistaken, the method I'm describing would allow the same > optimizations Yes, but I was replying to a completely different idea. What you propose is just a trivial extension of the code posted here, so all of the effort that went into that will still be valid, and most of my message is not really relevant.