From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 69F87C7619A for ; Sat, 8 Apr 2023 11:40:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229698AbjDHLkS (ORCPT ); Sat, 8 Apr 2023 07:40:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59090 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229696AbjDHLkR (ORCPT ); Sat, 8 Apr 2023 07:40:17 -0400 Received: from relay05.pair.com (relay05.pair.com [216.92.24.67]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8C81A4ED2 for ; Sat, 8 Apr 2023 04:40:16 -0700 (PDT) Received: from orac.inputplus.co.uk (unknown [87.112.67.239]) by relay05.pair.com (Postfix) with ESMTP id BB4521A26F4; Sat, 8 Apr 2023 07:40:15 -0400 (EDT) Received: from orac.inputplus.co.uk (orac.inputplus.co.uk [IPv6:::1]) by orac.inputplus.co.uk (Postfix) with ESMTP id F16772083C; Sat, 8 Apr 2023 12:40:14 +0100 (BST) From: Ralph Corderoy To: linux-man@vger.kernel.org, groff@gnu.org cc: Eli Zaretskii , Dirk Gouders Subject: Re: reformatting man pages at SIGWINCH MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit In-reply-to: References: <073413e2-7d35-f0d7-26eb-f66908d7af6a@gmail.com> <834jpuuc1a.fsf@gnu.org> <6ea6d1fe-375f-487a-b524-adc86880d3de@gmail.com> <20230407021822.3grfnenicwjhdive@illithid> Date: Sat, 08 Apr 2023 12:40:14 +0100 Message-Id: <20230408114014.F16772083C@orac.inputplus.co.uk> Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org Hi, > > > (1) what part of the screen was the reader actually looking at? less(1) has -j; that would be a good start. > > > (2) how is the pager supposed to know how to map any given > > > location on the screen back to a place in the unrendered source > > > document so it can be accurately found when the document is > > > rerendered? I would assume the pager looks for the same place in its input, not in the man-page source. It keeps seeking forward to the best matching run of words, jumping to the best so far. Problems I can think of: - the formatter's input may be ephemeral and so need buffering, - the originator may not have intended that and limited its size, - seeking the best match after being WINCH'd must also buffer and may never reach EOF, - the input formatter may alter its output based on the terminal's size, e.g. a pic(1) diagram disappears, and - a solution which re-starts the pager loses the pager's ephemeral settings. I expect more would be found in practice. -- Cheers, Ralph.