From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jim Blandy Newsgroups: gmane.emacs.devel Subject: PATCH: Don't mark entire man sections bold Date: Fri, 16 Oct 2020 23:26:11 -0700 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000c85e4505b1d7f5a8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2050"; mail-complaints-to="usenet@ciao.gmane.io" To: Emacs Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 17 08:27:02 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kTfgE-0000S1-Iu for ged-emacs-devel@m.gmane-mx.org; Sat, 17 Oct 2020 08:27:02 +0200 Original-Received: from localhost ([::1]:53530 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kTfgD-0001KI-Lb for ged-emacs-devel@m.gmane-mx.org; Sat, 17 Oct 2020 02:27:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58386) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kTffh-0000qo-5B for emacs-devel@gnu.org; Sat, 17 Oct 2020 02:26:29 -0400 Original-Received: from mail-il1-f178.google.com ([209.85.166.178]:40873) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kTffe-0004iw-Ok for emacs-devel@gnu.org; Sat, 17 Oct 2020 02:26:28 -0400 Original-Received: by mail-il1-f178.google.com with SMTP id i7so3105347ils.7 for ; Fri, 16 Oct 2020 23:26:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tQD6OZ5/WDUotuaMS231s5ao+f+vEDnaOvpo4w3s1hY=; b=sIrCLA+luq0vYgGVMn4yxyQTEvTjNeqezsRg4aG3TkP7wMnfjBsJ0xTO6JuDqHEeZ8 iIEh4X8xpNokBd3axLXuVOW780cT6nIO9AZC7oBAOBDhCFXvOW4ycs5u6fD7fs9UsruD lbXc4QLiA3eTsQfP/Rg578A2GI5CVz+B+ja1E4bEE12yb6zoAyOwS86CW5Zvrszx5YRO 9S+hAOf12epObwY3NMjN/AhxfX5w9h8sOO3dVDD1urGOTdqLolp3qSKHyuzN9blD47x1 N+oF0ZOJ6y8y4UNZ9e6uGqsKbHpU7r6L4FEkqd5haidvFMo+Cr49SfUK0hYbCAnQdaKF RIWA== X-Gm-Message-State: AOAM532HE+M3JzyvA3nkzLbX7da4L7vrcgLE7qrXZtH2nbVClmP83Lot IqSopXHOFgtXNNMr2l3UD31oUMHihCwM7UDI4MfBY9gh/h8= X-Google-Smtp-Source: ABdhPJw6mlL+yh7PUa9Ximl8y6XN6b/yPR207vkN1751DUOd4Nn2+JjAVA+fmLLeUosTbZSzjcKhRcMNa2McQLAB+0Q= X-Received: by 2002:a92:5a08:: with SMTP id o8mr5090341ilb.32.1602915983185; Fri, 16 Oct 2020 23:26:23 -0700 (PDT) Received-SPF: pass client-ip=209.85.166.178; envelope-from=jimblandy@gmail.com; helo=mail-il1-f178.google.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/17 02:26:23 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:257917 Archived-At: --000000000000c85e4505b1d7f5a8 Content-Type: text/plain; charset="UTF-8" If Man-bgproc-filter, receiving async output from `man`, happens to get a chunk from the subprocess that ends in a bold (or whatever) section, but not in the middle of an escape sequence, the entire section up to the end of that output chunk gets marked bold. This is because Man-fontify-manpage wants to process whole sections at once (not sure why, but it's what the comment there says), so Man-bgproc-filter doesn't tell it the true starting position of the newly inserted text it just received, instead always backing up to the last section start. Since successive calls to Man-fontify-manpage are passed regions that overlap, these are passed along to ansi-color-apply-on-region. ansi-color-apply-on-region is prepared to resume work at a position *earlier* than requested, to handle chunks that ended in the middle of an escape sequence. But it assumes that otherwise, if it left off work with some sort of highlighting active, then when it's called again, it should resume that highlighting at the `begin` position it's passed. If that `begin` position has been backed up to the last man section start, it ends up bolding the whole section up until the end of some random bold bit. Maybe `Man-fontify-manpage` should be passed more arguments. But it seemed easier just to make ansi-color-apply-on-region more robust, and have it remember the proper starting position whenever there's some highlighting to be resumed. commit 2b65205572277260d4a317f82bd7d1dd7493287f (HEAD -> ansi-color-man-restart-fix) Author: Jim Blandy Date: Fri Oct 16 22:35:16 2020 -0700 Man highlighting: Don't occasionally bold entire sections. * lisp/ansi-color.el (ansi-color-apply-on-region): Always save a restart position in ansi-color-context-region if the region ends with highlighting active. diff --git a/lisp/ansi-color.el b/lisp/ansi-color.el index 141ad2353e..c3b2d98c14 100644 --- a/lisp/ansi-color.el +++ b/lisp/ansi-color.el @@ -414,11 +414,17 @@ ansi-color-apply-on-region ;; if the rest of the region should have a face, put it there (funcall ansi-color-apply-face-function start-marker end-marker (ansi-color--find-face codes)) - (setq ansi-color-context-region (if codes (list codes))))) + ;; Save a restart position when there are codes active. It's + ;; convenient for man.el's process filter to pass `begin' + ;; positions that overlap regions previously colored; these + ;; `codes' should not be applied to that overlap, so we need + ;; to know where they should really start. + (setq ansi-color-context-region (if codes (list codes end-marker))))) ;; Clean up our temporary markers. (unless (eq start-marker (cadr ansi-color-context-region)) (set-marker start-marker nil)) - (set-marker end-marker nil))) + (unless (eq end-marker (cadr ansi-color-context-region)) + (set-marker end-marker nil)))) (defun ansi-color-apply-overlay-face (beg end face) "Make an overlay from BEG to END, and apply face FACE. --000000000000c85e4505b1d7f5a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If Man-bgproc-filter, receiving async output from `man`, h= appens to get a chunk from the subprocess that ends in a bold (or whatever)= section, but not in the middle of an escape sequence, the entire section u= p to the end of that output chunk gets marked bold.

This is because = Man-fontify-manpage wants to process whole sections at once (not sure why, = but it's what the comment there says), so Man-bgproc-filter doesn't= tell it the true starting position of the newly inserted text it just rece= ived, instead always backing up to the last section start. Since successive= calls to Man-fontify-manpage are passed regions that overlap, these are pa= ssed along to ansi-color-apply-on-region.

ansi-color-apply-on-region= is prepared to resume work at a position *earlier* than requested, to hand= le chunks that ended in the middle of an escape sequence. But it assumes th= at otherwise, if it left off work with some sort of highlighting active, th= en when it's called again, it should resume that highlighting at the `b= egin` position it's passed.

If that `begin` position has been ba= cked up to the last man section start, it ends up bolding the whole section= up until the end of some random bold bit.

Maybe `Man-fontify-manpag= e` should be passed more arguments. But it seemed easier just to make ansi-= color-apply-on-region more robust, and have it remember the proper starting= position whenever there's some highlighting to be resumed.


commit 2b65205572277260d4a317f82bd7d1dd7493287f (HEAD ->= ansi-color-man-restart-fix)
Author: Jim Blandy <jimb@red-bean.com>
Date: =C2=A0 Fri Oct 16 22:35= :16 2020 -0700

=C2=A0 =C2=A0 Man highlighting: Don't occasionall= y bold entire sections.
=C2=A0 =C2=A0
=C2=A0 =C2=A0 * lisp/ansi-colo= r.el (ansi-color-apply-on-region): Always save a
=C2=A0 =C2=A0 restart p= osition in ansi-color-context-region if the region ends with
=C2=A0 =C2= =A0 highlighting active.

diff --git a/lisp/ansi-color.el b/lisp/ansi= -color.el
index 141ad2353e..c3b2d98c14 100644
--- a/lisp/ansi-color.e= l
+++ b/lisp/ansi-color.el
@@ -414,11 +414,17 @@ ansi-color-apply-on-= region
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; if the rest of the region should h= ave a face, put it there
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (funcall ansi-color= -apply-face-function
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0start-marker end-marker (ansi-color--find-face codes))
- = =C2=A0 =C2=A0 =C2=A0 (setq ansi-color-context-region (if codes (list codes)= ))))
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0;; Save a restart position when there = are codes active. It's
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0;; convenient fo= r man.el's process filter to pass `begin'
+ =C2=A0 =C2=A0 =C2=A0= =C2=A0;; positions that overlap regions previously colored; these
+ =C2= =A0 =C2=A0 =C2=A0 =C2=A0;; `codes' should not be applied to that overla= p, so we need
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0;; to know where they should = really start.
+ =C2=A0 =C2=A0 =C2=A0 (setq ansi-color-context-region (if= codes (list codes end-marker)))))
=C2=A0 =C2=A0 =C2=A0;; Clean up our t= emporary markers.
=C2=A0 =C2=A0 =C2=A0(unless (eq start-marker (cadr ans= i-color-context-region))
=C2=A0 =C2=A0 =C2=A0 =C2=A0(set-marker start-ma= rker nil))
- =C2=A0 =C2=A0(set-marker end-marker nil)))
+ =C2=A0 =C2= =A0(unless (eq end-marker (cadr ansi-color-context-region))
+ =C2=A0 =C2= =A0 =C2=A0(set-marker end-marker nil))))
=C2=A0
=C2=A0(defun ansi-col= or-apply-overlay-face (beg end face)
=C2=A0 =C2=A0"Make an overlay = from BEG to END, and apply face FACE.
--000000000000c85e4505b1d7f5a8--