From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Support "\n" in icomplete-separator Date: Wed, 11 Nov 2020 18:30:29 +0200 Message-ID: <834klv26vu.fsf@gnu.org> References: <20201105235735.oxouuek66ehu5o45@Ergus> <20201106151541.dpgep7borlja25su@Ergus> <837dqv5huk.fsf@gnu.org> <83mtzp2qj0.fsf@gnu.org> <83r1p11369.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35907"; mail-complaints-to="usenet@ciao.gmane.io" Cc: spacibba@aol.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Andrii Kolomoiets Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 11 17:40:01 2020 Return-path: Envelope-to: ged-emacs-devel@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 1kctA9-0009A6-Nu for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 17:40:01 +0100 Original-Received: from localhost ([::1]:36204 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kctA8-0005Dz-OX for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 11:40:00 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39952) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kct0l-00043u-4X for emacs-devel@gnu.org; Wed, 11 Nov 2020 11:30:20 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59945) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kct0j-0003Xw-Sd; Wed, 11 Nov 2020 11:30:17 -0500 Original-Received: from [176.228.60.248] (port=1061 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kct0j-0004Ho-8A; Wed, 11 Nov 2020 11:30:17 -0500 In-Reply-To: (message from Andrii Kolomoiets on Tue, 10 Nov 2020 23:09:03 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:259025 Archived-At: > From: Andrii Kolomoiets > Cc: spacibba@aol.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca > Date: Tue, 10 Nov 2020 23:09:03 +0200 > > >> (defvar o (make-overlay 0 0 nil t t)) > >> (minibuffer-with-setup-hook > >> (lambda () > >> (set (make-local-variable 'face-remapping-alist) > >> '((default :height 1.3))) > >> (move-overlay o (point) (point) (current-buffer)) > >> (let ((text (mapconcat > >> #'identity > >> '("Some" "text" "that" "will" "not" "fit" > >> "the" "minibuffer" "window") > >> "\n"))) > >> (put-text-property 0 1 'cursor t text) > >> (overlay-put o 'after-string text))) > >> (read-string "Multiline\nprompt: ")) > >> > >> Is it possible to make the prompt visible? Should I file bug report > >> for this? > > > > What is the bug here? > > I don't take the overlay text as the actual text but rather like a hint > or helper. E.g. in icomplete-mode overlay text shows what part of the > text can be automatically completed. Overlay text can be completelly > hidden and even in this case I will be able to enter the text. > > The prompt is more important. Imagine there are two prompts: "Selected > file will be deleted. Select file: " and "Selected file will be > opened. Selected file: ". I certainly don't want to see only "Select > file:" because all the space is occupied by hints. Hide hints but show > me the full prompt. That is one way of looking at this. But it is not the only one, or at least it doesn't necessarily fit all the uses of the minibuffer. First, the overlay text is not just a "hint": sometimes it is very important to let you know what to type next. For example, the list of files in a large directory that are completion candidates is very important to see, unless you know in advance what file you want. Moreover, in some cases those "hints" are the _only_ way of knowing what inputs are acceptable: imagine a multiple-selection question where only a finite set of possible answers is acceptable, and you don't know in advance what that set is. E.g., this: Send this email message by: {Mailclient, Smtp, XDG-email} - - - Without seeing the possible answers, what are your chances of knowing what to type? OTOH, sometimes the prompt is not important: when you yourself invoke the command that prompts. For example, if you type "C-x C-f", how important is it for you to see the "Find file" prompt? Probably not too important. > The point is more important than the prompt, obviously. I must see > where and what I typed. That is a non-issue, since Emacs always shows point. > IMO the minibuffer behavior about the prompt, the text and the overlay > should be: show as much text before point as possible (including the > prompt), then show the rest of the text (in case the point is not at the > end of the text) and then show the overlay text. Do you still think this is always true? > And here I come to the answer to your question: for me, the bug here is > that the prompt is hidden in favor of the overlay text. The strategy Emacs uses to display stuff in the mini-window is shared by both minibuffer and echo-area display -- in the latter case your proposal that distinguishes between the prompt, the rest of the text, and the overlay at the end, will not necessarily make sense. The design of that strategy assumed that text displayed in the mini-window is relatively short. It is easy to break this strategy by using features that were never intended to be extensively used in the mini-window. But those uses don't invalidate the design assumptions, they just demand support for very different use cases. Thus, a "bug" is not an appropriate name for what you are bringing up, and I hope you will agree that a single strategy will never be able to cover all the possible uses of the mini-window. The conclusion, IMO, is that the application should tell the display engine how it wants to display the stuff in the mini-window in the "unusual" cases, where the default strategy produces sub-optimal results.