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 10:19:04 -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> <83zhpwz1i6.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="92499"; 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 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 15 15:41:38 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 1h4o1i-000Ny1-5s for ged-emacs-devel@m.gmane.org; Fri, 15 Mar 2019 15:41:38 +0100 Original-Received: from localhost ([127.0.0.1]:56418 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h4o1h-0007yr-0Y for ged-emacs-devel@m.gmane.org; Fri, 15 Mar 2019 10:41:37 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:45336) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h4nhC-0007wZ-Oh for emacs-devel@gnu.org; Fri, 15 Mar 2019 10:20:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h4nhA-0006Lu-CG for emacs-devel@gnu.org; Fri, 15 Mar 2019 10:20:25 -0400 Original-Received: from mail-qt1-x82d.google.com ([2607:f8b0:4864:20::82d]:40353) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h4nh9-0006LU-Jg; Fri, 15 Mar 2019 10:20:24 -0400 Original-Received: by mail-qt1-x82d.google.com with SMTP id f11so10209777qti.7; Fri, 15 Mar 2019 07:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=EK5nkae+tIHC2afRCtaNXmvTprOJgp04LqQU/sqtcRU=; b=BBysx/wlwqcVCdlhQBgGo/gQutIH8FU4DNEaJ3IiBejiJ+pdVN493jEjrL7mvmKU+c lVd6of01r749FyisQi1ISFNkgKgfsGJhrxIkeJQ30ALjTfP68R9H3oq5EFKrlpxxKWGH 3R2DTuHRKz3qDpNC2p0IONekU/+OSxNsU0PTYrEnvNsiewmvTiscOruInNW2fcXK+Hx2 ti+3WvjGKmsWos1yjpoaLTaQAEhrIeW0KMHKdgiNxIM5DKhgk2768W6iJtxNlVeJe1Q5 +LhSRcelZG/tidIaIYNBMl8AdjXK3SmZv4o+Bq+qa1mKXos7MekCKALARl/REYe1hGw9 woLQ== 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:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=EK5nkae+tIHC2afRCtaNXmvTprOJgp04LqQU/sqtcRU=; b=dWjIEXkoij7Qk/9LkdrgtjnvrINfP9GvOOgeaghVTLX91j4ATlbN+5flS5ty3p9VM9 Gntpnmw6vZOoeNuBTUp4iMJOk+OmZ/E6K63oCyeUzufGaEYe0oKjvlxv/U708Mp4OfLk zxxnK9LKhWUAUWHWsLCzEWAQTPlyDGSOD55SfS8b1E0dGQfjGGhUVXMe7M7fTW3py+Pt 4iuU2fXPkNOVvrgBtsTdEtet2ZTaPEKJkhmrNAGD9SCT7jXtcnTGEtSNBcy9dIku1ozP 7OXBF5kckh+4mNLSrXzNrTjPHpb7gTg3ctSP+hxW8oDWQYJwxgBj+uTJLqQ564oiQrID W5pg== X-Gm-Message-State: APjAAAWaNUbAPY5ZIfTuUzXn+vjzqQlamvM2V2VDG9baB7WpWB69o20v 4xwDXseVAS58MimLIGnFuHzQi2AU X-Google-Smtp-Source: APXvYqxvsQF1KL8PBhjlBIVYsdjIwVqmRDIxLnMjDqWAloRVOoXYs0QouCFkB+AjHVQnHMApRRrbdw== X-Received: by 2002:ac8:22d4:: with SMTP id g20mr3004995qta.50.1552659622618; Fri, 15 Mar 2019 07:20:22 -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 a73sm1181036qkb.66.2019.03.15.07.20.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Mar 2019 07:20:21 -0700 (PDT) In-Reply-To: <83zhpwz1i6.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::82d 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:234161 Archived-At: > 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. I did not have a dynamically sized images in mind, only fixed-height images.  They offer a way of achieving the graphical effect that some people in this thread have requested that would involve, as you point out, only a trivial extension of what Ergus has already done. Would lack of support for variable line heights be an issue?  I can only offer my experience here as the author of fill-column-indicator.  Among the many issues that package has, lack of support for variable line heights in a window hasn't been one of them.  It just isn't something users have requested. > 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. A choice between image and character was what I had in mind.  (If a buffer is displayed on both GUI and TTY frames, you can even use both at the same time, which is what fci-mode does.) I wouldn't expect end users to create their own images.  Again, I can only offer my own experience, but the only customization requests I've received have been for (a) color, (b) thickness, and (c) dashed vs. solid.  Those can be offered as simple customization options.  Arbitrary user defined images are possible on this scheme, but wouldn't be the basic mode of customization.