From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Support "\n" in icomplete-separator Date: Tue, 10 Nov 2020 18:18:33 +0000 Message-ID: References: <20201105235735.oxouuek66ehu5o45@Ergus> <20201106151541.dpgep7borlja25su@Ergus> <837dqv5huk.fsf@gnu.org> <83mtzp2qj0.fsf@gnu.org> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15253"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: Eli Zaretskii , 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 Tue Nov 10 19:21:12 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 1kcYGW-0003t0-0S for ged-emacs-devel@m.gmane-mx.org; Tue, 10 Nov 2020 19:21:12 +0100 Original-Received: from localhost ([::1]:41334 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcYGU-00025v-V9 for ged-emacs-devel@m.gmane-mx.org; Tue, 10 Nov 2020 13:21:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37166) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcYEJ-0008QW-Ry for emacs-devel@gnu.org; Tue, 10 Nov 2020 13:18:58 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:62838) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcYEH-0006py-EJ; Tue, 10 Nov 2020 13:18:55 -0500 Original-Received: from sdf.org (IDENT:ghe@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 0AAIIal3013540 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 10 Nov 2020 18:18:37 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 0AAIJ5FA000812; Tue, 10 Nov 2020 18:19:05 GMT In-Reply-To: Received-SPF: pass client-ip=205.166.94.24; envelope-from=ghe@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/10 13:18:46 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:258982 Archived-At: > > (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: ")) > This is one of the cases where it does not work, indeed. Another one is (again with emacs -Q): (let (w bd) (setq w 60) (setq bd (concat (temporary-file-directory) (make-string w ?a) "/")) (dolist (d '("a" "b" "c" "d" "e")) (make-directory (concat bd d) t)) (setq default-directory bd) (set-frame-height nil 20) (set-frame-width nil (+ (length bd) 10)) (icomplete-mode) (setq icomplete-separator "\n") (call-interactively 'insert-file)) > > Is it possible to make the prompt visible? > Yes it is. As I already told you, to make the prompt visible in all cases (when it is not impossible to make it visible) it is necessary to ask redisplay to start displaying at the beginning of the buffer. I provided short and simple Lisp-only solution for this: (defvar-local start-display-at-beginning-of-minibuffer nil) (defun start-display-at-beginning-of-minibuffer (&rest args) (when (and start-display-at-beginning-of-minibuffer (minibufferp)) (set-window-start-at-begin (point-min) (point)))) (defun set-window-start-at-begin (beg end) (when (< (+ beg 2) end) (set-window-start nil beg) (unless (pos-visible-in-window-p end nil t) (set-window-start-at-begin (+ beg (/ (- end beg) 2)) end)))) (add-hook 'window-scroll-functions #'start-display-at-beginning-of-minibuffer) (add-hook 'post-command-hook #'start-display-at-beginning-of-minibuffer) Just add (setq start-display-at-beginning-of-minibuffer t) in your minibuffer-with-setup-hook lambda, and it will work as you expect it to work. As I said a few days ago in the "Feature branches review please" thread, the problem of this solution is that Eli doesn't like it. He thinks another solution, using a text property that would be put on the prompt, should be implemented. Stefan thinks yet another solution, using the buffer redisplay routines instead of using a specific redisplay code for minibuffers, should be used. > > Should I file bug report for this? > I think you should read the other relevant bug reports first (bug#24293, bug#39379, bug#43519 and bug#43572). AFAIU the remaining 1% cases which are demonstrated by the two above recipes are not considered important enough to be classified as "bugs", so it is more a "feature request".