unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#12618: 24.2.50; Formating of completion candidates in the *Completions* buffer
@ 2012-10-10 19:45 Dani Moncayo
  2012-10-11  0:40 ` Stefan Monnier
  0 siblings, 1 reply; 7+ messages in thread
From: Dani Moncayo @ 2012-10-10 19:45 UTC (permalink / raw)
  To: 12618

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@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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#12618: 24.2.50; Formating of completion candidates in the *Completions* buffer
  2012-10-10 19:45 bug#12618: 24.2.50; Formating of completion candidates in the *Completions* buffer Dani Moncayo
@ 2012-10-11  0:40 ` Stefan Monnier
  2012-10-11  7:12   ` martin rudalics
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2012-10-11  0:40 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 12618

> 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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#12618: 24.2.50; Formating of completion candidates in the *Completions* buffer
  2012-10-11  0:40 ` Stefan Monnier
@ 2012-10-11  7:12   ` martin rudalics
  2012-10-11 12:58     ` Stefan Monnier
  0 siblings, 1 reply; 7+ messages in thread
From: martin rudalics @ 2012-10-11  7:12 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 12618

 >> 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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#12618: 24.2.50; Formating of completion candidates in the *Completions* buffer
  2012-10-11  7:12   ` martin rudalics
@ 2012-10-11 12:58     ` Stefan Monnier
  2012-10-12  7:21       ` martin rudalics
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2012-10-11 12:58 UTC (permalink / raw)
  To: martin rudalics; +Cc: 12618

>> 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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#12618: 24.2.50; Formating of completion candidates in the *Completions* buffer
  2012-10-11 12:58     ` Stefan Monnier
@ 2012-10-12  7:21       ` martin rudalics
  2012-10-12 13:53         ` Stefan Monnier
  0 siblings, 1 reply; 7+ messages in thread
From: martin rudalics @ 2012-10-12  7:21 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 12618

 >>> 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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#12618: 24.2.50; Formating of completion candidates in the *Completions* buffer
  2012-10-12  7:21       ` martin rudalics
@ 2012-10-12 13:53         ` Stefan Monnier
  2012-10-13  8:16           ` martin rudalics
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2012-10-12 13:53 UTC (permalink / raw)
  To: martin rudalics; +Cc: 12618

>>>> 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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#12618: 24.2.50; Formating of completion candidates in the *Completions* buffer
  2012-10-12 13:53         ` Stefan Monnier
@ 2012-10-13  8:16           ` martin rudalics
  0 siblings, 0 replies; 7+ messages in thread
From: martin rudalics @ 2012-10-13  8:16 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 12618

 >> 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





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2012-10-13  8:16 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-10 19:45 bug#12618: 24.2.50; Formating of completion candidates in the *Completions* buffer Dani Moncayo
2012-10-11  0:40 ` Stefan Monnier
2012-10-11  7:12   ` martin rudalics
2012-10-11 12:58     ` Stefan Monnier
2012-10-12  7:21       ` martin rudalics
2012-10-12 13:53         ` Stefan Monnier
2012-10-13  8:16           ` martin rudalics

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).