From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#51590: follow-mode is broken with header-line and tab-line Date: Tue, 9 Nov 2021 11:10:58 +0100 Message-ID: References: <86bl31xfl9.fsf@mail.linkov.net> <83h7ctgk93.fsf@gnu.org> <86pmrf3l9m.fsf_-_@mail.linkov.net> <835yt7g3my.fsf@gnu.org> <8335o9dazn.fsf@gnu.org> <83bl2xbhz1.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4638"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 51590@debbugs.gnu.org, juri@linkov.net To: Alan Mackenzie , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 09 11:12:11 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1mkO6s-00012t-SM for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Nov 2021 11:12:10 +0100 Original-Received: from localhost ([::1]:46022 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mkO6r-0008Rf-1S for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Nov 2021 05:12:09 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55830) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mkO6k-0008RV-Sv for bug-gnu-emacs@gnu.org; Tue, 09 Nov 2021 05:12:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49370) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mkO6k-0003Ue-Kn for bug-gnu-emacs@gnu.org; Tue, 09 Nov 2021 05:12:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mkO6k-0000a5-6K for bug-gnu-emacs@gnu.org; Tue, 09 Nov 2021 05:12:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 09 Nov 2021 10:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51590 X-GNU-PR-Package: emacs Original-Received: via spool by 51590-submit@debbugs.gnu.org id=B51590.16364526772118 (code B ref 51590); Tue, 09 Nov 2021 10:12:02 +0000 Original-Received: (at 51590) by debbugs.gnu.org; 9 Nov 2021 10:11:17 +0000 Original-Received: from localhost ([127.0.0.1]:60916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mkO61-0000Y6-2s for submit@debbugs.gnu.org; Tue, 09 Nov 2021 05:11:17 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:47307) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mkO5w-0000Xq-Tg for 51590@debbugs.gnu.org; Tue, 09 Nov 2021 05:11:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1636452661; bh=ch0DsYzw83g/hq2aCHGqPzbKi3JrX0uyUCwjuJR+tW4=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=gtnfYUVmZIhta84HAiqpbn0fZXdY+hgS5xtmtsa+p7398xFhYqI5VlTSFmlqSNTuS fUBIbHDFQHhK5AEn69zRwh9MeccWIIJ0I73terWf3HNGb9C2cr39s4kzbzbhNVfpOK Y+pYFbD8MaJ0x/Y0/pzJvdP1w0frbbwIhLPYjY9o= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.59]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MJmKh-1mzz2K0Cnx-00K7A9; Tue, 09 Nov 2021 11:11:01 +0100 In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:YjRBfzENw+F1YxFwcF2rt+jGR1PPOzYD+Kg0/sXgmhVTnBCxpX9 7bBRIr0GpZBbGcjN9JHjRszVlONE6/T7lx4ap7HPZlToQ8JKN9XQQH9c+kNW17/AmhiFZR8 KfVM+V0Qjeyanfyiv7emCpQBwjR3jSk0cSUlDC/tVFVcgwPrzsY+ZWbL9FBVuMXBBRcu/Do VQtlBCYv/eokjdv3/4Wew== X-UI-Out-Filterresults: notjunk:1;V03:K0:QLNTqYs50qw=:NdKJzYxtheLVe6yBkhbPvm JJpJAj54DOXQ1RMEDKQVw+NqNB85hl3wV9QQstl0pGuQcEpK1bXtxIAw5ge8vECl/gZB2wMn9 CeM6KaRqrMk8GZJKTpOW8Oh9nCc/gQ8xi9v4YqBH6rOCaBfL9EpSiqosMjehIjJiLF5PYCZNg 7OXoOm8O8Avq3CUKdhl7VUPHSUfGW2UC09Jn9FyCunH8Ekzyys7aFekgPpfkKSa1enEjBdeIB GouW9qGqVFDUrrcfehQfAEn5UQmanK4TM39Jfj+LzSQn9NDNmJEyvOAGHZ1EQm6tteBGvK7oB WQak3EzIopHd1QkVMuispv+Vqvb139LAqJoNb1T2Y2MnYMmXYs9jR2f0GiIvaMrR0GDZyIC0l SZHKshgVjfH+GgMsacMlEl1ijGeZSAC101M5t3LmaTE1f9N9sx4YNUI0tNKs2ERZS5lAUbZYw kOsQ7IntS6wcWZTBPRitBjq/PTzz0go59uzVp07PGVYtGcM6mg7tM68fxmnydp3eNiku9QJII ZwvlrKwmpFzuKvz5JMzVGG1iqPW4Jgea1NglU/UOuBsg4Thl/7/cifB8rH9A+7cSxZtuxyyTU iQ7jURdgW2w9El5bEjmCWu6RRk30mEmwdicvaslDG1ACxnbphucsIP3U/JfT7aKau+xSh2P1T 8uFzbIwM24IAlgovz3ak+2EuJ3F4S4JurBELDKnrwLp6SzLNJ5tj4U2lKcbVIhHQemZkfEicw v0QJ4lb+lfd/Z9Fz7zffFd7dyFGddJrUPNsGNahCFnZYDp9/fo5xl10XM3jaXvzo1m1KZmWC X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:219432 Archived-At: > I've done a survey of window.c, keyboard.c, window.el for all occurrences > of "text area" and "body" in function names, doc strings, some comments, > and parameter names. The source I've grepped is an almost up to date > copy of the emacs-28 branch. The function name is at the left, followed > by annotations for text area and body. "BIG" means the term includes the > header and tab lines, "small" means it does not, "?" means it is not > immediately clear, blank means it is irrelevant or not mentioned. Thanks. Note that searching for "text area" alone is not sufficient. In the past, the "thing" (the body of a window) we talk about here has been described in various ways, usually according to the personal taste of the author of a change. You missed, for example, 'window-text-width' which uses the term "text display area" for this. I've usually tried to retain the nomenclature originally used by the authors because it's hardly ever immediately evident what they really had in mind and also in the hope that the use of functions like 'window-text-width' would eventually fade out. The greatest problem in this area is that Emacs traditionally uses the terms 'window-height' to refer to the total height of a window and 'window-width' to refer to its body width. Obviously, all occurrences of these two terms should be replaced with 'window-total-height' and 'window-body-width' respectively but you can easily see for yourself the progress I have made. Hence, rather than caring about the (IMO) very minor "text area" issue, fixing these occurrences should be our major aim if we want to remove inconsistencies. Sadly, people add new occurrences of these at a faster pace than I'm able to remove the older ones. > Function Text Area Body > -------- --------- ---- > Fwindow_body_width Any function that has "body" in its name is "safe" (and means "small" in your nomenclature) so we can usually ignore them. Their doc-strings, however, may use some variant of "text area" since that was the term commonly in use at the time the "body" functions were added. > Fwindow_body_height small (small) > Fwindow_old_body_pixel_width > Fwindow_old_body_pixel_height ? > Fwindow_lines_pixel_dimensions confused. 'window-lines-pixel-dimensions' is like 'window-text-pixel-size' but works line-wise. More precisely, it can be used to walk the buffer text shown in a window and get the number of pixels occupied by each individual line. The BODY argument serves to control the impact the presence of a header or mode line could have on the return value. > Fwindow_text_height small > Fset_window_fringes > window_body_height small > window_body_width > window_change_record_windows ? 'window_change_record_windows' does not make any reference to the text area so why the "?". > run_window_change_functions > Vwindow_size_change_functions > Vwindow_state_change_functions > Vwindow_state_change_hook > Vwindow_configuration_change_hook I tried to very carefully distinguish between body and total sizes here because, for example, a change in the width of a fringe may or may not change the body width of a window and leave the total width alone. So there should not be any problems with these. > make_lispy_position small > make_lispy_event ? > read_key_sequence small > Fposn_at_x_y BIG I never thoroughly checked the keyboard and mouse defined routines. There anything is possible. > window-body-size ? > window-edges ? ? > window-absolute-body-pixel-edges ? ? > window-largest-empty-rectangle ? > window-preserve-size ? > > window-body-edges ? > window-body-pixel-edges ? All of these are new and should be "small" although their docs may still contain references to the "text area". But the far greater problem is to find all occurrences of "text" in the manuals, for example, where it stands for the width or height of the buffer text shown in a window. Often I read and re-read the manual a couple of times in order to find out what is really meant and whether what I read is not biased because I've read some different part of the manual before. These parts of the manual suffer most from the transition of Emacs from TTYs to GUIs over time and the accompanying changes of its nomenclature. > It seems clear that, at least in the places where the meaning of "text > area" and "body" are clear, that they refer to the area which doesn't > include the header line and tab line. > > Fposn_at_x_y stands out as the only function with BIG. Maybe the picture > would change on examining the elisp manual. Maybe some of the unclear > annotations would resolve to BIG, but that doesn't seem all that likely. > > Given this, it seems it would be better to amend the documentation of > Fposn_at_x_y to refer to the "text area _plus_ any header line or tab > line". Or _not use_ the term "text area" here in the first place. martin