unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Juri Linkov <juri@jurta.org>, Lars Ingebrigtsen <larsi@gnus.org>
Cc: Lennart Borgman <lennart.borgman@gmail.com>, 6000@debbugs.gnu.org
Subject: bug#6000: describe-text-sexp does not know window-width
Date: Sun, 6 Jun 2021 09:42:22 +0200	[thread overview]
Message-ID: <b4e75298-339c-b41e-3e42-e1cb88974faa@gmx.at> (raw)
In-Reply-To: <87h7ie3isy.fsf@mail.linkov.net>

 >> Does anybody have a test case that displays the problem (in case it's
 >> still in place after all these years)?
 >
 > Indeed a test case would be needed, but I have none.

With emacs -Q evaluate

(progn
   (split-window nil -20 t)
   (put-text-property 1 2 'foo "This is a very long text property")
   (describe-char 1))

or

(progn
   (setq split-height-threshold nil)
   (setq split-width-threshold 20)
   (put-text-property 1 2 'foo "This is a very long text property")
   (describe-char 1))

Here these show a *Help* window on the right where not the entire text
property string is visible.  Depending on your settings it won't matter
much because the rest of that buffer is only partially visible too.

To show the inverse effect, again with emacs -Q, evaluate

(progn
   (split-window nil 20 t)
   (put-text-property 1 2 'foo t)
   (describe-char 1))

Here this shows *Help* in the window on the right with a line

   foo                  [Show]

where clicking on [Show] will show "t" in the window on the left.
This is embarrassingly silly.

Obviously, there are many more scenarios but most of them require to
customize `display-buffer-alist'.  Presumably, most people don't notice
the behavior - they just got used to it.

We could

- Do nothing: If, in the earlier scenarios, we'd insert a "Show" button
   instead of the text, clicking that button might again pop up a too
   narrow *Pp Eval Output* window and nothing has been gained.  As for
   the last scenario, we could tell users that they are on their own when
   they invoke `describe-char' in a too narrow window.

- Skip the `window-width' check in `describe-text-sexp' and maybe
   recommend using `temp-buffer-resize-mode' with a few tweaks like

(progn
   (temp-buffer-resize-mode)
   (setq temp-buffer-max-width 100)
   (setq fit-window-to-buffer-horizontally t)
   (setq split-height-threshold nil)
   (setq split-width-threshold 20)
   (put-text-property 1 2 'foo "This is a very long text property")
   (describe-char 1))

   But some people don't like `temp-buffer-resize-mode'.

- Calculate the maximum width of text in the buffer preceding the line
   where to insert the property with a function like

(defun max-column-in-frame ()
   "Return maximum column of current buffer in selected frame.
The return value is the longest column from the beginning of the
buffer to the line specified by the selected frame's height."
   (save-excursion
     (goto-char (point-min))
     (let ((width (frame-width))
	  (height (frame-height))
	  (line 0)
	  (max-column 0)
	  column)
       (while (and (< line height) (< (point) (point-max)))
	(setq column (move-to-column width))
	(when (> column max-column)
	  (setq max-column column))
	(forward-line 1)
	(setq line (1+ line)))
       max-column)))

and use that instead of `window-width' in `describe-text-sexp' as

     	     (<= (length pp) (- (max-column-in-frame) (current-column))))

This will delegate the problem to those who inserted text earlier into
that buffer.  If they were right, `describe-text-sexp' won't do anything
wrong.

martin





      parent reply	other threads:[~2021-06-06  7:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-22 12:15 bug#6000: describe-text-sexp does not know window-width Lennart Borgman
2014-07-01 23:37 ` Juri Linkov
2021-06-03  9:07   ` Lars Ingebrigtsen
2021-06-03 20:25     ` Juri Linkov
2021-06-04  9:18       ` martin rudalics
2021-06-04  9:49         ` Lars Ingebrigtsen
2021-06-04 12:44           ` martin rudalics
2021-06-06  9:03             ` Lars Ingebrigtsen
2021-06-06  7:42       ` martin rudalics [this message]

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=b4e75298-339c-b41e-3e42-e1cb88974faa@gmx.at \
    --to=rudalics@gmx.at \
    --cc=6000@debbugs.gnu.org \
    --cc=juri@jurta.org \
    --cc=larsi@gnus.org \
    --cc=lennart.borgman@gmail.com \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).