From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Josh Newsgroups: gmane.emacs.bugs Subject: bug#9949: 24.0.91; window-width function does not take text-scale-mode-amount into account Date: Fri, 4 Nov 2011 11:30:10 -0700 Message-ID: References: <83r51okwui.fsf@gnu.org> <83ipmzlvu3.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf300fb0b9679bc304b0ece6a5 X-Trace: dough.gmane.org 1320431498 17294 80.91.229.12 (4 Nov 2011 18:31:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 4 Nov 2011 18:31:38 +0000 (UTC) Cc: 9949@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 04 19:31:34 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RMOY9-00063q-DI for geb-bug-gnu-emacs@m.gmane.org; Fri, 04 Nov 2011 19:31:33 +0100 Original-Received: from localhost ([::1]:52075 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMOY8-0005RS-LD for geb-bug-gnu-emacs@m.gmane.org; Fri, 04 Nov 2011 14:31:32 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:50547) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMOY4-0005RC-Cg for bug-gnu-emacs@gnu.org; Fri, 04 Nov 2011 14:31:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RMOY3-0004v2-3n for bug-gnu-emacs@gnu.org; Fri, 04 Nov 2011 14:31:28 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46228) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMOY2-0004uy-PZ for bug-gnu-emacs@gnu.org; Fri, 04 Nov 2011 14:31:26 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RMOaY-0001XY-2X for bug-gnu-emacs@gnu.org; Fri, 04 Nov 2011 14:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Josh Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Nov 2011 18:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9949 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9949-submit@debbugs.gnu.org id=B9949.13204315905858 (code B ref 9949); Fri, 04 Nov 2011 18:34:02 +0000 Original-Received: (at 9949) by debbugs.gnu.org; 4 Nov 2011 18:33:10 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMOZh-0001WQ-Md for submit@debbugs.gnu.org; Fri, 04 Nov 2011 14:33:10 -0400 Original-Received: from mail-gy0-f172.google.com ([209.85.160.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RMOZf-0001WJ-Id for 9949@debbugs.gnu.org; Fri, 04 Nov 2011 14:33:08 -0400 Original-Received: by gye5 with SMTP id 5so2698811gye.3 for <9949@debbugs.gnu.org>; Fri, 04 Nov 2011 11:30:31 -0700 (PDT) Original-Received: by 10.236.75.227 with SMTP id z63mr22285682yhd.46.1320431431162; Fri, 04 Nov 2011 11:30:31 -0700 (PDT) Original-Received: by 10.236.108.11 with HTTP; Fri, 4 Nov 2011 11:30:10 -0700 (PDT) In-Reply-To: <83ipmzlvu3.fsf@gnu.org> X-Google-Sender-Auth: phbAdI9bkiPTlgrQVJbuLwUAWAQ X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 04 Nov 2011 14:34:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:53526 Archived-At: --20cf300fb0b9679bc304b0ece6a5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Nov 4, 2011 at 9:02 AM, Eli Zaretskii wrote: > [Please don't remove debbugs from the CC list.] Oops, sorry. > > > The code shown by the URL you cite should not use window-width. It > > > should instead use posn-at-point after moving to the line end (e.g., > > > with `end-of-visual-line'). > > > > > > > In the common case, lines are shorter than the window width, so after > > moving to end-of-visual-line, posn-at-point would contain the length of > the > > current line and not the window width. I don't see how this approach > could > > work without modifying the buffer. > > I don't really understand what the code on the page you pointed to > wants to do, so perhaps my suggestion was incorrect. An alternative > is what Martin suggested: It's trying to set the ERC fill column such that there will be room to insert a timestamp aligned to the right edge of the window. That code was only an example to show how incorrect window-width can break things. I really want a version of window-width that behaves as I described. > Recipe by courtesy of Johan Bockg=E5rd: > > > > (insert (propertize > > " " 'display > > '(space :align-to (- text 8))) "#123456") > > > > (defun scaled-window-width () > > (destructuring-bind (left top right bottom) (window-inside-pixel-edge= s) > > (/ (- right left) (face-pixel-width)))) > > > > Unfortunately, I could not find anything like face-pixel-width. Is thi= s > > information exposed somehow or could it be made so? > > You could move point by 1 character and subtract pixel coordinates > returned by posn-at-point. I'd prefer to avoid the save-excursion-and-move-point dance so I could avoid checking conditions like being at start or end of buffer, whether forward-char actually moved horizontally or did it go to the next line, etc. This approach also wouldn't work in buffers that were empty, for example in a find-file-hook on a new file, because we can't move the point without modifying the buffer. It would be much simpler and more reliable to expose faces' pixel widths. > > For someone to be able to implement these new functions, you (or > > > someone else) should come up with a specification of what they should > > > return in the presence of different faces in the window. E.g., shoul= d > > > the function that returns the line's width return values for a > > > specific line, rather than for a window as a whole? should it count > > > characters in that line or something else? etc., etc. > > > > > > > Basing the result on the width of the face at point seems reasonable, > with > > a caveat in the docstring about windows having faces of different width= s. > > But given that a line can have characters of different width, even for > the same face (think proportional fonts), what good will this kind of > functionality be? > window-width already returns incorrect results for the exceptions you mentioned. A variant that accounts for text scaling would be correct in all the cases window-width is correct, plus the case where text scaling has been applied to a fixed width font. All that is needed is for someone to expose the pixel width of a face and my scaled-window-width function above will work. --20cf300fb0b9679bc304b0ece6a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Nov 4, 2011 at 9:02 AM, Eli Zaretskii <eliz@gnu.org> wrote:
[Please don't remove debbugs from the CC list.]

Oops, sorry.
=A0
> > The code shown by the URL you cite should not use window-width. = =A0It
> > should instead use posn-at-point after moving to the line end (e.= g.,
> > with `end-of-visual-line').
> >
>
> In the common case, lines are shorter than the window width, so after<= br> > moving to end-of-visual-line, posn-at-point would contain the length o= f the
> current line and not the window width. =A0I don't see how this app= roach could
> work without modifying the buffer.

I don't really understand what the code on the page you pointed t= o
wants to do, so perhaps my suggestion was incorrect. =A0An alternative
is what Martin suggested:

It's trying t= o set the ERC fill column such that there will be room to insert a timestam= p aligned to the right edge of the window. =A0That code was only an example= to show how incorrect window-width can break things. =A0I really want a ve= rsion of window-width that behaves as I described.

> Recipe by courtesy of Johan Bockg=E5rd:
>
> (insert (propertize
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 " " 'display
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 '(space :align-to (- text 8))) "#= 123456")


> (defun scaled-window-width ()
> =A0 (destructuring-bind (left top right bottom) (window-inside-pixel-e= dges)
> =A0 =A0 (/ (- right left) (face-pixel-width))))
>
> Unfortunately, I could not find anything like face-pixel-width. =A0Is = this
> information exposed somehow or could it be made so?

You could move point by 1 character and subtract pixel coordinates returned by posn-at-point.

I'd prefer t= o avoid the save-excursion-and-move-point dance so I could avoid checking c= onditions like being at start or end of buffer, whether forward-char actual= ly moved horizontally or did it go to the next line, etc. =A0This approach = also wouldn't work in buffers that were empty, for example in a find-fi= le-hook on a new file, because we can't move the point without modifyin= g the buffer. =A0It would be much simpler and more reliable to expose faces= ' pixel widths.
=A0
> For someone to be able to implement these new functions, you (or
> > someone else) should come up with a specification of what they sh= ould
> > return in the presence of different faces in the window. =A0E.g.,= should
> > the function that returns the line's width return values for = a
> > specific line, rather than for a window as a whole? =A0should it = count
> > characters in that line or something else? =A0etc., etc.
> >
>
> Basing the result on the width of the face at point seems reasonable, = with
> a caveat in the docstring about windows having faces of different widt= hs.

But given that a line can have characters of different width, even fo= r
the same face (think proportional fonts), what good will this kind of
functionality be?

window-width already returns incorrect results = for the exceptions you mentioned. =A0A variant that accounts for text scali= ng would be correct in all the cases window-width is correct, plus the case= where text scaling has been applied to a fixed width font. =A0All that is = needed is for someone to expose the pixel width of a face and my scaled-win= dow-width function above will work.
--20cf300fb0b9679bc304b0ece6a5--