GNU bug report logs - #12618
24.2.50; Formating of completion candidates in the *Completions* buffer

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12618 in the body.
You can then email your comments to 12618 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.2.50;
	Formating of completion candidates in the *Completions* buffer
Date: Wed, 10 Oct 2012 21:45:09 +0200

severity: minor

Recipe from emacs -Q:
1. Maximize the Emacs (graphical) frame.
2. Type: M-x a u t o - <SPC> <SPC>

I observe that the first <SPC> creates a *Completions* buffer with the
completion candidates formatted in 3 columns, whereas the second <SPC>
reformat those candidates so that the full with of the window is used
(6 columns in my case).

Why the first <SPC> didn't use the full width of the window?  I think it should.


In GNU Emacs 24.2.50.1 (i386-mingw-nt6.1.7601)
 of 2012-10-10 on DANI-PC
Bzr revision: 110500 lekktu <at> gmail.com-20121010155949-32ouh3o4qooiybaj
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -I../../libs/libxpm-3.5.8/include -I../../libs/libxpm-3.5.8/src
 -I../../libs/libpng-1.4.10 -I../../libs/zlib-1.2.6
 -I../../libs/giflib-4.1.4-1/include -I../../libs/jpeg-6b-4/include
 -I../../libs/tiff-3.8.2-1/include
 -I../../libs/libxml2-2.7.8-w32-bin/include/libxml2
 -I../../libs/gnutls-3.0.16/include
 -I../../libs/libiconv-1.14-2-mingw32-dev/include'

Important settings:
  value of $LANG: en_US.UTF8
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

-- 
Dani Moncayo

Message #8 received at 12618 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 12618 <at> debbugs.gnu.org
Subject: Re: bug#12618: 24.2.50;
	Formating of completion candidates in the *Completions* buffer
Date: Wed, 10 Oct 2012 20:40:11 -0400

> I observe that the first <SPC> creates a *Completions* buffer with the
> completion candidates formatted in 3 columns, whereas the second <SPC>
> reformat those candidates so that the full with of the window is used
> (6 columns in my case).

> Why the first <SPC> didn't use the full width of the window?

I think it's because when the text is first laid out, we don't know yet
the dimensions of the window where it will be displayed (actually, that
window doesn't even exist yet), so we assume a default 80-columns.

For the second time, the *Completions* buffer is already displayed in
a window, so the dimensions are available.

> I think it should.

Agreed, which means first display the buffer and then fill it.


        Stefan

Message #11 received at 12618 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 12618 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#12618: 24.2.50;	Formating of completion candidates in the
	*Completions* buffer
Date: Thu, 11 Oct 2012 09:12:59 +0200

>> I observe that the first <SPC> creates a *Completions* buffer with the
>> completion candidates formatted in 3 columns, whereas the second <SPC>
>> reformat those candidates so that the full with of the window is used
>> (6 columns in my case).
>
>> Why the first <SPC> didn't use the full width of the window?
>
> I think it's because when the text is first laid out, we don't know yet
> the dimensions of the window where it will be displayed (actually, that
> window doesn't even exist yet), so we assume a default 80-columns.
>
> For the second time, the *Completions* buffer is already displayed in
> a window, so the dimensions are available.
>
>> I think it should.
>
> Agreed, which means first display the buffer and then fill it.

I thought Tabulated List mode would handle that now.

martin

Message #14 received at 12618 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 12618 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#12618: 24.2.50;
	Formating of completion candidates in the *Completions* buffer
Date: Thu, 11 Oct 2012 08:58:29 -0400

>> Agreed, which means first display the buffer and then fill it.
> I thought Tabulated List mode would handle that now.

Not sure how it could: the mode has no impact on when the buffer is
displayed, and *Completions* doesn't use tabulated list mode (last
I checked).


        Stefan

Message #17 received at 12618 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 12618 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#12618: 24.2.50;	Formating of completion candidates in the
	*Completions* buffer
Date: Fri, 12 Oct 2012 09:21:52 +0200

>>> Agreed, which means first display the buffer and then fill it.
>> I thought Tabulated List mode would handle that now.
>
> Not sure how it could: the mode has no impact on when the buffer is
> displayed, and *Completions* doesn't use tabulated list mode (last
> I checked).

Maybe it should.  IIUC the idea of Tabulated List mode is to handle the
problem described here.

martin

Message #20 received at 12618 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 12618 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#12618: 24.2.50;
	Formating of completion candidates in the *Completions* buffer
Date: Fri, 12 Oct 2012 09:53:50 -0400

>>>> Agreed, which means first display the buffer and then fill it.
>>> I thought Tabulated List mode would handle that now.
>> Not sure how it could: the mode has no impact on when the buffer is
>> displayed, and *Completions* doesn't use tabulated list mode (last
>> I checked).
> Maybe it should.  IIUC the idea of Tabulated List mode is to handle the
> problem described here.

I don't see how Tabulated List Mode would help here.


        Stefan

Message #23 received at 12618 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 12618 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#12618: 24.2.50;	Formating of completion candidates in the
	*Completions* buffer
Date: Sat, 13 Oct 2012 10:16:28 +0200

>> Maybe it should.  IIUC the idea of Tabulated List mode is to handle the
>> problem described here.
>
> I don't see how Tabulated List Mode would help here.

I thought the purpose of Tabulated List mode was to crowd a buffer with
multicolumn entries separated by tabs that could be adjusted according
to the width of a window showing the buffer.  Apparently I was wrong.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.