From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alp Aker Newsgroups: gmane.emacs.devel Subject: Re: Fill column indicator functionality Date: Fri, 15 Mar 2019 09:00:59 -0400 Message-ID: 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; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="213581"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 15 14:11: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.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h4mcl-000tRB-Ej for ged-emacs-devel@m.gmane.org; Fri, 15 Mar 2019 14:11:47 +0100 Original-Received: from localhost ([127.0.0.1]:54773 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h4mck-0002gf-AT for ged-emacs-devel@m.gmane.org; Fri, 15 Mar 2019 09:11:46 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51010) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h4mTn-00033D-3n for emacs-devel@gnu.org; Fri, 15 Mar 2019 09:02:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h4mTk-0000cD-Rx for emacs-devel@gnu.org; Fri, 15 Mar 2019 09:02:30 -0400 Original-Received: from mail-qt1-x82a.google.com ([2607:f8b0:4864:20::82a]:33278) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h4mTk-0000WC-FW for emacs-devel@gnu.org; Fri, 15 Mar 2019 09:02:28 -0400 Original-Received: by mail-qt1-x82a.google.com with SMTP id k14so4198647qtb.0 for ; Fri, 15 Mar 2019 06:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=HmaYpMVjDjHCcXeYR30XuB+u8aGWoEE0lIqNFgQQgcQ=; b=Bh6W180O8lFHbm8ARpU77hTAiZoTqBzH1VADpqHdYywT2cKMdAsKHAsMElQWYEewXy PH6byrpPFTmttQ2Bm00DqUsUivsv3dFKbZL5Xy/FoWO5swCSTkThWSB5dAGQSK4d9fIY ohagtPYYX6sV1rcwFL8E03AmO+zxZUH/lwOXHblTqG1khr4tG6zWAgfYROvmrrJopfi0 HNFkBTxWEoGx26tIkVZEAtUWV9bb7FWUryr0Y9ZyBzo3H41hGqixvsZfxklGOBiMl20Y vOoMIyvriALxjUAoOVLMz8PzQNvfhh9b3ivMdATQpMZzOZgD/0w5CZ9m9Q/GsFDYtD2c KcDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=HmaYpMVjDjHCcXeYR30XuB+u8aGWoEE0lIqNFgQQgcQ=; b=mMhnkZinmFV0b4XDIOXA6PxNGixpBlDSZ76PfEl3D6RKlN/nKv4m3xKn2xTD3VDF45 kh5k6CuMwhKI3A65toJheuIwwRJ9LqZ8Y/nu0GtuIG2oGfDGvt5bpHBe4D2YNDwUaVG1 yjeUCObrjvCo6FIFkP3LrQoYb5Au1AdiWR9U8dvRPP2ft0yV8vb9//xZ1dJdPi2I5t0p q5ojqJ9t6rnInvOTAgZBdc0E0+bxQgSdSvQkFxjKBy3xfwUAlphw7YvLBMb72GdH9MEp XLzxlaz4ypiq/kyjuZTxIQqN/S1MdlMdHaARGoCzNMnMEDT9e91kPThAD6N/OO94DJzp vRCQ== X-Gm-Message-State: APjAAAVUY7+9EmJDD7eADTOadlzzNJG/sUMMaqFcfP7MiF+53zdLgQ4q xOq+qA0BiXKEVLP0FPe2mZucwnKO X-Google-Smtp-Source: APXvYqwBV++WqXD/wmtzXv+zmnGlJGVMKfLsm7sVJtCbpVocqBebfqyOHw4pYZEUIx9oCtEBsYeCPg== X-Received: by 2002:a0c:d648:: with SMTP id e8mr2447393qvj.10.1552654937253; Fri, 15 Mar 2019 06:02:17 -0700 (PDT) Original-Received: from [10.0.1.6] (cpe-98-14-239-39.nyc.res.rr.com. [98.14.239.39]) by smtp.gmail.com with ESMTPSA id z140sm1045105qka.81.2019.03.15.06.02.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Mar 2019 06:02:16 -0700 (PDT) In-Reply-To: <83d0ms1to4.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::82a 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:234154 Archived-At: > 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.  That is, instead of a single window-length element, analogous to the window divider, the indicator would consist of many independently displayed line segments, one per line.  If we use an image type like XPM that's universally supported, this would allow a single implementation shared by all window systems, and the implementation for graphical and text frames would be the same except for the choice of glyph.  (This is the method used by the unfortunate fill-column-indicator package whose deficiencies have necessitated the current work.) > . 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; the display routine that positions the image segments doesn't need to know how to construct the image.  Users could even supply arbitrary images to use, so long as they're of the appropriate height (or they could just be cropped to the correct height if necessary).  It's straightforward to define XPM bitmaps in code, so this would allow even more flexibility than using font characters. > . 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 that Ergus's current implementation does (since it would, as far as display is concerned, be the same except for the choice of glyph to use).