From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: `fit-window-to-buffer-as-displayed'? Date: Tue, 11 Jan 2011 09:47:34 -0800 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1294768277 10521 80.91.229.12 (11 Jan 2011 17:51:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 11 Jan 2011 17:51:17 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 11 18:51:12 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PciNE-0007c2-1P for ged-emacs-devel@m.gmane.org; Tue, 11 Jan 2011 18:51:12 +0100 Original-Received: from localhost ([127.0.0.1]:55795 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PciND-0002k6-EO for ged-emacs-devel@m.gmane.org; Tue, 11 Jan 2011 12:51:11 -0500 Original-Received: from [140.186.70.92] (port=40206 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PciLf-0007dU-Pn for emacs-devel@gnu.org; Tue, 11 Jan 2011 12:51:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PciJt-0007tM-Kp for emacs-devel@gnu.org; Tue, 11 Jan 2011 12:49:35 -0500 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:52009) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PciJt-0007tE-EZ for emacs-devel@gnu.org; Tue, 11 Jan 2011 12:47:45 -0500 Original-Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0BHlg4a015148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Jan 2011 17:47:43 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0BEuBEU004458; Tue, 11 Jan 2011 17:47:40 GMT Original-Received: from abhmt010.oracle.com by acsmt353.oracle.com with ESMTP id 949955811294768055; Tue, 11 Jan 2011 09:47:35 -0800 Original-Received: from dradamslap1 (/10.159.216.144) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 Jan 2011 09:47:34 -0800 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcuxULRDmJ829/KlQE2h2Rr6RRtpNAAYzQHAAADl3uA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:134449 Archived-At: > >> At the time fit-window-to-buffer-as-displayed is called, the > >> text might not be completely displayed yet. > > > > Well obviously one would call > > `fit-window-to-buffer-as-displayed' only after > > (one knew that) it was displayed. ;-) > > And how do you know and/or make sure it's *completely* displayed? You might not be able to know for sure - hence the smily. But likely you would not want to call it before you added `display' properties etc. that you wanted to be taken into account for the fitting. Of course calling it after such code has finished is still no guarantee. You can try forcing redisplay, but in many cases that won't be necessary. The point is that calls to fit the window to what is displayed would intentionally be made after the buffer has been displayed in all its glory. Whether that intention is realized in all cases is another story. > > And if it were called when not displayed then, in that > > situation, we could either have it be a no-op or have it > > do what `fit-window-to-buffer' does now. > > But fit-window-to-buffer doesn't work right in many cases, so > that'd not be a complete solution. Any bugs should be fixed, of course. By "what it does now" I was referring to the current intended behavior of taking into account screen lines, not text lines. > > I think there can be use cases for its current behavior. And use > > cases for just fitting to the buffer text, ignoring all display > > considerations (treating it as plain, fixed-width text, no more). > > Maybe there can be, but I can't think of any of them, so I > think they'd be very far fetched and insignificant. > > > I probably have nothing to offer wrt the implementation. I do think > > though that this is bound to be somewhat complex and success is likely > > to be partial and conditional (works for some display artifacts in > > some situations, but is not perfect). There are a lot of different > > things one can do with display, even just counting the `display' > > text/overlay property. (And note that some of them take place beyond > > buffer positions, so tests involving (point) won't necessarily cut > > the mustard.) > > There's no point trying to add support for some properties > but not all: adding support for all properties is likely to be easier > because it'd rely on (re)using the existing display code. I agree with the attempt. I was only suggesting that the job might not be simple. You mentioned checking `posn-point' in a loop. I pointed out that some display happens outside of any positions that point can assume - outside of the buffer text altogether (e.g. margins). Anyway, making `fit-window-to-buffer' take display artifacts into account would be an improvement. If you want to have it always take all such into account (i.e. not let programmers pick & choose), that's still a fine improvement. Let's please do it.