From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: :extend face attribute at EOB without end-of-line char Date: Tue, 15 Oct 2019 10:10:21 +0200 Message-ID: References: <20191014163219.dieg73u73onqsgyt@Ergus> <83ftjvi4yp.fsf@gnu.org> <83a7a3hzxw.fsf@gnu.org> <838spnhz64.fsf@gnu.org> <83zhi2h6up.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000413c440594ee8636" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="223810"; mail-complaints-to="usenet@blaine.gmane.org" Cc: spacibba@aol.com, Emacs developers To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 15 10:11:18 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.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iKHvH-000w4W-M1 for ged-emacs-devel@m.gmane.org; Tue, 15 Oct 2019 10:11:15 +0200 Original-Received: from localhost ([::1]:36836 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iKHvG-0000Ra-CY for ged-emacs-devel@m.gmane.org; Tue, 15 Oct 2019 04:11:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54227) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iKHv5-0000Gi-GL for emacs-devel@gnu.org; Tue, 15 Oct 2019 04:11:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iKHv4-0003Az-6k for emacs-devel@gnu.org; Tue, 15 Oct 2019 04:11:03 -0400 Original-Received: from mail-qk1-x736.google.com ([2607:f8b0:4864:20::736]:46940) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iKHv2-0003Aa-Eu; Tue, 15 Oct 2019 04:11:00 -0400 Original-Received: by mail-qk1-x736.google.com with SMTP id 201so18339143qkd.13; Tue, 15 Oct 2019 01:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OleKTueufrd8IYGQkUVwgt0fXehPe/0TNF/oucZD+RE=; b=glXeq7ySPpMcViYppHhMOKYoDYAJM73NNcMR+GBouPhiOTA9bsAPWyQ+IavHRuwjns AVKkXUOAWP9xqoJaMu5aRCnI+4HJbW74rXxr9522mq651pu49zDZcO+dQ4hsGMZONpIA wHEiSChrfKOY7BcmJQrHJHSH1SMmPlovRqYulIF4MrfK+MNZkQ/U6YvlO5S9d+aEz0Xs bRZwo2FtpLMrF3MgBF9lFSCQIFZL+dA4hovpRxsMjCGwXHLq9OyqMUYhaVtiS76uXnoR p0AzjxXnz1pMpIGA8AEJdPP944Keo7ex9fRMDYRsRSDvt+QWKbfldNzQP9r7TODMgN4y ayPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OleKTueufrd8IYGQkUVwgt0fXehPe/0TNF/oucZD+RE=; b=eWJ9YUq55Bh2Zed96h/jscH78K5bynXJ7/ORRSY7NPhjIcTMkuqH577PCHIiFmTf0j 3PEskaeRlbWMPRHg9pOdY7dqMdjWCnqHOCeaSXRJ0P5yh3Le0J16pOcJTZttBhydsizA xK3AIe60ffAQ4jbezeyJe6ajdOCvIU5d/D/GkNN3z1I3VpPagmFzmLt53qVG18UXe3kZ Qgx7+PDmFD1b3iup0ehvEgm6DPgsVeKoRO61awwzH+CQPQ+zLl4Xb7TzgymC9DXT3KLh VpH74+7fsZAfM21+vwAYscQwOF3qn0iMgRJF/ztJdjrU7hYP2Uxz2iD3ZAZ18tFVO7H5 lcjQ== X-Gm-Message-State: APjAAAWqprlut2uhwpSa0qpLPSTTVuGbFcQt5r/GpFeCSU+3F9IMk6I3 9cUMbmsFNjZyYngTOyPZydFrfR/wThdZtCVhpkq8zg== X-Google-Smtp-Source: APXvYqxlH6Y33b0V/l4Ho6xCTHldH4Ty699ReDURcFqRpyjLT9GjC2RaSpP53PZDau2ZeQQYTGZFeRlDJ0RLBcXQKOg= X-Received: by 2002:ae9:c307:: with SMTP id n7mr9036029qkg.185.1571127059101; Tue, 15 Oct 2019 01:10:59 -0700 (PDT) In-Reply-To: <83zhi2h6up.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::736 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:241037 Archived-At: --000000000000413c440594ee8636 Content-Type: text/plain; charset="UTF-8" On Tue, Oct 15, 2019 at 8:15 AM Eli Zaretskii wrote: > OK, but still, we'd need a rationale. I'm not sure what rationale would satisfy you. In my mind, the idea of extending a face up to the margin of the window seems quite decoupled from whether that line has a newline at the end or not. It's purely visual. If I'm using a face that extends in all lines, for example, I find weird that it does or does not extend in the last one depending of a newline. (Again: I agree that's how it is defined now, I'm not questioning that.) > The use case is quite obscure, IMO, Yes. I happen to use bs-show, and hl-line-mode in bs-show, so it's not obscure for me, obviously. (Years ago I defined the format of my bs lines to fill entirely the window with spaces to avoid this ugly "ragged" effect on the last one.) But whether it will be useful in other cases will depend on how frequent is to have buffers with a non-newline last line, I suppose. No idea. > and the implementation won't be trivial (I had my share of bugs > from fiddling with display code past ZV, and you just had a taste of > that with the ticks feature). Yes. It was quite "entertaining", so to speak. --000000000000413c440594ee8636 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Oct 15, 2019 at 8:15 AM Eli Zaretskii <eliz@gnu.org> wrote:
> OK, but still, we'd need a rationale.=C2=A0
<= br>
I'm not sure what rationale would satisfy you. In my mind= , the idea of extending a face up to the margin of the window seems quite d= ecoupled from whether that line has a newline at the end or not. It's p= urely visual. If I'm using a face that extends in all lines, for exampl= e, I find weird that it does or does not extend in the last one depending o= f a newline. (Again: I agree that's how it is defined now, I'm not = questioning that.)

> The use case is quite obsc= ure, IMO,

Yes. I happen to use bs-show, and hl-lin= e-mode in bs-show, so it's not obscure for me, obviously. (Years ago I = defined the format of my bs lines to fill entirely the window with spaces t= o avoid this ugly "ragged" effect on the last one.) But whether i= t will be useful in other cases will depend on how frequent is to have buff= ers with a non-newline last line, I suppose. No idea.

<= div>> and the implementation won't be trivial (I had my share of bug= s
> from fiddling with display code past ZV, and you just = had a taste of
> that with the ticks feature).

Yes. It was quite "entertaining", so to speak.

<= /div>
--000000000000413c440594ee8636--