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: feature/icomplete-vertical Date: Sat, 19 Sep 2020 11:35:14 -0400 Message-ID: References: <20200919015957.prffuac2jke3hp6a@Ergus> <20200919061531.oyjlbdvkbeif5fsg@Ergus> <20200919114359.7kph6xt2gdmah2pp@Ergus> <20200919134202.xg3s6lj7kwgjzeki@Ergus> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16922"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Gregory Heytings , Eli Zaretskii , casouri@gmail.com, emacs-devel@gnu.org To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 19 17:43:17 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 1kJf1B-0004Jn-7Y for ged-emacs-devel@m.gmane-mx.org; Sat, 19 Sep 2020 17:43:17 +0200 Original-Received: from localhost ([::1]:51086 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJf1A-0007l5-73 for ged-emacs-devel@m.gmane-mx.org; Sat, 19 Sep 2020 11:43:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46236) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJetZ-0007vb-RP for emacs-devel@gnu.org; Sat, 19 Sep 2020 11:35:29 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23916) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJetW-0003yU-D2; Sat, 19 Sep 2020 11:35:24 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 6F87610022F; Sat, 19 Sep 2020 11:35:17 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D63E710022A; Sat, 19 Sep 2020 11:35:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1600529715; bh=4shW33toZDkh7lflc07s/kcWqSYzIWSPi0qgHH8Kv9A=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=dkguMejuGQ9fC2MahoDuOeQpOn51CQX72q4NXIagIN8wXoZBzKnYqTHp1JXGjhty1 ev0FlipSXMYNGj0EBMVkDeQpJ0t9EvbLqdS4WyLH3veadq7X+ws/ZzsNj4kYqoMod9 +/Cpgl2xyYTOGQdGFnPXnaflPlfT1d3wvNMoF2qypMQSCaJm2LI/1jw+uTbhatM8gj Mb0PE/Yosk65adX+4ws2QS601tQBylX0wlMMwxaOga18wVQsudd4/hoFgwe5bOO5/w H4pG51Snnvxp/gQZ5WxJB43ffaRuJKSzOKprtWswIH2XM99B+lLhcLfQt4EYrRRNJn 5di2QZxu/tZcA== Original-Received: from alfajor (unknown [45.72.232.131]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9AB0D120376; Sat, 19 Sep 2020 11:35:15 -0400 (EDT) In-Reply-To: <20200919134202.xg3s6lj7kwgjzeki@Ergus> (Ergus's message of "Sat, 19 Sep 2020 15:42:02 +0200") 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/09/19 11:35:17 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:256183 Archived-At: > That's why I work with pixels. Yes, that's fine. > Because we can get the height of every added line and do a better > estimation... but we need to add the text properties before the > increment... which is a different topic because ATM this is > not happening. You don't want to go there. You end up having to reimplement the job done by the redisplay. Instead, just output "a bit more" than necessary, and then ask the redisplay code whether it fits (so you reuse the redisplay code instead of reimplementing it). >>Using 1 instead of (cl-count ?\n icomplete--separator) will err on the >>side of putting too many rather than too few candidates, which should >>have as sole negative impact a negligible performance hit. > I actually added the cl-count for the opposite reason; in case the user > adds a separator with more than one \n. That's not the opposite reason, that's the case I had in mind. By using 1 instead of (cl-count ?\n icomplete--separator) you'll be over-estimating (by the factor that would have been returned by `cl-count`) the number of candidates that can fit when (cl-count ?\n icomplete--separator) is greater than 1. > So we need to add the exact amount of lines as accurate as possible. I *strongly* recommend you design the behavior under the assumption that it's OK if there are a few more lines in the (mini)buffer than are actually visible. Stefan