unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Gregory Heytings <ghe@sdf.org>
Cc: acm@muc.de, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
	juri@linkov.net
Subject: Re: New multi-command facility displays in the wrong echo area.
Date: Mon, 12 Oct 2020 19:01:23 +0300	[thread overview]
Message-ID: <83mu0r3030.fsf@gnu.org> (raw)
In-Reply-To: <alpine.NEB.2.22.394.2010121639210453.13342@sdf.lonestar.org> (message from Gregory Heytings on Mon, 12 Oct 2020 15:41:35 +0000)

> Date: Mon, 12 Oct 2020 15:41:35 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: Juri Linkov <juri@linkov.net>, acm@muc.de, monnier@iro.umontreal.ca,
>         emacs-devel@gnu.org
> 
> > In any case, I think the condition could be relaxed: we only care about 
> > how much space is left from the minibuffer text's end till the end of 
> > the screen line, so "if minibuffer text size modulo window-width is less 
> > than something" would be better, I think.  E.g., if you use 70 instead 
> > of 67 in your recipe, the problem is mostly gone.
> 
> The condition could be refined indeed, but the modulo operation you 
> propose would not work with variable pitch faces.

It will, if the calculation is done in pixels.  The APIs you mentioned
can return pixels instead of columns, or there are alternatives which
do.

> I intentionally proposed something simple, which should work in
> (almost) all cases.  I'm an adept of the KISS principle.

Me too; "the solution should as simple as possible, but not simpler."

> > Also, it would be safer to use string-width instead of the number of 
> > characters, or even window-text-pixel-size: some people do customize the 
> > faces used in the minibuffer.
> 
> I won't comment on this.  As I already said elsewhere, it's IMO awful to 
> expect any code to do something like this.

That function was written because it's really needed and useful.  We
use it under the hood, and I see no reason not to use it in this case,
which is exactly one of the cases for which the function was
implemented.

> See above.  I've now read that bug thread, and I'm not at all convinced 
> that the chosen solution was TRT, quite the contrary.

We can discuss other solutions, of course.  However, significant
changes will have to wait for Emacs 28.

> It seems to me that being wiser would mean taking the time to evaluate a 
> proposed solution, instead of rejecting it outright based on a gut 
> feeling.

Please give me the credit of having done so.  I've given you no reason
to believe otherwise; disagreement doesn't imply incompetence or
sloppiness on my part.  It is simply unfair and even rude to suggest
that.



  reply	other threads:[~2020-10-12 16:01 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-09 16:34 New multi-command facility displays in the wrong echo area Alan Mackenzie
2020-10-09 19:47 ` Stefan Monnier
2020-10-09 20:38   ` Alan Mackenzie
2020-10-09 22:12     ` Stefan Monnier
2020-10-09 22:56       ` Drew Adams
2020-10-10  6:52     ` Eli Zaretskii
2020-10-10 10:32       ` Alan Mackenzie
2020-10-10 11:13         ` Eli Zaretskii
2020-10-10 12:36           ` Gregory Heytings via Emacs development discussions.
2020-10-10 12:44           ` Alan Mackenzie
2020-10-10 12:50             ` Eli Zaretskii
2020-10-10 13:00               ` Eli Zaretskii
2020-10-10 20:30                 ` Gregory Heytings via Emacs development discussions.
2020-10-11 14:38                   ` Eli Zaretskii
2020-10-12  9:12                     ` Gregory Heytings via Emacs development discussions.
2020-10-12 12:00                       ` Alan Mackenzie
2020-10-12 12:18                         ` Gregory Heytings via Emacs development discussions.
2020-10-12 14:37                       ` Eli Zaretskii
2020-10-12 15:41                         ` Gregory Heytings via Emacs development discussions.
2020-10-12 16:01                           ` Eli Zaretskii [this message]
2020-10-12 16:31                             ` Gregory Heytings via Emacs development discussions.
2020-10-12 17:20                               ` Eli Zaretskii
2020-10-12 21:06                                 ` Gregory Heytings via Emacs development discussions.
2020-10-13 14:03                                   ` Eli Zaretskii
2020-10-13 19:27                                     ` Gregory Heytings via Emacs development discussions.
2020-10-13 21:22                                       ` Gregory Heytings via Emacs development discussions.
2020-10-12 17:12                         ` Drew Adams
2020-10-12 17:34                           ` Eli Zaretskii
2020-10-12 19:46                         ` Juri Linkov
2020-10-13  2:25                           ` Eli Zaretskii
2020-10-14 20:44                       ` Gregory Heytings via Emacs development discussions.
     [not found]                         ` <1cd65040-f7ad-4613-b3fb-7cfa62bb0488@default>
2020-10-14 22:15                           ` Gregory Heytings via Emacs development discussions.
2020-10-14 22:51                         ` Stefan Monnier
2020-10-16  7:19                           ` Eli Zaretskii
2020-10-16  7:19                         ` Eli Zaretskii
2020-10-10 13:03             ` Gregory Heytings via Emacs development discussions.
2020-10-10 13:47               ` Alan Mackenzie
2020-10-10 20:20                 ` Gregory Heytings via Emacs development discussions.
2020-10-09 21:14   ` Gregory Heytings via Emacs development discussions.
2020-10-09 21:48     ` Gregory Heytings via Emacs development discussions.
2020-10-10 10:15       ` Alan Mackenzie
2020-10-10 13:44         ` Stefan Monnier
     [not found] <<20201009163445.GB4027@ACM>
     [not found] ` <<jwv362nkwss.fsf-monnier+emacs@gnu.org>
     [not found]   ` <<20201009203810.GC4027@ACM>
     [not found]     ` <<83imbi609a.fsf@gnu.org>
2020-10-10 16:11       ` Drew Adams
2020-10-10 20:40         ` Gregory Heytings via Emacs development discussions.
2020-10-11  0:59           ` Drew Adams

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=83mu0r3030.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=ghe@sdf.org \
    --cc=juri@linkov.net \
    --cc=monnier@iro.umontreal.ca \
    /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).