completion buffer - unsuitable column width

completion buffer - unsuitable column width

[David Reitter]

I noticed that the columns in completion buffers are awfully wide for  
me.  They also wrap around when the frame is resized, either while  
displaying it or after killing it explicitly and bringing up a new  
completion buffer.

Looking at the code, it seems that this is due to an incorrect  
calculation of the available width in characters:

(defun completion--insert-strings (strings)
  ...
	   (window (get-buffer-window (current-buffer) 0))
	   (wwidth (if window (1- (window-width window)) 79))
...

In my case, I use face-remapping-alist to assign different faces for  
the frame default face and the buffer default face.  This causes  
"window-width" to return a figure that does not indicate how much text  
can be fit in one line in that window.

I don't know how to fix this given that there seems to be no way to  
calculate the (average) character width of text with a given face.

I haven't encountered such an issue with 22.

Re: completion buffer - unsuitable column width

[Stefan Monnier]

> 	   (window (get-buffer-window (current-buffer) 0))
> 	   (wwidth (if window (1- (window-width window)) 79))
> ...

> In my case, I use face-remapping-alist to assign different faces for the
> frame default face and the buffer default face.  This causes  "window-width"
> to return a figure that does not indicate how much text  can be fit in one
> line in that window.

> I don't know how to fix this given that there seems to be no way to
> calculate the (average) character width of text with a given face.

That's unfortunate, indeed.

> I haven't encountered such an issue with 22.

The code in Emacs-22, just used a hard-coded 79.


        Stefan

Re: completion buffer - unsuitable column width

[David Reitter]

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

On 2 Mar 2009, at 20:33, Stefan Monnier wrote:

>> I don't know how to fix this given that there seems to be no way to
>> calculate the (average) character width of text with a given face.
>
> That's unfortunate, indeed.
>
>> I haven't encountered such an issue with 22.
>
> The code in Emacs-22, just used a hard-coded 79.

OK, perhaps we could use something like

(if (assq 'default face-remapping-alist) 79  (window-width))

to cover at least the case that I've encountered.

A grep over the source, looking for (window-width), reveals other  
suspicious uses.
I haven't examined it further, but take simple.el, line-move-visual:

       (cond ((eq (nth 1 posn) 'right-fringe) ; overflow-newline-into- 
fringe
	     (setq temporary-goal-column (- (window-width) 1)))

`temporary-goal-column' refers to buffer columns; window-width does not.

Or, abbrev.el:

	(while abbrev-list
	  (if (> (+ first-column 40) (window-width))
	      (progn

first-column seems to refer to the buffer, again.

Or, term.el:
`term-window-width' uses (window-width) and I would assume that this  
(`term-width') is what is used by processes running in the terminal  
(COLUMNS).

Also, there's the longlines-mode case, but I've reported that before  
and we have a suitable replacement thanks to word wrapping.

I think we need something like

"window-buffer-width", giving the average (expected) number of columns  
in a window for text in the default face applicable to the buffer  
shown in a given window.




[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: completion buffer - unsuitable column width

[Stefan Monnier]

> OK, perhaps we could use something like
> (if (assq 'default face-remapping-alist) 79 (window-width))
> to cover at least the case that I've encountered.

I'm not sure it's worth the trouble.

> A grep over the source, looking for (window-width), reveals other
> suspicious uses.

No doubt.  This is just another instance of the long standing problem
that all/most of the code presumes fixed-width fonts (and of a single
width shared by all fonts) as was the case in Emacs<21.

> "window-buffer-width", giving the average (expected) number of columns in
> a window for text in the default face applicable to the buffer shown in
> a given window.

Yes, that could help.


        Stefan

Re: completion buffer - unsuitable column width

[David Reitter]

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

On 3 Mar 2009, at 09:21, Stefan Monnier wrote:

>> A grep over the source, looking for (window-width), reveals other
>> suspicious uses.
>
> No doubt.  This is just another instance of the long standing problem
> that all/most of the code presumes fixed-width fonts (and of a single
> width shared by all fonts) as was the case in Emacs<21.

I suspect that most developers here use a single mono-spaced font for  
most or all their editing...  I started running the NS port of 23 for  
some regular editing now, and I've run into a number of bugs.

>> "window-buffer-width", giving the average (expected) number of  
>> columns in
>> a window for text in the default face applicable to the buffer  
>> shown in
>> a given window.
>
> Yes, that could help.

OK, what is the plan regarding this for 23.1?  Do nothing, add a  
fairly safe workaround as I suggested, or try to implement window- 
buffer-width?

I don't think I can help implementing window-buffer-width in the  
available time; it takes someone who knows the (re)display code fairly  
well I think.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: completion buffer - unsuitable column width

[Stefan Monnier]

>>> "window-buffer-width", giving the average (expected) number of columns in
>>> a window for text in the default face applicable to the buffer shown in
>>> a given window.
>> Yes, that could help.
> OK, what is the plan regarding this for 23.1?  Do nothing, add
> a fairly safe workaround as I suggested, or try to implement window-
> buffer-width?

I think the plan is "do nothing for 23.1".
Tho if someone comes up with an implementation of window-buffer-width,
we may consider it, depending on whether its code looks safe enough.


        Stefan

Re: completion buffer - unsuitable column width

[Dan Nicolaescu]

David Reitter <david.reitter@gmail.com> writes:

  > On 2 Mar 2009, at 20:33, Stefan Monnier wrote:
  > 
  > >> I don't know how to fix this given that there seems to be no way to
  > >> calculate the (average) character width of text with a given face.
  > >
  > > That's unfortunate, indeed.
  > >
  > >> I haven't encountered such an issue with 22.
  > >
  > > The code in Emacs-22, just used a hard-coded 79.
  > 
  > OK, perhaps we could use something like
  > 
  > (if (assq 'default face-remapping-alist) 79  (window-width))
  > 
  > to cover at least the case that I've encountered.
  > 
  > A grep over the source, looking for (window-width), reveals other
  > suspicious uses.
  > I haven't examined it further, but take simple.el, line-move-visual:
  > 
  >       (cond ((eq (nth 1 posn) 'right-fringe) ; overflow-newline-into-
  > fringe
  > 	     (setq temporary-goal-column (- (window-width) 1)))
  > 
  > `temporary-goal-column' refers to buffer columns; window-width does not.
  > 
  > Or, abbrev.el:
  > 
  > 	(while abbrev-list
  > 	  (if (> (+ first-column 40) (window-width))
  > 	      (progn
  > 
  > first-column seems to refer to the buffer, again.
  > 
  > Or, term.el:
  > `term-window-width' uses (window-width) and I would assume that this
  > (`term-width') is what is used by processes running in the terminal
  > (COLUMNS).

term.el relies on using a fixed width font.  Trying to not do so in a
terminal emulator is simply not worth the effort.

Re: completion buffer - unsuitable column width

[Jonathan Rockway]

* On Mon, Mar 02 2009, Stefan Monnier wrote:
>> 	   (window (get-buffer-window (current-buffer) 0))
>> 	   (wwidth (if window (1- (window-width window)) 79))
>> ...
>
>> In my case, I use face-remapping-alist to assign different faces for the
>> frame default face and the buffer default face.  This causes  "window-width"
>> to return a figure that does not indicate how much text  can be fit in one
>> line in that window.
>
>> I don't know how to fix this given that there seems to be no way to
>> calculate the (average) character width of text with a given face.
>
> That's unfortunate, indeed.

This has been bugging me for a while, as there appears to be no way for
lisp code to determine how many pixels wide a string/font pair will
render to.  (I tried a hack involving redisplay and count-screen-lines,
and it works, but is generally horrible, and it only answers the
question "will this line render to more than one screen-line".  I guess
you can just resize the buffer until it wraps, though.  Like I said,
though, this is a horrible hack :)

Anyway, since it appears that the code exists in the font-backend to do
this properly (and some parts of emacs *do* do it properly)... would it
be worthwhile to bind these C functions to Lisp?  I have never worked on
the C parts of emacs... but since this is bugging someone other than me,
it might be worthwhile.

Thoughts?

Regards,
Jonathan Rockway

--
print just => another => perl => hacker => if $,=$"