all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Juri Linkov <juri@linkov.net>
Cc: 32536@debbugs.gnu.org
Subject: bug#32536: displayed width of man pages
Date: Tue, 27 Nov 2018 09:08:02 +0100	[thread overview]
Message-ID: <5BFCFB62.4030507@gmx.at> (raw)
In-Reply-To: <875zwjgypr.fsf@mail.linkov.net>

 >> (3) Run the buffer-local hook for changes of the window's body size
 >>      too.
 >
 > What might cause these changes?

Adding/removing fringes, dividers, scroll bars, mode or header lines
to/from a window.  Usually, applications do not care for the total
size of a window - they want to know the size of the text area only.

 > (4) Run the buffer-local hook also when a window has not shown the
 >>      buffer the last time this hook was run.
 >
 > Good, so initial buffer display will be automatically handled as well.

It should also include the following idiosyncrasy: Suppose a user
saves away a window in a configuration in some register, kills it and
revives the window from that register a few hours later.  How should
running size change functions handle that case?  The window has
neither changed buffer nor size since the last time it was shown.  I
currently just run the buffer-local hook (since the window was not
there the last time the functions were run) but without further
notice.  If someone thinks that the application should get notified in
some sense about this fact, then please tell me how.

 >> So essentially you would have to rerun occur whenever the Man buffer
 >> is reformatted.
 >
 > It's too ad-hoc to find all Occur buffers created from the Man buffer,
 > and revert all of them.

Is it reverting Man buffers only that causes problems?  I suppose
(auto-)reversal is a wide-spread disease.

 >> Otherwise, I see only one way to handle this.  Before reformatting,
 >> store the context of each marker (in a bookmark-like or diff-like
 >> fashion) and restore the markers from that context.  The matching done
 >> in the restore step would have to identify and ignore "soft" changes
 >> of whitespace.
 >
 > This means additionally to finding all affected Occur buffers like above,
 > instead of reverting them, perform much more complex processing of
 > their markers.
 >
 > It seems a more practical solution is to limit the width of Man buffers
 > to at least 80 columns by default, so splitting such windows will not
 > resize their number of columns, so they won't be reverted and reformatted.

Why is it that we care so much about Man buffers and live with the
fact that, for example, our *info* buffers have rigid width?

martin





  reply	other threads:[~2018-11-27  8:08 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-26 12:42 bug#32536: 24.3; Feature Request: change defaults or behaviour hw
2018-08-30 23:35 ` bug#32536: displayed width of man pages Juri Linkov
2018-08-31  6:54   ` martin rudalics
2018-09-01 22:27     ` Juri Linkov
2018-09-02  7:14       ` martin rudalics
2018-09-02 22:19         ` Juri Linkov
2018-09-03  7:31           ` martin rudalics
2018-09-03 22:23             ` Juri Linkov
2018-09-04  7:51               ` martin rudalics
2018-09-04 21:27                 ` Juri Linkov
2018-09-05  7:47                   ` martin rudalics
2018-11-25 20:42                   ` Juri Linkov
2018-11-26  9:32                     ` martin rudalics
2018-11-27  0:01                       ` Juri Linkov
2018-11-27  8:08                         ` martin rudalics [this message]
2018-11-27 23:58                           ` Juri Linkov
2018-09-04  5:46           ` hw
2018-09-04 21:20             ` Juri Linkov
2018-09-05  2:50               ` hw
2018-09-05 22:20                 ` Juri Linkov
2018-09-07 14:03                   ` hw
2018-09-02 22:30         ` Juri Linkov
2018-09-03  7:31           ` martin rudalics
2018-09-03 22:25             ` Juri Linkov
2018-09-04  7:51               ` martin rudalics
2018-09-02 14:55       ` hw
2018-09-02 22:12         ` Juri Linkov
2018-09-04  3:34           ` hw
2018-09-03 18:20       ` Filipp Gunbin
2018-12-26 23:36 ` Juri Linkov
2018-12-27 15:46   ` Eli Zaretskii
2018-12-27 20:54     ` Juri Linkov
2018-12-28  4:50       ` Eli Zaretskii
2019-12-07 22:37         ` Juri Linkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5BFCFB62.4030507@gmx.at \
    --to=rudalics@gmx.at \
    --cc=32536@debbugs.gnu.org \
    --cc=juri@linkov.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.