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:50:24 +0200 Message-ID: References: <20191014163219.dieg73u73onqsgyt@Ergus> <83ftjvi4yp.fsf@gnu.org> <83a7a3hzxw.fsf@gnu.org> <838spnhz64.fsf@gnu.org> <83zhi2h6up.fsf@gnu.org> <83mue2h0rl.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000005dc7850594ef15d0" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="138296"; 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:52:45 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 1iKIZR-000ZnY-7S for ged-emacs-devel@m.gmane.org; Tue, 15 Oct 2019 10:52:45 +0200 Original-Received: from localhost ([::1]:37786 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iKIZP-0004Fb-Uk for ged-emacs-devel@m.gmane.org; Tue, 15 Oct 2019 04:52:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60860) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iKIXo-0002t3-NE for emacs-devel@gnu.org; Tue, 15 Oct 2019 04:51:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iKIXn-0003Sz-BO for emacs-devel@gnu.org; Tue, 15 Oct 2019 04:51:04 -0400 Original-Received: from mail-qk1-x72b.google.com ([2607:f8b0:4864:20::72b]:46134) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iKIXl-0003NW-8m; Tue, 15 Oct 2019 04:51:01 -0400 Original-Received: by mail-qk1-x72b.google.com with SMTP id 201so18418638qkd.13; Tue, 15 Oct 2019 01:51:01 -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=v+OOhFCPYFTcMhku3uxVlDvR1/h4sAI0Yw1byVxgqo0=; b=aYUUHPk0jCrGgXDApxl8Me5nZgu1s27o9tEvB/TrB/tlLSgqcw02M/1vSBzuTM2yY9 Tod/+Sbl8Pc4NCKnR84vDI73a6mrI9R07k+BIx2lJDZMTXCcmerN2nIPhktJv4jxCf5w oPxk8n5f5EwA91cvpWRHtFK80SlBqNWa1chcn7QM48H/or4IVlcSbP5eOdaYqqxwG1Bd 5Cj6ZH0cazLB6FQffyXR25mdsfWOp2KJ1KifRaJLZjnvNSrXYjqfJJce65HT6M21BwBr /GR7u7SHqoJvErBI5iI2ITI4ygvqUJ/2ezXHjejnpc/Wuqx8SOPgORZakJafskmuOUn3 BE0Q== 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=v+OOhFCPYFTcMhku3uxVlDvR1/h4sAI0Yw1byVxgqo0=; b=rtmjCdi4hXvA5cGkPQPtN76yZZBSpoBTwtigF9hnEqANWphibxFlD6E6wpCQEmpf/M pQoXYWxVRDkLmqyYSoqY7kkobUVd/ZxCwMAD8ibCtfEiQXtZLCRv4cVeOio3KGKee5np n84T7+h6gMYRxkqmvdjxIN/EkIq7/NaSyx9YQITV3T+NI6G4FQpFYJF2Tj6wnvu7Mqxo 812StG12ySLPlDQEoa1vSP3BVH2qJkHISqEo9Yk2fc0rGzJ16zFI1r9IHHNG3BrqVlg6 nqHsUKZMhY70PZOfxnTrB71jSlzgGL/HjML/tGgmVdzbPUNaneB0DeGoVQaQz4AJtSVn AQag== X-Gm-Message-State: APjAAAWHXGZjyNpr/Sbvq0PtgyJWJnfGrOGBsVafOARZYJc8+naLXyRz VpcAL9H9Aa9EEkdV+daK35nOOUgJJr2KlfftlbA49g== X-Google-Smtp-Source: APXvYqz/n823eIKGewLPAp+NIrtBtQUqSB3nnncaZ5f1AVeEh3N+tWaasQYujYBBF2VWfEAxSihH2qAOCeoIgVbkpZ8= X-Received: by 2002:ae9:c307:: with SMTP id n7mr9157199qkg.185.1571129460114; Tue, 15 Oct 2019 01:51:00 -0700 (PDT) In-Reply-To: <83mue2h0rl.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::72b 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:241039 Archived-At: --0000000000005dc7850594ef15d0 Content-Type: text/plain; charset="UTF-8" On Tue, Oct 15, 2019 at 10:27 AM Eli Zaretskii wrote: > Face extension is only a factor when it ends on the next line, > i.e. "covers" the newline that ends the line. When there's no newline > at EOB, the face ends with the last character on the line, so IMO it > makes no sense to extend it, because what would such an extension > indicate? When there's a newline, extending the face indicates that > the newline (which is otherwise invisible) is "covered" by the face. I understand, but again, that's an explanation of how it works. For me, face extension is useful as a way to fill the "empty background" of a line. It is only vaguely related to the idea of text ending in a newline. For example, if you open the speedbar and then activate hl-line-mode, the "lines" are highlighted up to the window margin, though speedbar "lines" are not conceptually lines of text, but an outline of some structure (of course they *are* lines of text, implementation-wise). In that case, it happens that the last item in the speedbar ends with a newline, so hl-line-mode works as expected. But if the speedbar were implemented like bs-show is, and the last item had no newline, it would be equally surprising to see the whole "window line" highlighted in all items, and just partially in the last one. (Note: I'm not arguing for this to be implemented; just trying to explain why I would expect a behavior different of the current one.) --0000000000005dc7850594ef15d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 15, 2019 at 10:27 AM Eli Zaretskii <eliz@gnu.org> wrote:

> Face = extension is only a factor when it ends on the next line,
> i.e. &quo= t;covers" the newline that ends the line.=C2=A0 When there's no ne= wline
> at EOB, the face ends with the last character on the line, so= IMO it
> makes no sense to extend it, because what would such an ext= ension
> indicate?=C2=A0 When there's a newline, extending the fa= ce indicates that
> the newline (which is otherwise invisible) is &qu= ot;covered" by the face.

I understand, but again, that's an= explanation of how it works. For me, face extension is useful as a way to = fill the "empty background" of a line. It is only vaguely related= to the idea of text ending in a newline.=C2=A0

For example, if you = open the speedbar and then activate hl-line-mode, the "lines" are= highlighted up to the window margin, though speedbar "lines" are= not conceptually lines of text, but an outline of some structure (of cours= e they *are* lines of text, implementation-wise). In that case, it happens = that the last item in the speedbar ends with a newline, so hl-line-mode wor= ks as expected. But if the speedbar were implemented like bs-show is, and t= he last item had no newline, it would be equally surprising to see the whol= e "window line" highlighted in all items, and just partially in t= he last one.

(Note: I'm not arguing for this to be implemented; = just trying to explain why I would expect a behavior different of the curre= nt one.)
--0000000000005dc7850594ef15d0--