bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Titus von der Malsburg]

- emacs -Q
- (set-fringe-mode '(0 . 2))
  The left fringe has to be zero, the right fringe doesn't seem to matter.
- Fill a line completely with n characters such that it doesn't break.
- (window-width) reports n+1 characters instead of n.

This bug is potentially related to this one: https://lists.gnu.org/archive/html/bug-gnu-emacs/2014-10/msg00061.html



In GNU Emacs 25.0.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2014-12-13 on montana
Repository revision: 49daed60510a073062b41fa39fd7c010cb0a315e
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04.1 LTS

Configured using:
 `configure --prefix=/home/malsburg/usr/
 PKG_CONFIG_PATH=/usr/local/X11R6.8/lib/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS NOTIFY
GNUTLS LIBXML2 FREETYPE XFT ZLIB

Important settings:
  value of $LC_MONETARY: en_GB.UTF-8
  value of $LC_NUMERIC: en_GB.UTF-8
  value of $LC_TIME: en_GB.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
scroll-up-command: End of buffer
ESC <mouse-1> is undefined
Mark set [7 times]
((left-fringe . 0) (right-fringe . 2))
50 (#o62, #x32, ?2)

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util help-fns mail-prsvr mail-utils mule-util time-date
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
gfilenotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 77284 9243)
 (symbols 48 18162 1)
 (miscs 40 53 174)
 (strings 32 11417 4672)
 (string-bytes 1 307454)
 (vectors 16 10084)
 (vector-slots 8 394429 11468)
 (floats 8 73 226)
 (intervals 56 215 0)
 (buffers 976 11)
 (heap 1024 31835 1054))

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> From: Titus von der Malsburg <malsburg@posteo.de>
> Date: Tue, 16 Dec 2014 12:01:45 -0800
> 
> 
> - emacs -Q
> - (set-fringe-mode '(0 . 2))
>   The left fringe has to be zero, the right fringe doesn't seem to matter.
> - Fill a line completely with n characters such that it doesn't break.
> - (window-width) reports n+1 characters instead of n.

The n+1st character is usurped for the continuation glyph.  This is
not a bug.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Titus von der Malsburg]

[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]


On 2014-12-16 Tue 12:09, Eli Zaretskii wrote:
>> From: Titus von der Malsburg <malsburg@posteo.de>
>> Date: Tue, 16 Dec 2014 12:01:45 -0800
>> 
>> 
>> - emacs -Q
>> - (set-fringe-mode '(0 . 2))
>>   The left fringe has to be zero, the right fringe doesn't seem to matter.
>> - Fill a line completely with n characters such that it doesn't break.
>> - (window-width) reports n+1 characters instead of n.
>
> The n+1st character is usurped for the continuation glyph.  This is
> not a bug.

Sorry, but I don't understand that.  If (window-width) says there is
space for 50 characters and I put 50 characters on a line, there
shouldn't be a continuation character in the first place.  Also, I don't
see why I should get different behaviour for different values of
left-fringe.  When left-fringe is > 0, I get as many characters on a
line as (window-width) reports.  But if left-fringe is 0, I get one
character less on the line.  This behaviour doesn't seem to be
consistent with the documentation of window-width.  Quote:

  The return value does not include any vertical dividers, fringes or
  marginal areas, or scroll bars.

My understanding of this is that the fringes should not matter at
all.  If window-with reports n, I should be able to fit n characters on
a line irrespective of what the fringes are.  Moreover, why is this
specific to the left-fringe?  The value of right-fringe does not affect
influence whether I can get (window-width) or (window-width) -1
characters on a line.

  Titus

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> From: Titus von der Malsburg <malsburg@posteo.de>
> Cc: 19395@debbugs.gnu.org
> Date: Tue, 16 Dec 2014 12:36:13 -0800
> 
> > The n+1st character is usurped for the continuation glyph.  This is
> > not a bug.
> 
> Sorry, but I don't understand that.  If (window-width) says there is
> space for 50 characters and I put 50 characters on a line, there
> shouldn't be a continuation character in the first place.

window-width doesn't report the number of characters a window's line
can hold without continuation.  It reports the window width in
character units.  When there's no fringe to display the continuation
bitmap, that width includes the space reserved for the continuation
glyph, which is the backslash character produced by the display engine
on the last column of the line.

> Also, I don't see why I should get different behaviour for different
> values of left-fringe.  When left-fringe is > 0, I get as many
> characters on a line as (window-width) reports.  But if left-fringe
> is 0, I get one character less on the line.

As long as the left fringe exists, we can display on it.  But once its
width is zero, it no longer exists, and so we need to reserve space to
display the continuation glyph "by other means".

> This behaviour doesn't seem to be consistent with the documentation
> of window-width.  Quote:
> 
>   The return value does not include any vertical dividers, fringes or
>   marginal areas, or scroll bars.

This doesn't say anything about continuation and truncation glyphs, so
I see no inconsistency here, perhaps just missing details.

> My understanding of this is that the fringes should not matter at
> all.  If window-with reports n, I should be able to fit n characters on
> a line irrespective of what the fringes are.

I tried to explain above why this interpretation is incorrect:
window-width does not return the number of characters of buffer text
that can be displayed on a line.

> Moreover, why is this specific to the left-fringe?  The value of
> right-fringe does not affect influence whether I can get
> (window-width) or (window-width) -1 characters on a line.

That's not what I see here.  Setting any of the fringes' width to zero
causes window-width to report 1 more character than you can put on a
line without going to a continuation line.  IOW, the "penalty" is
symmetrical, at least on my machine.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Stefan Monnier]

> As long as the left fringe exists, we can display on it.  But once its
> width is zero, it no longer exists, and so we need to reserve space to
> display the continuation glyph "by other means".

That sounds wrong: if the user decides to get rid of the left-fringe,
she just shouldn't get any continuation glyph on the left.


        Stefan

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Titus von der Malsburg]

On 2014-12-16 Tue 12:58, Eli Zaretskii wrote:
>> From: Titus von der Malsburg <malsburg@posteo.de>
>> Cc: 19395@debbugs.gnu.org
>> Date: Tue, 16 Dec 2014 12:36:13 -0800
>> 
>> > The n+1st character is usurped for the continuation glyph.  This is
>> > not a bug.
>> 
>> Sorry, but I don't understand that.  If (window-width) says there is
>> space for 50 characters and I put 50 characters on a line, there
>> shouldn't be a continuation character in the first place.
>
> window-width doesn't report the number of characters a window's line
> can hold without continuation.  It reports the window width in
> character units.  When there's no fringe to display the continuation
> bitmap, that width includes the space reserved for the continuation
> glyph, which is the backslash character produced by the display engine
> on the last column of the line.
>
>> Also, I don't see why I should get different behaviour for different
>> values of left-fringe.  When left-fringe is > 0, I get as many
>> characters on a line as (window-width) reports.  But if left-fringe
>> is 0, I get one character less on the line.
>
> As long as the left fringe exists, we can display on it.  But once its
> width is zero, it no longer exists, and so we need to reserve space to
> display the continuation glyph "by other means".

I see, thanks for explaining.  Perhaps it would make sense to amend the
documentation of `window-width' because this is easy to misunderstand
and I suspect that I'm not the only one who consults window-width in
order to determine how much columns are available for text display.  In
term.el, I found a function that does what I want (`term-window-width')
but requiring term.el only to use this function seems
inappropriate.  Duplicating this function is not perfect either.

  Titus

>> This behaviour doesn't seem to be consistent with the documentation
>> of window-width.  Quote:
>> 
>>   The return value does not include any vertical dividers, fringes or
>>   marginal areas, or scroll bars.
>
> This doesn't say anything about continuation and truncation glyphs, so
> I see no inconsistency here, perhaps just missing details.
>
>> My understanding of this is that the fringes should not matter at
>> all.  If window-with reports n, I should be able to fit n characters on
>> a line irrespective of what the fringes are.
>
> I tried to explain above why this interpretation is incorrect:
> window-width does not return the number of characters of buffer text
> that can be displayed on a line.
>
>> Moreover, why is this specific to the left-fringe?  The value of
>> right-fringe does not affect influence whether I can get
>> (window-width) or (window-width) -1 characters on a line.
>
> That's not what I see here.  Setting any of the fringes' width to zero
> causes window-width to report 1 more character than you can put on a
> line without going to a continuation line.  IOW, the "penalty" is
> symmetrical, at least on my machine.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Titus von der Malsburg <malsburg@posteo.de>,  19395@debbugs.gnu.org
> Date: Tue, 16 Dec 2014 18:12:51 -0500
> 
> > As long as the left fringe exists, we can display on it.  But once its
> > width is zero, it no longer exists, and so we need to reserve space to
> > display the continuation glyph "by other means".
> 
> That sounds wrong: if the user decides to get rid of the left-fringe,
> she just shouldn't get any continuation glyph on the left.

That's how Emacs worked since v21.1.  But then users asked to have
continuation and truncation glyphs in that case, and we introduced
this feature a few versions ago.

So what you are suggesting is going back and deleting a feature which
was added by users' request.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Titus von der Malsburg]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]


On 2014-12-16 Tue 15:12, Stefan Monnier wrote:
>> As long as the left fringe exists, we can display on it.  But once its
>> width is zero, it no longer exists, and so we need to reserve space to
>> display the continuation glyph "by other means".
>
> That sounds wrong: if the user decides to get rid of the left-fringe,
> she just shouldn't get any continuation glyph on the left.

Strange, setting left-fringe to 0 apparently reserves a column for the
continuation character even when the right fringe is non-zero and no
such column is needed.  Just tested it.

  Titus


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Stefan Monnier]

>> That sounds wrong: if the user decides to get rid of the left-fringe,
>> she just shouldn't get any continuation glyph on the left.
> That's how Emacs worked since v21.1.

Definitely not 21.1: in 21.1 the fringes could not be modified at all.

> But then users asked to have continuation and truncation glyphs in
> that case,

I do remember users clamoring for the possibility to eliminate the
fringes, which was indeed added (in the form of set-window-fringes)
a few versions later (not sure exactly when, but >= 22.1 and <= 22.3).

I don't remember users asking for "no fringe, but still something where we
can display the continuation glyphs" (and since the fringe is the thing
where we display the continuation glyphs, I read this as "no fringe, yet
with a fringe").

This said, I wouldn't be surprised if some users asked for that.

> So what you are suggesting is going back and deleting a feature which
> was added by users' request.

Not necessarily: I'm suggesting that maybe the Emacs-22 behavior where
"continuation glyphs" are only ever displayed in the fringe (and hence
aren't displayed if there's no fringe) is preferable.

Note also that in the OP's situation, there *is* a fringe on the right,
so I don't see why we need to keep an extra empty space on the right
since we'll never display a continuation glyph on the right elsewhere
than in the fringe.


        Stefan

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> From: Titus von der Malsburg <malsburg@posteo.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, 19395@debbugs.gnu.org
> Date: Tue, 16 Dec 2014 19:46:52 -0800
> 
> On 2014-12-16 Tue 15:12, Stefan Monnier wrote:
> >> As long as the left fringe exists, we can display on it.  But once its
> >> width is zero, it no longer exists, and so we need to reserve space to
> >> display the continuation glyph "by other means".
> >
> > That sounds wrong: if the user decides to get rid of the left-fringe,
> > she just shouldn't get any continuation glyph on the left.
> 
> Strange, setting left-fringe to 0 apparently reserves a column for the
> continuation character even when the right fringe is non-zero and no
> such column is needed.

You are thinking only about left-to-right lines of text.  But Emacs
also supports right-to-left lines of text, which use the left fringe
to display the continuation bitmap.  Those right-to-left lines need
the extra column for the continuation glyph when the left fringe is
not available.

And because Emacs supports mixed directions of text lines in the same
buffer, and because the line geometry needs to be symmetrical in both
cases, we reserve one column in left-to-right lines as well, even
though the right fringe is available (and so that column will be left
unused, i.e. empty, in left-to-right lines).

This all is so, when neither the left nor the right fringe are
available, we display mixed-direction lines like this (where "|"
denotes the window edge):

  |left-to-right continued line\|
  |/RIGHT-TO-LEFT CONTINUED LINE|

IOW, no matter what the direction, the text always begins at the
window edge, and its last (in logical order) column is used for the
continuation glyph.

When the right fringe is available, but the left one isn't, you will
see this instead (with "⤶" standing for the fringe bitmap:

  |left-to-right continued line |⤶
  |/RIGHT-TO-LEFT CONTINUED LINE|

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> From: Titus von der Malsburg <malsburg@posteo.de>
> Cc: 19395@debbugs.gnu.org
> Date: Tue, 16 Dec 2014 19:28:45 -0800
> 
> I see, thanks for explaining.  Perhaps it would make sense to amend the
> documentation of `window-width' because this is easy to misunderstand

Will do.

> In term.el, I found a function that does what I want
> (`term-window-width') but requiring term.el only to use this
> function seems inappropriate.  Duplicating this function is not
> perfect either.

That function is in term.el because term.el is its only user.  We
might consider moving it to a more general place, but please describe
the use case where you needed it.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: malsburg@posteo.de,  19395@debbugs.gnu.org
> Date: Wed, 17 Dec 2014 09:16:04 -0500
> 
> >> That sounds wrong: if the user decides to get rid of the left-fringe,
> >> she just shouldn't get any continuation glyph on the left.
> > That's how Emacs worked since v21.1.
> 
> Definitely not 21.1: in 21.1 the fringes could not be modified at all.

But they were the only way to show truncation and continuation
indicators on GUI frames.

> > But then users asked to have continuation and truncation glyphs in
> > that case,
> 
> I do remember users clamoring for the possibility to eliminate the
> fringes, which was indeed added (in the form of set-window-fringes)
> a few versions later (not sure exactly when, but >= 22.1 and <= 22.3).
> 
> I don't remember users asking for "no fringe, but still something where we
> can display the continuation glyphs" (and since the fringe is the thing
> where we display the continuation glyphs, I read this as "no fringe, yet
> with a fringe").
> 
> This said, I wouldn't be surprised if some users asked for that.

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11832

> > So what you are suggesting is going back and deleting a feature which
> > was added by users' request.
> 
> Not necessarily: I'm suggesting that maybe the Emacs-22 behavior where
> "continuation glyphs" are only ever displayed in the fringe (and hence
> aren't displayed if there's no fringe) is preferable.

As you can see from the above URL, that was an explicit feature
request, in response to which we provided the feature.  So going back
to Emacs 23 behavior is tantamount to removing the feature.

> Note also that in the OP's situation, there *is* a fringe on the right,
> so I don't see why we need to keep an extra empty space on the right
> since we'll never display a continuation glyph on the right elsewhere
> than in the fringe.

Because of RTL lines.  I explained that in more detail in my other
message.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Titus von der Malsburg]

[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]


On 2014-12-17 Wed 07:32, Eli Zaretskii wrote:
>> In term.el, I found a function that does what I want
>> (`term-window-width') but requiring term.el only to use this
>> function seems inappropriate.  Duplicating this function is not
>> perfect either.
>
> That function is in term.el because term.el is its only user.  We
> might consider moving it to a more general place, but please describe
> the use case where you needed it.

I'm the author of a number of extensions for Helm (helm-bibtex,
helm-dictionary, helm-mu).  These extensions display the results of a
search in the form of tables.  See here for an example:

  https://github.com/tmalsburg/helm-bibtex/raw/master/screenshot.png

I want to use the full number of available columns for displaying data
but avoid line breaks at all cost because they would mess up the table
layout.  That's why I need a robust way to determine the maximal number
of characters that I can put on a line.  `term-window-width' is better
at doing that then `window-width' because it corrects (window-width) in
a number of special cases.  (It's not perfect, though, because like
`window-width' it ignores the size of the font in the window and
pretends the window is using the default size.)

  Titus

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> From: Titus von der Malsburg <malsburg@posteo.de>
> Cc: 19395@debbugs.gnu.org
> Date: Wed, 17 Dec 2014 09:18:34 -0800
> 
> I want to use the full number of available columns for displaying data
> but avoid line breaks at all cost because they would mess up the table
> layout.  That's why I need a robust way to determine the maximal number
> of characters that I can put on a line.  `term-window-width' is better
> at doing that then `window-width' because it corrects (window-width) in
> a number of special cases.  (It's not perfect, though, because like
> `window-width' it ignores the size of the font in the window and
> pretends the window is using the default size.)

Exactly.  So perhaps we need a different function, one that returns
exactly the result that you want here.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Titus von der Malsburg]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]


On 2014-12-17 Wed 10:21, Eli Zaretskii wrote:
>> From: Titus von der Malsburg <malsburg@posteo.de>
>> Cc: 19395@debbugs.gnu.org
>> Date: Wed, 17 Dec 2014 09:18:34 -0800
>> 
>> I want to use the full number of available columns for displaying data
>> but avoid line breaks at all cost because they would mess up the table
>> layout.  That's why I need a robust way to determine the maximal number
>> of characters that I can put on a line.  `term-window-width' is better
>> at doing that then `window-width' because it corrects (window-width) in
>> a number of special cases.  (It's not perfect, though, because like
>> `window-width' it ignores the size of the font in the window and
>> pretends the window is using the default size.)
>
> Exactly.  So perhaps we need a different function, one that returns
> exactly the result that you want here.

The problem is that there may not be a clean solution to that
problem.  A buffer can contain text is several font sizes and as far as
I know there is no notion of a default size for a buffer, or is there?
In my special case, I have the font size under control and
`term-window-width' would be good enough.

  Titus


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> From: Titus von der Malsburg <malsburg@posteo.de>
> Cc: 19395@debbugs.gnu.org
> Date: Wed, 17 Dec 2014 10:48:25 -0800
> 
> The problem is that there may not be a clean solution to that
> problem.  A buffer can contain text is several font sizes and as far as
> I know there is no notion of a default size for a buffer, or is there?

Yes, there is: the 'default' face.

> In my special case, I have the font size under control and
> `term-window-width' would be good enough.

But if we want this function to be more generally useful, it
shouldn't be limited to the frame's canonical character size, and
should at least take the face-remapping into account.  Bonus points
for accepting a face as an argument and using that face's font
dimensions.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Stefan Monnier]

>   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11832

Note that this was a request from Drew who didn't even understand that
the "$" signs used up just as much space as the fringe would.

IOW a typical "I don't understand what I say, but I want my old teddy
bear back".

So, it doesn't seem to be a request of terribly high importance.

> As you can see from the above URL, that was an explicit feature
> request, in response to which we provided the feature.

..and removed the previous feature of letting users decide to have no
fringe at all (neither of the regular "graphical" kind, nor of the
"old-style tty" kind).


        Stefan

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Stefan Monnier]

>   |left-to-right continued line\|
>   |/RIGHT-TO-LEFT CONTINUED LINE|

OK, makes sense.

>   |left-to-right continued line |⤶
>   |/RIGHT-TO-LEFT CONTINUED LINE|

Why do you need the empty space at the end of the left-to-right line?
The glyph in the right fringe already gives the corresponding
information about whether the line starts on the left or on the
right, AFAICT.


        Stefan

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Drew Adams]

> >   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11832
> 
> Note that this was a request from Drew who didn't even understand
> that the "$" signs used up just as much space as the fringe would.

Oooooh.  "Drew didn't even understand THAT"?!  You never miss an
opportunity, do you?  Try to see if you can convince people by
throwing in an ad hominem aspersion or two...

> IOW a typical "I don't understand what I say, but I want my old
> teddy bear back".

I guess we can see whose behavior is typical here.  A typical
bleating of "This doesn't count because it was reported by Drew!"

> So, it doesn't seem to be a request of terribly high importance.

Because it is from Drew.  Of course.  That follows.

Maybe some will read that bug thread for themselves and decide.
Maybe not.

I will repeat only this:

  Let me be clear BTW about my motivation: I use Emacs with fringes
  turned off.  And I use it with line truncation turned off (although
  it gets turned on automatically in contexts such as the debugger).

  I am not asking for a fix to this bug for myself but for Emacs.

  I simply recognize that something was lost for users in moving to
  Emacs 21.  It seems wrong that users who choose not to show fringe
  have no way of knowing which lines are truncated.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

So much for this all being about ignorant, crybaby Drew just wanting
to have his teddy bear back.  Drew has little use for this teddy,
and he made that clear from the outset.

"No way of knowing which lines are truncated."  Did Drew know what
he was talking about there, or not?  You have only to compare Emacs
22 and Emacs 24 with fringe turned off and `truncate-lines' turned on.

That was the bug that Drew reported.  And the bug that Eli fixed.
The report simply asked to let users who choose to not show fringe be
able to tell which lines are truncated.  They had that ability before
the bug (regression).  And they had it again after Eli fixed it.

If you want to take that teddy bear away from non-Drew users then
no one will stop you.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Titus von der Malsburg]

[-- Attachment #1: Type: text/plain, Size: 2702 bytes --]


On 2014-12-17 Wed 11:09, Eli Zaretskii wrote:
>> From: Titus von der Malsburg <malsburg@posteo.de>
>> Cc: 19395@debbugs.gnu.org
>> Date: Wed, 17 Dec 2014 10:48:25 -0800
>> 
>> The problem is that there may not be a clean solution to that
>> problem.  A buffer can contain text is several font sizes and as far as
>> I know there is no notion of a default size for a buffer, or is there?
>
> Yes, there is: the 'default' face.
>
>> In my special case, I have the font size under control and
>> `term-window-width' would be good enough.
>
> But if we want this function to be more generally useful, it
> shouldn't be limited to the frame's canonical character size, and
> should at least take the face-remapping into account.  Bonus points
> for accepting a face as an argument and using that face's font
> dimensions.

This is more difficult than I thought.  Below is a first sketch.  Let me
know if you think this is going in the right direction and I'll polish
it and add the bonus feature.

It appears that a font has to be rendered before Emacs can tell how wide
a character is.  That's why we need the temporary buffer.  Not elegant,
but I couldn't find a better way.  `default-font-width' complements
`default-font-height' in simple.el.  The other function would go into
window.el.

  Titus

(defun default-font-width () 
  "Return the width in pixels of the current buffer's default
face font.  More precisely, this returns the width of the letter
‘m’.  If the font is mono-spaced, this will also be the width of
all other printable characters."
  (let ((window (selected-window))
        (remapping face-remapping-alist))
    (with-temp-buffer
      (make-local-variable 'face-remapping-alist)
      (setq face-remapping-alist remapping)
      (set-window-buffer window (current-buffer))
      (insert "m")
      (aref (aref (font-get-glyphs (font-at 1) 1 2) 0) 4))))

(defun window-available-columns ()
  "Return the maximal number of characters that can be displayed
on one line.  This function is different from `window-body-width'
in that it accounts for fringes (when at least one fringe has
zero width, one column is reserved for continuation characters)
and for the size of the default font (which may have been
adjusted using, e.g., `text-scale-increase')."
  (let* ((window-width (window-body-width nil t))
	 (font-width (default-font-width))
	 (ncols (/ window-width font-width)))
    (if (and (not (featurep 'xemacs))
	     (display-graphic-p)
	     overflow-newline-into-fringe
	     (/= (frame-parameter nil 'left-fringe) 0)
	     (/= (frame-parameter nil 'right-fringe) 0))
        ncols
      (1- (ncols)))))


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: malsburg@posteo.de,  19395@debbugs.gnu.org
> Date: Wed, 17 Dec 2014 16:31:20 -0500
> 
> So, it doesn't seem to be a request of terribly high importance.

But it's already done.

> > As you can see from the above URL, that was an explicit feature
> > request, in response to which we provided the feature.
> 
> ..and removed the previous feature of letting users decide to have no
> fringe at all (neither of the regular "graphical" kind, nor of the
> "old-style tty" kind).

They can still have it if they give up 1 pixel for each fringe they
want to disable.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Titus von der Malsburg <malsburg@posteo.de>,  19395@debbugs.gnu.org
> Date: Wed, 17 Dec 2014 16:34:41 -0500
> 
> >   |left-to-right continued line |⤶
> >   |/RIGHT-TO-LEFT CONTINUED LINE|
> 
> Why do you need the empty space at the end of the left-to-right line?

Because that empty space simply doesn't exist in the display line's
geometry, as far as the display engine is concerned.  Most of the
display engine is oblivious to the fact that an RTL line is reversed
on display, so it cannot do its job if some lines are longer than
others.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Stefan Monnier]

>> So, it doesn't seem to be a request of terribly high importance.
> But it's already done.

Yes, but your argument for not providing the "no fringe" behavior is
that it would go against this request, so I'm pointing out that this is
not a good enough reason.

Most of the non-Emacs editors I see (e.g. vi in a tty, or the god-awful
edit-boxes in Iceweasel) don't have anything like fringes or other forms
of continuation glyphs (IOW, there's simply no visual indication at all
distinguishing a line-wrap from a newline), so it would make sense for
Emacs to be able to provide this behavior somehow.


        Stefan

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Stefan Monnier]

>> >   |left-to-right continued line |⤶
>> >   |/RIGHT-TO-LEFT CONTINUED LINE|
>> Why do you need the empty space at the end of the left-to-right line?
> Because that empty space simply doesn't exist in the display line's
> geometry, as far as the display engine is concerned.  Most of the
> display engine is oblivious to the fact that an RTL line is reversed
> on display, so it cannot do its job if some lines are longer than
> others.

IOW, it's because it makes the implementation easier.  OK, that's
a good reason.


        Stefan

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: malsburg@posteo.de,  19395@debbugs.gnu.org
> Date: Thu, 18 Dec 2014 09:24:05 -0500
> 
> >> So, it doesn't seem to be a request of terribly high importance.
> > But it's already done.
> 
> Yes, but your argument for not providing the "no fringe" behavior is
> that it would go against this request, so I'm pointing out that this is
> not a good enough reason.

If someone wants to submit (an almost trivial) patch to add an option
that would remove the continuation/truncation glyphs when there are no
fringes, please go ahead.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: malsburg@posteo.de,  19395@debbugs.gnu.org
> Date: Thu, 18 Dec 2014 09:25:33 -0500
> 
> >> >   |left-to-right continued line |⤶
> >> >   |/RIGHT-TO-LEFT CONTINUED LINE|
> >> Why do you need the empty space at the end of the left-to-right line?
> > Because that empty space simply doesn't exist in the display line's
> > geometry, as far as the display engine is concerned.  Most of the
> > display engine is oblivious to the fact that an RTL line is reversed
> > on display, so it cannot do its job if some lines are longer than
> > others.
> 
> IOW, it's because it makes the implementation easier.

No, it makes it possible.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> From: Titus von der Malsburg <malsburg@posteo.de>
> Cc: 19395@debbugs.gnu.org
> Date: Wed, 17 Dec 2014 19:36:04 -0800
> 
> > But if we want this function to be more generally useful, it
> > shouldn't be limited to the frame's canonical character size, and
> > should at least take the face-remapping into account.  Bonus points
> > for accepting a face as an argument and using that face's font
> > dimensions.
> 
> This is more difficult than I thought.  Below is a first sketch.  Let me
> know if you think this is going in the right direction and I'll polish
> it and add the bonus feature.
> 
> It appears that a font has to be rendered before Emacs can tell how wide
> a character is.  That's why we need the temporary buffer.  Not elegant,
> but I couldn't find a better way.  `default-font-width' complements
> `default-font-height' in simple.el.  The other function would go into
> window.el.

Given the changes I pushed in commit b197822, you will no longer need
all this complexity.  Just

   (aref (font-info (face-font 'default)) 11)

(For bullet-proof code, check that this is not zero, and if it is, use
the 10th member instead; see the docs.)

> (defun window-available-columns ()
>   "Return the maximal number of characters that can be displayed
> on one line.  This function is different from `window-body-width'
> in that it accounts for fringes (when at least one fringe has
> zero width, one column is reserved for continuation characters)
> and for the size of the default font (which may have been
> adjusted using, e.g., `text-scale-increase')."
>   (let* ((window-width (window-body-width nil t))
> 	 (font-width (default-font-width))
> 	 (ncols (/ window-width font-width)))
>     (if (and (not (featurep 'xemacs))
> 	     (display-graphic-p)
> 	     overflow-newline-into-fringe
> 	     (/= (frame-parameter nil 'left-fringe) 0)
> 	     (/= (frame-parameter nil 'right-fringe) 0))
>         ncols
>       (1- (ncols)))))

If we are going to put this in simple.el or subr.el, I don't think we
need to worry about XEmacs.

Thanks.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> From: Titus von der Malsburg <malsburg@posteo.de>
> Cc: 19395@debbugs.gnu.org
> Date: Tue, 16 Dec 2014 19:28:45 -0800
> 
> I see, thanks for explaining.  Perhaps it would make sense to amend the
> documentation of `window-width' because this is easy to misunderstand
> and I suspect that I'm not the only one who consults window-width in
> order to determine how much columns are available for text display.

Done.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[martin rudalics]

 > Given the changes I pushed in commit b197822, you will no longer need
 > all this complexity.  Just
 >
 >     (aref (font-info (face-font 'default)) 11)
 >
 > (For bullet-proof code, check that this is not zero, and if it is, use
 > the 10th member instead; see the docs.)

Very good.  IIUC this means that I could use something like

(defun window-char-width (&optional window)
   "Return default character width for WINDOW.
WINDOW must be a live window and defaults to the selected one."
   (setq window (window-normalize-window window t))
   (with-current-buffer (window-buffer window)
     (let* ((info (font-info (face-font 'default)))
	   (width (aref info 11)))
       (if (> width 0)
	  width
	(aref info 10)))))

(defun window-char-height (&optional window)
   "Return default character height for WINDOW.
WINDOW must be a live window and defaults to the selected one."
   (setq window (window-normalize-window window t))
   (with-current-buffer (window-buffer window)
     (aref (font-info (face-font 'default)) 3)))

in window.el.  If that is the case, then the doc of `font-info' should
be somehow amended.  It currently says

Return information about a font named NAME on frame FRAME.

and nowhere mentions which buffer must be current or maybe even which
window must be selected.  I'm a bit too lazy to look into this myself.

Thanks a lot for this, martin

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> Date: Fri, 19 Dec 2014 18:09:31 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 19395@debbugs.gnu.org
> 
>  > Given the changes I pushed in commit b197822, you will no longer need
>  > all this complexity.  Just
>  >
>  >     (aref (font-info (face-font 'default)) 11)
>  >
>  > (For bullet-proof code, check that this is not zero, and if it is, use
>  > the 10th member instead; see the docs.)
> 
> Very good.  IIUC this means that I could use something like
> 
> (defun window-char-width (&optional window)
>    "Return default character width for WINDOW.
> WINDOW must be a live window and defaults to the selected one."
>    (setq window (window-normalize-window window t))
>    (with-current-buffer (window-buffer window)
>      (let* ((info (font-info (face-font 'default)))
> 	   (width (aref info 11)))
>        (if (> width 0)
> 	  width
> 	(aref info 10)))))
> 
> (defun window-char-height (&optional window)
>    "Return default character height for WINDOW.
> WINDOW must be a live window and defaults to the selected one."
>    (setq window (window-normalize-window window t))
>    (with-current-buffer (window-buffer window)
>      (aref (font-info (face-font 'default)) 3)))
> 
> in window.el.

Yes, that's the idea.

> If that is the case, then the doc of `font-info' should
> be somehow amended.  It currently says
> 
> Return information about a font named NAME on frame FRAME.
> 
> and nowhere mentions which buffer must be current or maybe even which
> window must be selected.

I don't think the results of font-info depend on that.  It's the
result of face-font that depend on the buffer and frame, but once you
have the font's name, all the rest doesn't matter, since Emacs already
have the font data structure set up and stored in memory.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[martin rudalics]

 > I don't think the results of font-info depend on that.  It's the
 > result of face-font that depend on the buffer and frame, but once you
 > have the font's name, all the rest doesn't matter, since Emacs already
 > have the font data structure set up and stored in memory.

Then we should mention the buffer for `face-font'.  BTW, why does the
Elisp manual say that it does "mostly provide compatibility with old
versions of Emacs"?

But we also should mention (and I still think `font-info' is the better
place for that) what happens when the current buffer has rescaled text
but is not displayed on the selected frame (or the frame denoted by the
argument of `font-info').

I would do that myself but I got lost in the code.  I still don't
understand where and how text rescaling is applied.  Sorry.

martin

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[martin rudalics]

 > If someone wants to submit (an almost trivial) patch to add an option
 > that would remove the continuation/truncation glyphs when there are no
 > fringes, please go ahead.

I'm mising two trademarks: One for "someone" and another one for "almost
trivial".

martin

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> Date: Sat, 20 Dec 2014 11:09:18 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: malsburg@posteo.de, 19395@debbugs.gnu.org
> 
>  > I don't think the results of font-info depend on that.  It's the
>  > result of face-font that depend on the buffer and frame, but once you
>  > have the font's name, all the rest doesn't matter, since Emacs already
>  > have the font data structure set up and stored in memory.
> 
> Then we should mention the buffer for `face-font'.

I agree.  Feel free to add that (and please mention face remapping, as
I believe it is the only reason why the buffer, as opposed to the
frame, could be relevant).

> BTW, why does the Elisp manual say that it does "mostly provide
> compatibility with old versions of Emacs"?

AFAIU, it only says so about the set-face-FOO functions, which doesn't
include face-font.

> But we also should mention (and I still think `font-info' is the better
> place for that) what happens when the current buffer has rescaled text
> but is not displayed on the selected frame (or the frame denoted by the
> argument of `font-info').

How can the current buffer be not displayed in the selected frame?

> I would do that myself but I got lost in the code.  I still don't
> understand where and how text rescaling is applied.

In face-remap.el, and then in xfaces.c (search for face_remapping in
the latter).  Assuming I understand correctly what is it that confused
you.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> Date: Sat, 20 Dec 2014 11:09:44 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 19395@debbugs.gnu.org, malsburg@posteo.de
> 
>  > If someone wants to submit (an almost trivial) patch to add an option
>  > that would remove the continuation/truncation glyphs when there are no
>  > fringes, please go ahead.
> 
> I'm mising two trademarks: One for "someone" and another one for "almost
> trivial".

It's really almost trivial, I can provide hints if I see a volunteer
stepping forward.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[martin rudalics]

 > AFAIU, it only says so about the set-face-FOO functions, which doesn't
 > include face-font.

Here I see in "37.12.3 Face Attribute Functions"

...

    The following functions examine the attributes of a face.  They
mostly provide compatibility with old versions of Emacs.  If you don't
specify FRAME, they refer to the selected frame; `t' refers to the
default data for new frames.  They return `unspecified' if the face
doesn't define any value for that attribute.  If INHERIT is `nil', only
an attribute directly defined by the face is returned.  If INHERIT is
non-`nil', any faces specified by its `:inherit' attribute are
considered as well, and if INHERIT is a face or a list of faces, then
they are also considered, until a specified attribute is found.  To
ensure that the return value is always specified, use a value of
`default' for INHERIT.

  -- Function: face-font face &optional frame
      This function returns the name of the font of face FACE.

...

Maybe "mostly" is special here.

 >> But we also should mention (and I still think `font-info' is the better
 >> place for that) what happens when the current buffer has rescaled text
 >> but is not displayed on the selected frame (or the frame denoted by the
 >> argument of `font-info').
 >
 > How can the current buffer be not displayed in the selected frame?

As in

(with-selected-frame some-frame
   (with-current-buffer a-buffer-not-displayed-on-some-frame
     ...

 >> I still don't
 >> understand where and how text rescaling is applied.
 >
 > In face-remap.el, and then in xfaces.c (search for face_remapping in
 > the latter).

This boils down to understanding the 200+ lines of merge_face_ref, at
least.

 > Assuming I understand correctly what is it that confused
 > you.

If I look at the doc-string of say `text-scale-adjust' I cannot see that
some buffer local value is mentioned although C-x C-- clearly has only a
buffer local effect here.  So I obviously have to delve into the doc of
something like `face-remapping-alist' which, however, doesn't mention
any relationship of faces to frames.

IIUC face remapping maps a default face (which may be frame specific or
not) via a scaling value (which may be buffer local or not) to another
face whose width I eventually want to retrieve via `face-font'.  Does
the buffer/frame/window relationship affect that value and if so how?

martin

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> Date: Sat, 20 Dec 2014 12:42:49 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: malsburg@posteo.de, 19395@debbugs.gnu.org
> 
>  > AFAIU, it only says so about the set-face-FOO functions, which doesn't
>  > include face-font.
> 
> Here I see in "37.12.3 Face Attribute Functions"
> 
> ...
> 
>     The following functions examine the attributes of a face.  They
> mostly provide compatibility with old versions of Emacs.  If you don't
> specify FRAME, they refer to the selected frame; `t' refers to the
> default data for new frames.  They return `unspecified' if the face
> doesn't define any value for that attribute.  If INHERIT is `nil', only
> an attribute directly defined by the face is returned.  If INHERIT is
> non-`nil', any faces specified by its `:inherit' attribute are
> considered as well, and if INHERIT is a face or a list of faces, then
> they are also considered, until a specified attribute is found.  To
> ensure that the return value is always specified, use a value of
> `default' for INHERIT.
> 
>   -- Function: face-font face &optional frame
>       This function returns the name of the font of face FACE.

Ah, OK.  That probably wants you to use the Brave New World's

   (face-attribute 'default :font)

instead of using face-font.

>  > How can the current buffer be not displayed in the selected frame?
> 
> As in
> 
> (with-selected-frame some-frame
>    (with-current-buffer a-buffer-not-displayed-on-some-frame
>      ...

Which makes it "displayed", as far as Emacs is concerned, right?

IOW, for this purpose, the fact that the display engine didn't
actually display the buffer doesn't matter.  All we need is the frame
and access to face-remapping-alist.

>  >> I still don't
>  >> understand where and how text rescaling is applied.
>  >
>  > In face-remap.el, and then in xfaces.c (search for face_remapping in
>  > the latter).
> 
> This boils down to understanding the 200+ lines of merge_face_ref, at
> least.

What do you want to understand?  In a nutshell, we go through the
face-remapping-alist, and if the face is there, use the remapped
face's attributes instead.

> If I look at the doc-string of say `text-scale-adjust' I cannot see that
> some buffer local value is mentioned although C-x C-- clearly has only a
> buffer local effect here.  So I obviously have to delve into the doc of
> something like `face-remapping-alist' which, however, doesn't mention
> any relationship of faces to frames.

face-remapping-alist is applied _after_ the frame-specific face is
retrieved.  Does that answer your problem?

> IIUC face remapping maps a default face (which may be frame specific or
> not) via a scaling value (which may be buffer local or not) to another
> face whose width I eventually want to retrieve via `face-font'.  Does
> the buffer/frame/window relationship affect that value and if so how?

AFAIK, only the buffer matters, since face-remapping-alist is
buffer-local.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[martin rudalics]

 > Ah, OK.  That probably wants you to use the Brave New World's
 >
 >     (face-attribute 'default :font)
 >
 > instead of using face-font.

OK.  So let's do without Huxley.

 >>   > How can the current buffer be not displayed in the selected frame?
 >>
 >> As in
 >>
 >> (with-selected-frame some-frame
 >>     (with-current-buffer a-buffer-not-displayed-on-some-frame
 >>       ...
 >
 > Which makes it "displayed", as far as Emacs is concerned, right?

You mean as far as the Emacs display engine is concerned, right?  But
the caller of `face-font' doesn't know that the display engine operates
on the current buffer regardless of whether it is displayed or not.

 > What do you want to understand?  In a nutshell, we go through the
 > face-remapping-alist, and if the face is there, use the remapped
 > face's attributes instead.

I can only guess - are the following statements correct wrt to display?

(1) When two characters have the same face they are identic in their
     appearance on screen.

(2) When two characters have a different appearance on screen they have
     different faces.

For me it's difficult to discriminate the usage of the term "face" when
programming Elisp from the usage of the term "face" when Emacs displays
a character.

 > face-remapping-alist is applied _after_ the frame-specific face is
 > retrieved.  Does that answer your problem?

What means "applied"?  Is it merged or does it replace the
frame-specific face?

 >> IIUC face remapping maps a default face (which may be frame specific or
 >> not) via a scaling value (which may be buffer local or not) to another
 >> face whose width I eventually want to retrieve via `face-font'.  Does
 >> the buffer/frame/window relationship affect that value and if so how?
 >
 > AFAIK, only the buffer matters, since face-remapping-alist is
 > buffer-local.

It's doc-string says

   If this variable is made buffer-local, the face remapping takes effect
   only in that buffer.

martin

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Titus von der Malsburg]

[-- Attachment #1: Type: text/plain, Size: 4193 bytes --]


On 2014-12-18 Thu 17:15, Eli Zaretskii wrote:
>> From: Titus von der Malsburg <malsburg@posteo.de>
>> Cc: 19395@debbugs.gnu.org
>> Date: Wed, 17 Dec 2014 19:36:04 -0800
>> 
>> > But if we want this function to be more generally useful, it
>> > shouldn't be limited to the frame's canonical character size, and
>> > should at least take the face-remapping into account.  Bonus points
>> > for accepting a face as an argument and using that face's font
>> > dimensions.
>> 
>> This is more difficult than I thought.  Below is a first sketch.  Let me
>> know if you think this is going in the right direction and I'll polish
>> it and add the bonus feature.
>> 
>> It appears that a font has to be rendered before Emacs can tell how wide
>> a character is.  That's why we need the temporary buffer.  Not elegant,
>> but I couldn't find a better way.  `default-font-width' complements
>> `default-font-height' in simple.el.  The other function would go into
>> window.el.
>
> Given the changes I pushed in commit b197822, you will no longer need
> all this complexity.  Just
>
>    (aref (font-info (face-font 'default)) 11)

Great, thanks for adding this.  Below the updated version of my solution
to the original problem:

(defun window-char-width (&optional window face)
   "Return character width for WINDOW.
WINDOW must be a live window and defaults to the selected one.

FACE is the face for which character width should be
returned.  Buffer-local face remappings are applied.  If nil, the
default face is used."
   (with-selected-window (window-normalize-window window t)
     (let* ((face (if face face 'default))
	    (info (font-info (face-font face)))
	    (width (aref info 11)))
       (if (> width 0)
	  width
	 (aref info 10)))))

(defun window-max-characters-per-line (&optional window face)
  "Return the number of characters that can be displayed
on one line.
WINDOW must be a live window and defaults to the selected one.

FACE is the face whose character width should be used for the
calculation.  Buffer-local face remappings are applied.  If nil,
the default face is used.

This function is different from `window-body-width' in that it
accounts for fringes (when at least one fringe has zero width,
one column is reserved for continuation characters) and for the
size of the default font (which may have been adjusted using,
e.g., `text-scale-increase')."
  (with-selected-window (window-normalize-window window t)
    (let* ((window-width (window-body-width window t))
           (font-width (window-char-width window face))
           (ncols (/ window-width font-width)))
      (if (and (display-graphic-p)
               overflow-newline-into-fringe
               (/= (frame-parameter nil 'left-fringe) 0)
               (/= (frame-parameter nil 'right-fringe) 0))
          ncols
        (1- ncols)))))

Note that the first function is a variant of Martin's version which had
a bug: if the buffer in the specified window is displayed in two frames,
the returned character width was always the one used in the current
frame which is not necessarily the character width in the specified
window (the window may be in the other frame).  This is a problem
because character width can be different, if the two frames use
different default fonts.

For completeness, it probably also makes sense to include the following
function in simple.el, which already has a function
`default-font-height'.

(defun default-font-width () 
  "Return the width in pixels of the current buffer's default face font.

Buffer-local face remappings are applied."
  (let* ((info (font-info (face-font 'default)))
	 (width (aref info 11)))
    (if (> width 0)
	width
      (aref info 10))))

> (For bullet-proof code, check that this is not zero, and if it is, use
> the 10th member instead; see the docs.)

This is checked.

> If we are going to put this in simple.el or subr.el, I don't think we
> need to worry about XEmacs.

I removed that part of the condition.

I also added the bonus feature which lets you specify a specific face
that should be used for the calculations.

  Titus


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[martin rudalics]

 > (defun window-char-width (&optional window face)
 >     "Return character width for WINDOW.
 > WINDOW must be a live window and defaults to the selected one.
 >
 > FACE is the face for which character width should be
 > returned.  Buffer-local face remappings are applied.  If nil, the
 > default face is used."
 >     (with-selected-window (window-normalize-window window t)
 >       (let* ((face (if face face 'default))
 > 	    (info (font-info (face-font face)))
 > 	    (width (aref info 11)))
 >         (if (> width 0)
 > 	  width
 > 	 (aref info 10)))))
 >
 > (defun window-max-characters-per-line (&optional window face)
 >    "Return the number of characters that can be displayed
 > on one line.
 > WINDOW must be a live window and defaults to the selected one.
 >
 > FACE is the face whose character width should be used for the
 > calculation.  Buffer-local face remappings are applied.  If nil,
 > the default face is used.
 >
 > This function is different from `window-body-width' in that it
 > accounts for fringes (when at least one fringe has zero width,
 > one column is reserved for continuation characters) and for the
 > size of the default font (which may have been adjusted using,
 > e.g., `text-scale-increase')."
 >    (with-selected-window (window-normalize-window window t)
 >      (let* ((window-width (window-body-width window t))
 >             (font-width (window-char-width window face))
 >             (ncols (/ window-width font-width)))
 >        (if (and (display-graphic-p)
 >                 overflow-newline-into-fringe
 >                 (/= (frame-parameter nil 'left-fringe) 0)
 >                 (/= (frame-parameter nil 'right-fringe) 0))
 >            ncols
 >          (1- ncols)))))
 >
 > Note that the first function is a variant of Martin's version which had
 > a bug: if the buffer in the specified window is displayed in two frames,
 > the returned character width was always the one used in the current
 > frame which is not necessarily the character width in the specified
 > window (the window may be in the other frame).  This is a problem
 > because character width can be different, if the two frames use
 > different default fonts.

So this what I've been trying to find out all the time.  The faces
apparently _get_ merged dependent on the buffer _and_ the frame.

I need a corresponding `window-char-height' as well, probably also with
a FACE argument.

 > For completeness, it probably also makes sense to include the following
 > function in simple.el, which already has a function
 > `default-font-height'.
 >
 > (defun default-font-width ()
 >    "Return the width in pixels of the current buffer's default face font.

I profoundly dislike the "default-" prefix here.  `buffer-font-height'
and `buffer-font-width' would be much better IMHO.

 > I also added the bonus feature which lets you specify a specific face
 > that should be used for the calculations.

So are you now sure that we don't need a specific character ("M") any
more?

martin

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Titus von der Malsburg]

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]


On 2014-12-20 Sat 16:06, martin rudalics wrote:
>  > (defun default-font-width ()
>  >    "Return the width in pixels of the current buffer's default face font.
>
> I profoundly dislike the "default-" prefix here.  `buffer-font-height'
> and `buffer-font-width' would be much better IMHO.

The thing is that the value is not fully determined by the buffer, so I
think the name buffer-font-width is a little
misleading.  `frame-buffer-font-width' is more precise but also a little
unwieldy.  The other problem is that `default-font-height' is already a
standard Emacs function and renaming it will cause problems.

>  > I also added the bonus feature which lets you specify a specific face
>  > that should be used for the calculations.
>
> So are you now sure that we don't need a specific character ("M") any
> more?

If I understand correctly, the returned value is based on the width of a
space.  In proportional fonts that will of course differ from the width
of other characters.  But I think this is not a big problem because the
notion of characters per line doesn't make sense for proportional fonts
and using proportional fonts in Emacs is a terrible idea
anyway.  But perhaps this issue should be mentioned in the doc string.

  Titus



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Titus von der Malsburg]

(Sent from my cell phone.)

>> On 20.12.2014, at 16:06, martin rudalics <rudalics@gmx.at> wrote:
>> 
>> (defun window-char-width (&optional window face)
>>    "Return character width for WINDOW.
>> WINDOW must be a live window and defaults to the selected one.
>> 
>> FACE is the face for which character width should be
>> returned.  Buffer-local face remappings are applied.  If nil, the
>> default face is used."
>>    (with-selected-window (window-normalize-window window t)
>>      (let* ((face (if face face 'default))
>>       (info (font-info (face-font face)))
>>       (width (aref info 11)))
>>        (if (> width 0)
>>     width
>>    (aref info 10)))))
>> 
>> (defun window-max-characters-per-line (&optional window face)
>>   "Return the number of characters that can be displayed
>> on one line.
>> WINDOW must be a live window and defaults to the selected one.
>> 
>> FACE is the face whose character width should be used for the
>> calculation.  Buffer-local face remappings are applied.  If nil,
>> the default face is used.
>> 
>> This function is different from `window-body-width' in that it
>> accounts for fringes (when at least one fringe has zero width,
>> one column is reserved for continuation characters) and for the
>> size of the default font (which may have been adjusted using,
>> e.g., `text-scale-increase')."
>>   (with-selected-window (window-normalize-window window t)
>>     (let* ((window-width (window-body-width window t))
>>            (font-width (window-char-width window face))
>>            (ncols (/ window-width font-width)))
>>       (if (and (display-graphic-p)
>>                overflow-newline-into-fringe
>>                (/= (frame-parameter nil 'left-fringe) 0)
>>                (/= (frame-parameter nil 'right-fringe) 0))
>>           ncols
>>         (1- ncols)))))
>> 
>> Note that the first function is a variant of Martin's version which had
>> a bug: if the buffer in the specified window is displayed in two frames,
>> the returned character width was always the one used in the current
>> frame which is not necessarily the character width in the specified
>> window (the window may be in the other frame).  This is a problem
>> because character width can be different, if the two frames use
>> different default fonts.
> 
> So this what I've been trying to find out all the time.  The faces
> apparently _get_ merged dependent on the buffer _and_ the frame.

Yes, my understanding is that each frame has a default face. The properties in the buffer-local face-remapping-alist overwrite the vales of the dafault face. Windows do not influence the font.

> 
> I need a corresponding `window-char-height' as well, probably also with
> a FACE argument.

Yes, that makes sense. I can add it if you want.

> 
>> For completeness, it probably also makes sense to include the following
>> function in simple.el, which already has a function
>> `default-font-height'.
>> 
>> (defun default-font-width ()
>>   "Return the width in pixels of the current buffer's default face font.
> 
> I profoundly dislike the "default-" prefix here.  `buffer-font-height'
> and `buffer-font-width' would be much better IMHO.
> 
>> I also added the bonus feature which lets you specify a specific face
>> that should be used for the calculations.
> 
> So are you now sure that we don't need a specific character ("M") any
> more?
> 
> martin

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[martin rudalics]

 > The thing is that the value is not fully determined by the buffer, so I
 > think the name buffer-font-width is a little
 > misleading.  `frame-buffer-font-width' is more precise but also a little
 > unwieldy.

I've been confused enough already.  It would be nice to get this right
once and for all.

 > The other problem is that `default-font-height' is already a
 > standard Emacs function and renaming it will cause problems.

We would add an alias, obviously.

 >>   > I also added the bonus feature which lets you specify a specific face
 >>   > that should be used for the calculations.
 >>
 >> So are you now sure that we don't need a specific character ("M") any
 >> more?
 >
 > If I understand correctly, the returned value is based on the width of a
 > space.  In proportional fonts that will of course differ from the width
 > of other characters.  But I think this is not a big problem because the
 > notion of characters per line doesn't make sense for proportional fonts
 > and using proportional fonts in Emacs is a terrible idea
 > anyway.  But perhaps this issue should be mentioned in the doc string.

I forgot that it was Joe Corneli who asked for this in another thread.
But once we have a function like `window-max-characters-per-line' it
would make sense to have it consider the maximum width of a proportional
font character as well and we'd fix his problem as well

BTW, do we have some character or letter spacing which we should
consider as well?  IIRC somone asked here for an orthogonal function
that would consider line spacing.

martin

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> From: Titus von der Malsburg <malsburg@posteo.de>
> Cc: 19395@debbugs.gnu.org
> Date: Sat, 20 Dec 2014 15:51:27 +0100
> 
> >    (aref (font-info (face-font 'default)) 11)
> 
> Great, thanks for adding this.  Below the updated version of my solution
> to the original problem:

Looks good to me.  A few comments about the doc strings:

> (defun window-char-width (&optional window face)
>    "Return character width for WINDOW.

      Return average character width for the font of FACE used in WINDOW.

> FACE is the face for which character width should be
> returned.

This is redundant with my proposed change above.

>           Buffer-local face remappings are applied.  If nil, the
> default face is used."

I would reverse the order:

  If FACE is nil or omitted, the default face is used.  If FACE is
  remapped (see `face-remapping-alist'), the function returns the
  information for the remapped face.

> (defun window-max-characters-per-line (&optional window face)
>   "Return the number of characters that can be displayed
> on one line.

This should be one line, and it is better to mention WINDOW there.

> Buffer-local face remappings are applied.

"Are applied" is too vague, and might confuse.  See my rewording above
for one possible solution.

> This function is different from `window-body-width' in that it
> accounts for fringes

Actually, it accounts for the portions of the line reserved for the
continuation glyph.  Missing fringes are just the trigger to reserve
that.

> one column is reserved for continuation characters) and for the

Please use "glyphs" here, as it could be a string, not a single
character.  (This is explained in the documentation of
standard-display-table.)

> For completeness, it probably also makes sense to include the following
> function in simple.el, which already has a function
> `default-font-height'.

I agree.

Thanks.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> Date: Sat, 20 Dec 2014 15:51:12 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: malsburg@posteo.de, 19395@debbugs.gnu.org
> 
>  >> (with-selected-frame some-frame
>  >>     (with-current-buffer a-buffer-not-displayed-on-some-frame
>  >>       ...
>  >
>  > Which makes it "displayed", as far as Emacs is concerned, right?
> 
> You mean as far as the Emacs display engine is concerned, right?  But
> the caller of `face-font' doesn't know that the display engine operates
> on the current buffer regardless of whether it is displayed or not.

She doesn't need to know: the effect doesn't depend on that.

> (1) When two characters have the same face they are identic in their
>      appearance on screen.
> 
> (2) When two characters have a different appearance on screen they have
>      different faces.

I think YES to both, assuming both characters are on the same frame.
If not, then (2) might be false.

> For me it's difficult to discriminate the usage of the term "face" when
> programming Elisp from the usage of the term "face" when Emacs displays
> a character.

I was primarily talking about the latter.  But the different is small,
if it exists at all.

>  > face-remapping-alist is applied _after_ the frame-specific face is
>  > retrieved.  Does that answer your problem?
> 
> What means "applied"?  Is it merged or does it replace the
> frame-specific face?

It replaces the original frame-specific face.

>  >> IIUC face remapping maps a default face (which may be frame specific or
>  >> not) via a scaling value (which may be buffer local or not) to another
>  >> face whose width I eventually want to retrieve via `face-font'.  Does
>  >> the buffer/frame/window relationship affect that value and if so how?
>  >
>  > AFAIK, only the buffer matters, since face-remapping-alist is
>  > buffer-local.
> 
> It's doc-string says
> 
>    If this variable is made buffer-local, the face remapping takes effect
>    only in that buffer.

OK, _if_ face-remapping-alist is buffer-local.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> Date: Sat, 20 Dec 2014 16:06:21 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 19395@debbugs.gnu.org
> 
> The faces apparently _get_ merged dependent on the buffer _and_ the
> frame.

Remapped faces might depend on the buffer, non-remapped ones depend
only on the frame.

> I need a corresponding `window-char-height' as well, probably also with
> a FACE argument.

Without the FACE argument, you already have default-font-height,

>  > For completeness, it probably also makes sense to include the following
>  > function in simple.el, which already has a function
>  > `default-font-height'.
>  >
>  > (defun default-font-width ()
>  >    "Return the width in pixels of the current buffer's default face font.
> 
> I profoundly dislike the "default-" prefix here.  `buffer-font-height'
> and `buffer-font-width' would be much better IMHO.

But a buffer can use a variety of fonts.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> Date: Sat, 20 Dec 2014 17:03:33 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, 19395@debbugs.gnu.org
> 
> BTW, do we have some character or letter spacing which we should
> consider as well?  IIRC somone asked here for an orthogonal function
> that would consider line spacing.

There is already default-line-height which does that for the font of
the default face.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[martin rudalics]

 >> You mean as far as the Emacs display engine is concerned, right?  But
 >> the caller of `face-font' doesn't know that the display engine operates
 >> on the current buffer regardless of whether it is displayed or not.
 >
 > She doesn't need to know: the effect doesn't depend on that.

If I want to right-adjust the last word of a buffer line I apparently
have to provide the buffer _and_ the frame in order to know how many
spaces to insert.

 >> What means "applied"?  Is it merged or does it replace the
 >> frame-specific face?
 >
 > It replaces the original frame-specific face.

IIUC this contradicts an earlier observation by Titus that

   if the buffer in the specified window is displayed in two frames,
   the returned character width was always the one used in the current
   frame which is not necessarily the character width in the specified
   window (the window may be in the other frame).  This is a problem
   because character width can be different, if the two frames use
   different default fonts.

martin

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[martin rudalics]

 >> The faces apparently _get_ merged dependent on the buffer _and_ the
 >> frame.
 >
 > Remapped faces might depend on the buffer

... and the frame ...

 > , non-remapped ones depend
 > only on the frame.
 >
 >> I need a corresponding `window-char-height' as well, probably also with
 >> a FACE argument.
 >
 > Without the FACE argument, you already have default-font-height,

It's the window that establishes the correspondence between a buffer and
its frame.  Otherwise we can do away with `window-char-width' as well.

 >> I profoundly dislike the "default-" prefix here.  `buffer-font-height'
 >> and `buffer-font-width' would be much better IMHO.
 >
 > But a buffer can use a variety of fonts.

OK.  Then this needs a better doc-string.

martin

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> Date: Sat, 20 Dec 2014 18:50:56 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: malsburg@posteo.de, 19395@debbugs.gnu.org
> 
>  >> You mean as far as the Emacs display engine is concerned, right?  But
>  >> the caller of `face-font' doesn't know that the display engine operates
>  >> on the current buffer regardless of whether it is displayed or not.
>  >
>  > She doesn't need to know: the effect doesn't depend on that.
> 
> If I want to right-adjust the last word of a buffer line I apparently
> have to provide the buffer _and_ the frame in order to know how many
> spaces to insert.

Yes, and with-current-buffer achieves that, right?

>  >> What means "applied"?  Is it merged or does it replace the
>  >> frame-specific face?
>  >
>  > It replaces the original frame-specific face.
> 
> IIUC this contradicts an earlier observation by Titus that
> 
>    if the buffer in the specified window is displayed in two frames,
>    the returned character width was always the one used in the current
>    frame which is not necessarily the character width in the specified
>    window (the window may be in the other frame).  This is a problem
>    because character width can be different, if the two frames use
>    different default fonts.

I don't see any contradictions.  I said nothing about windows, only
about frames and buffers.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> Date: Sat, 20 Dec 2014 18:51:14 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: malsburg@posteo.de, 19395@debbugs.gnu.org
> 
>  >> I need a corresponding `window-char-height' as well, probably also with
>  >> a FACE argument.
>  >
>  > Without the FACE argument, you already have default-font-height,
> 
> It's the window that establishes the correspondence between a buffer and
> its frame.  Otherwise we can do away with `window-char-width' as well.

We are miscommunicating.  What I pointed out that if FACE doesn't
matter, you already have the function you are after, in reply to your
"probably also with a FACE".  That's all I wanted to say.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[martin rudalics]

 >> If I want to right-adjust the last word of a buffer line I apparently
 >> have to provide the buffer _and_ the frame in order to know how many
 >> spaces to insert.
 >
 > Yes, and with-current-buffer achieves that, right?

Only if the current buffer appears on the selected frame.  My original
definition was

(defun window-char-width (&optional window)
   "Return default character width for WINDOW.
WINDOW must be a live window and defaults to the selected one."
   (setq window (window-normalize-window window t))
   (with-current-buffer (window-buffer window)
     (let* ((info (font-info (face-font 'default)))
        (width (aref info 11)))
       (if (> width 0)
       width
     (aref info 10)))))

and you can trust me that I would have written it as

(defun window-char-width (&optional window)
   "Return default character width for WINDOW.
WINDOW must be a live window and defaults to the selected one."
   (setq window (window-normalize-window window t))
   (with-selected-window window
     (let* ((info (font-info (face-font 'default)))
        (width (aref info 11)))
       (if (> width 0)
       width
     (aref info 10)))))

if I had known that

 >>   > It replaces the original frame-specific face.

is not true.

 >> IIUC this contradicts an earlier observation by Titus that
 >>
 >>     if the buffer in the specified window is displayed in two frames,
 >>     the returned character width was always the one used in the current
 >>     frame which is not necessarily the character width in the specified
 >>     window (the window may be in the other frame).  This is a problem
 >>     because character width can be different, if the two frames use
 >>     different default fonts.
 >
 > I don't see any contradictions.  I said nothing about windows, only
 > about frames and buffers.

His last sentence says that the outcome is dependent on the frame.  So
it does not "replace" the original frame-specific face but "merge" the
frame and buffer specific faces.

But maybe we are just miscommunicating again.

martin

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> Date: Sat, 20 Dec 2014 19:58:05 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: malsburg@posteo.de, 19395@debbugs.gnu.org
> 
>  >> IIUC this contradicts an earlier observation by Titus that
>  >>
>  >>     if the buffer in the specified window is displayed in two frames,
>  >>     the returned character width was always the one used in the current
>  >>     frame which is not necessarily the character width in the specified
>  >>     window (the window may be in the other frame).  This is a problem
>  >>     because character width can be different, if the two frames use
>  >>     different default fonts.
>  >
>  > I don't see any contradictions.  I said nothing about windows, only
>  > about frames and buffers.
> 
> His last sentence says that the outcome is dependent on the frame.  So
> it does not "replace" the original frame-specific face but "merge" the
> frame and buffer specific faces.

No.  When a buffer is displayed that has a face in its
face-remapping-alist, every face in that alist is replaced by its
remapped face.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Titus von der Malsburg]

[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]


On 2014-12-20 Sat 20:52, Eli Zaretskii wrote:
>> Date: Sat, 20 Dec 2014 19:58:05 +0100
>> From: martin rudalics <rudalics@gmx.at>
>> CC: malsburg@posteo.de, 19395@debbugs.gnu.org
>> 
>>  >> IIUC this contradicts an earlier observation by Titus that
>>  >>
>>  >>     if the buffer in the specified window is displayed in two frames,
>>  >>     the returned character width was always the one used in the current
>>  >>     frame which is not necessarily the character width in the specified
>>  >>     window (the window may be in the other frame).  This is a problem
>>  >>     because character width can be different, if the two frames use
>>  >>     different default fonts.
>>  >
>>  > I don't see any contradictions.  I said nothing about windows, only
>>  > about frames and buffers.
>> 
>> His last sentence says that the outcome is dependent on the frame.  So
>> it does not "replace" the original frame-specific face but "merge" the
>> frame and buffer specific faces.
>
> No.  When a buffer is displayed that has a face in its
> face-remapping-alist, every face in that alist is replaced by its
> remapped face.

Yes, that's technically correct.  However, a common use case of
face-remapping-alist is to merge a new attribute into the existing
definition of a face, e.g:

  ((default (:height 1.2) default))

Moreover, the default face seems to be a special case.  If you define
face-remapping-alist as following:

  ((default (:height 1.2)))

the height attribute is merged into the existing definition of the
default face.  What this means is that the faces used in a buffer will
typically (but not necessarily) depend on the default font and thus on
the frame in which the buffer is displayed.

  Titus

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> From: Titus von der Malsburg <malsburg@posteo.de>
> Cc: martin rudalics <rudalics@gmx.at>, 19395@debbugs.gnu.org
> Date: Sun, 21 Dec 2014 13:14:20 +0100
> 
> On 2014-12-20 Sat 20:52, Eli Zaretskii wrote:
> >> Date: Sat, 20 Dec 2014 19:58:05 +0100
> >> From: martin rudalics <rudalics@gmx.at>
> >> CC: malsburg@posteo.de, 19395@debbugs.gnu.org
> >> 
> >>  >> IIUC this contradicts an earlier observation by Titus that
> >>  >>
> >>  >>     if the buffer in the specified window is displayed in two frames,
> >>  >>     the returned character width was always the one used in the current
> >>  >>     frame which is not necessarily the character width in the specified
> >>  >>     window (the window may be in the other frame).  This is a problem
> >>  >>     because character width can be different, if the two frames use
> >>  >>     different default fonts.
> >>  >
> >>  > I don't see any contradictions.  I said nothing about windows, only
> >>  > about frames and buffers.
> >> 
> >> His last sentence says that the outcome is dependent on the frame.  So
> >> it does not "replace" the original frame-specific face but "merge" the
> >> frame and buffer specific faces.
> >
> > No.  When a buffer is displayed that has a face in its
> > face-remapping-alist, every face in that alist is replaced by its
> > remapped face.
> 
> Yes, that's technically correct.

Actually, I stand corrected: we do merge the remapped face with the
original one.  It goes like this:

   lookup_basic_face
     -> lookup_named_face
          -> merge_face_vectors

Sorry.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Titus von der Malsburg]

[-- Attachment #1: Type: text/plain, Size: 3380 bytes --]


On 2014-12-20 Sat 17:31, Eli Zaretskii wrote:
>> From: Titus von der Malsburg <malsburg@posteo.de>
>> Cc: 19395@debbugs.gnu.org
>> Date: Sat, 20 Dec 2014 15:51:27 +0100
>> 
>> >    (aref (font-info (face-font 'default)) 11)
>> 
>> Great, thanks for adding this.  Below the updated version of my solution
>> to the original problem:
>
> Looks good to me.  A few comments about the doc strings:

Eli, I fixed the doc strings following your suggestions and added the
function `window-char-height' analogous to `window-char-width' (see code
below).  If there are no objections, I'll go ahead and submit a patch
(after reading the relevant guidelines).

Thanks for your input.  I learned a lot about fonts and faces in Emacs.

  Titus

(defun default-font-width ()
  "Return the width in pixels of the current buffer's default face font.

If the default font is remapped (see `face-remapping-alist'), the
function returns the width of the remapped face."
  (let* ((info (font-info (face-font 'default)))
	 (width (aref info 11)))
    (if (> width 0)
	width
      (aref info 10))))

(defun window-char-width (&optional window face)
   "Return average character width for the font of FACE used in WINDOW.
WINDOW must be a live window and defaults to the selected one.

If FACE is nil or omitted, the default face is used.  If FACE is
remapped (see `face-remapping-alist'), the function returns the
information for the remapped face."
   (with-selected-window (window-normalize-window window t)
     (let* ((face (if face face 'default))
	    (info (font-info (face-font face)))
	    (width (aref info 11)))
       (if (> width 0)
	  width
	 (aref info 10)))))

(defun window-char-height (&optional window face)
   "Return character height for the font of FACE used in WINDOW.
WINDOW must be a live window and defaults to the selected one.

If FACE is nil or omitted, the default face is used.  If FACE is
remapped (see `face-remapping-alist'), the function returns the
information for the remapped face."
   (with-selected-window (window-normalize-window window t)
     (let* ((face (if face face 'default))
	    (info (font-info (face-font face))))
       (aref info 3))))

(defun window-max-characters-per-line (&optional window face)
  "Return the number of characters that can be displayed on one line in WINDOW.
WINDOW must be a live window and defaults to the selected one.

The character width of FACE is used for the calculation.  If FACE
is nil or omitted, the default face is used.  If FACE is
remapped (see `face-remapping-alist'), the function uses the
remapped face.

This function is different from `window-body-width' in two
ways.  First, it accounts for the portions of the line reserved
for the continuation glyph.  Second, it accounts for the size of
the font, which may have been adjusted, e.g., using
`text-scale-increase')."
  (with-selected-window (window-normalize-window window t)
    (let* ((window-width (window-body-width window t))
           (font-width (window-char-width window face))
           (ncols (/ window-width font-width)))
      (if (and (display-graphic-p)
               overflow-newline-into-fringe
               (/= (frame-parameter nil 'left-fringe) 0)
               (/= (frame-parameter nil 'right-fringe) 0))
          ncols
        (1- ncols)))))
  

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii]

> From: Titus von der Malsburg <malsburg@posteo.de>
> Cc: 19395@debbugs.gnu.org
> Date: Sun, 21 Dec 2014 23:04:51 +0100
> 
> Eli, I fixed the doc strings following your suggestions and added the
> function `window-char-height' analogous to `window-char-width' (see code
> below).  If there are no objections, I'll go ahead and submit a patch
> (after reading the relevant guidelines).

LGTM.  Now to make this a superb contribution, please add a few words
in NEWS about the new functions, and submit a patch with that.

> Thanks for your input.  I learned a lot about fonts and faces in Emacs.

You are welcome.  And thanks for working on this.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> LGTM.  Now to make this a superb contribution, please add a few words
> in NEWS about the new functions, and submit a patch with that.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

The patch apparently never arrived, so I've now added Titus' functions
to Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Jim Porter]

(Resending, since this bug was archived.)

On 4/29/2022 6:14 AM, Lars Ingebrigtsen wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>> LGTM.  Now to make this a superb contribution, please add a few words
>> in NEWS about the new functions, and submit a patch with that.
> 
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
> 
> The patch apparently never arrived, so I've now added Titus' functions
> to Emacs 29.

It looks like a modified version of this patch was already merged as 
4a50af936e24b5f71df4079beb6dde82ed1955c2, which shipped with Emacs 25. 
I'm not totally sure, but from looking at the various functions, it 
seems the older patch is a bit more robust in the face of different 
configuration.

bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Lars Ingebrigtsen]

Jim Porter <jporterbugs@gmail.com> writes:

> It looks like a modified version of this patch was already merged as
> 4a50af936e24b5f71df4079beb6dde82ed1955c2, which shipped with Emacs
> 25. I'm not totally sure, but from looking at the various functions,
> it seems the older patch is a bit more robust in the face of different
> configuration.

Oops.  Thanks, I've now removed window-max-characters-per-line and
friends, and pointed the doc strings towards window-max-chars-per-line
instead.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no