From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Support "\n" in icomplete-separator Date: Tue, 17 Nov 2020 09:05:31 -0500 Message-ID: References: <20201105235735.oxouuek66ehu5o45@Ergus> <20201106151541.dpgep7borlja25su@Ergus> <837dqv5huk.fsf@gnu.org> <83mtzp2qj0.fsf@gnu.org> <83r1p11369.fsf@gnu.org> <834klv26vu.fsf@gnu.org> <835z69y7kc.fsf@gnu.org> <83tuttwgsp.fsf@gnu.org> <83pn4hwedn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31388"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , spacibba@aol.com, andreyk.mad@gmail.com, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 17 15:06:21 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 1kf1ci-0007iC-42 for ged-emacs-devel@m.gmane-mx.org; Tue, 17 Nov 2020 15:06:20 +0100 Original-Received: from localhost ([::1]:44256 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kf1ch-00023P-5s for ged-emacs-devel@m.gmane-mx.org; Tue, 17 Nov 2020 09:06:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57590) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kf1c3-0001cn-9r for emacs-devel@gnu.org; Tue, 17 Nov 2020 09:05:39 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21927) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kf1c0-0007r8-OJ; Tue, 17 Nov 2020 09:05:38 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B6F6D80968; Tue, 17 Nov 2020 09:05:34 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1452C80C1A; Tue, 17 Nov 2020 09:05:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1605621933; bh=6JKUN/dfA8/7JRm1yX7xdAIecaT7Asgw6e2uytyVET4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=WAM1cL9ngYZ1bgECtTSMDRy4JtviP5OVI6jijRJgTNClkJQjgzHxK+zXHbnsid7Dq HM545kAophuKkx4SNEPcxYaNRRiq7qXqxvQWiicCYQPLONsJJn1XJLYhPSlATd31n/ I4cH4VJ8/wiJwETpgTkqtM6UAX060Iv31abXInXSgg9wOzt9eqXn4EzKk6E4P5ooWA 44z+T8m3Z4Hp9efA3xQUHcOvehJAKQXKqoSvp65efPWjhlZYLphePk2yAXivSbj5Bv W8W40WLJfRAtqMMJBczA6oBobhaVK7BSGKwGafVE2c66njAfRo98vE+/Tvq7O1TCVu wYqLh8kpXpbpA== Original-Received: from alfajor (unknown [157.52.9.240]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BA41D12034B; Tue, 17 Nov 2020 09:05:32 -0500 (EST) In-Reply-To: (Gregory Heytings's message of "Tue, 17 Nov 2020 11:51:05 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/17 08:54:54 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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:259288 Archived-At: > I was not thinking about that feature, which indeed is much more ambitious, > but about the `minibuffer-scroll-generic' feature you proposed, which would > have solved the issue at hand, and for which you wrote a (partial) patch. Ah you mean the patch where I basically remove the ad-hoc scrolling code from resize_mini_window? Eli doesn't like it, so it would have to be activated by a config variable (and deactivated by default). I'm using it in my local Emacs (see patch below) and have been tempted to add it to master (under the control of a boolean config variable), but its effect is so minor that I'm not sure it's worth the trouble. If you think you can make use of it, then I can clean it up and push it. > Now I think indeed that just doing what Eli wants is the best way to > move forward. Sounds about right. Stefan diff --git a/src/xdisp.c b/src/xdisp.c index 021c99dec4..d953120e28 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -11814,10 +11814,10 @@ resize_mini_window_1 (void *a1, Lisp_Object exactly) means size the window exactly to the size needed. Otherwise, it's only enlarged until W's buffer is empty. - Set W->start to the right place to begin display. If the whole - contents fit, start at the beginning. Otherwise, start so as - to make the end of the contents appear. This is particularly - important for y-or-n-p, but seems desirable generally. + If the whole contents fit, set W->start at the beginning. + Otherwise, let redisplay do its thing to make sure point is displayed, + so we can control which part is more important by placing point + accordingly. Value is true if the window height has been changed. */ @@ -11839,9 +11839,10 @@ resize_mini_window (struct window *w, bool exact_p) return false; /* By default, start display at the beginning. */ - set_marker_both (w->start, w->contents, - BUF_BEGV (XBUFFER (w->contents)), - BUF_BEGV_BYTE (XBUFFER (w->contents))); + /* bug#43519: Let the redisplay choose the window start! + * set_marker_both (w->start, w->contents, + * BUF_BEGV (XBUFFER (w->contents)), + * BUF_BEGV_BYTE (XBUFFER (w->contents))); */ /* Nil means don't try to resize. */ if ((NILP (Vresize_mini_windows) @@ -11900,27 +11901,18 @@ resize_mini_window (struct window *w, bool exact_p) if (height > max_height) { height = (max_height / unit) * unit; - init_iterator (&it, w, ZV, ZV_BYTE, NULL, DEFAULT_FACE_ID); - move_it_vertically_backward (&it, height - unit); - /* The following move is usually a no-op when the stuff - displayed in the mini-window comes entirely from buffer - text, but it is needed when some of it comes from overlay - strings, especially when there's an after-string at ZV. - This happens with some completion packages, like - icomplete, ido-vertical, etc. With those packages, if we - don't force w->start to be at the beginning of a screen - line, important parts of the stuff in the mini-window, - such as user prompt, will be hidden from view. */ - move_it_by_lines (&it, 0); - start = it.current.pos; - /* Prevent redisplay_window from recentering, and thus from - overriding the window-start point we computed here. */ - w->start_at_line_beg = false; + /* bug#43519: Let the redisplay choose the window start! + * + * init_iterator (&it, w, ZV, ZV_BYTE, NULL, DEFAULT_FACE_ID); + * move_it_vertically_backward (&it, height - unit); + * start = it.current.pos; */ } else - SET_TEXT_POS (start, BEGV, BEGV_BYTE); + { + SET_TEXT_POS (start, BEGV, BEGV_BYTE); - SET_MARKER_FROM_TEXT_POS (w->start, start); + SET_MARKER_FROM_TEXT_POS (w->start, start); + } if (EQ (Vresize_mini_windows, Qgrow_only)) {