bug#30692: list-buffers has hardwired 80 character width from the 80's

bug#30692: list-buffers has hardwired 80 character width from the 80's

[積丹尼 Dan Jacobson]

C-x C-b runs the command list-buffers.
It has a hardwired 80 character width from back in the 80's.
Even if one buys a 165 character monitor, it insists on squeezing and
truncating as if we didn't.

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson
> 	<jidanni@jidanni.org>
> Date: Sun, 04 Mar 2018 07:12:10 +0800
> 
> C-x C-b runs the command list-buffers.
> It has a hardwired 80 character width from back in the 80's.
> Even if one buys a 165 character monitor, it insists on squeezing and
> truncating as if we didn't.

Did you try customizing the variables Buffer-menu-name-width,
Buffer-menu-size-width, and Buffer-menu-mode-width?

bug#30692: list-buffers has hardwired 80 character width from the 80's

[積丹尼 Dan Jacobson]

(defcustom Buffer-menu-name-width 19
(defcustom Buffer-menu-size-width 7
(defcustom Buffer-menu-mode-width 16
all need to all be multiplied by a factor,
the-current-terminal-width / 80
right there in that file.
That way they would act correctly for all users.

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
> Cc: 30692@debbugs.gnu.org
> Date: Mon, 05 Mar 2018 08:23:36 +0800
> 
> (defcustom Buffer-menu-name-width 19
> (defcustom Buffer-menu-size-width 7
> (defcustom Buffer-menu-mode-width 16
> all need to all be multiplied by a factor,
> the-current-terminal-width / 80
> right there in that file.

You are assuming that the buffer-menu window will be full-width, but
that assumption is false in general.

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Lars Ingebrigtsen]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> C-x C-b runs the command list-buffers.
> It has a hardwired 80 character width from back in the 80's.
> Even if one buys a 165 character monitor, it insists on squeezing and
> truncating as if we didn't.

It doesn't truncate anything for me when I try it in a wide window.  I
get loooong file names poking out to the right.  I don't think I've done
any customisations.

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

bug#30692: list-buffers has hardwired 80 character width from the 80's

[積丹尼 Dan Jacobson]

LI> It doesn't truncate anything for me when I try it in a wide window.  I
LI> get loooong file names poking out to the right.

Sure the File column has no such problem.

The problem is the Buffer column.

# stty -a|grep columns
speed 38400 baud; rows 39; columns 149; line = 0;
# emacs -q -nw /tmp/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
C-x C-b
CRM Buffer                 Size Mode             File
.   eeeeeeeeeeeeeeee...       0 Fundamental      /tmp/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
    *scratch*               145 Lisp Interaction
 %* *Messages*              901 Messages


The trouble really starts when one has lots of
    *sent mail to dd...     219 Message          ~/News/drafts/drafts/51
    *sent mail to da...     329 Message          ~/News/drafts/drafts/52
    *sent wide reply...    1024 Message          ~/News/drafts/drafts/53

indeed one cannot even see one letter of who the last one was sent to.

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Lars Ingebrigtsen]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> The problem is the Buffer column.

[...]

> The trouble really starts when one has lots of
>     *sent mail to dd...     219 Message          ~/News/drafts/drafts/51
>     *sent mail to da...     329 Message          ~/News/drafts/drafts/52
>     *sent wide reply...    1024 Message          ~/News/drafts/drafts/53
>
> indeed one cannot even see one letter of who the last one was sent to.

Ah, I see.  Yes, that's pretty annoying.  It should expand the buffer
column size based on the window width.

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

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> The problem is the Buffer column.
>
> [...]
>
>> The trouble really starts when one has lots of
>>     *sent mail to dd...     219 Message          ~/News/drafts/drafts/51
>>     *sent mail to da...     329 Message          ~/News/drafts/drafts/52
>>     *sent wide reply...    1024 Message          ~/News/drafts/drafts/53
>>
>> indeed one cannot even see one letter of who the last one was sent to.
>
> Ah, I see.  Yes, that's pretty annoying.  It should expand the buffer
> column size based on the window width.

To recap: Even when the window is very wide, `C-x b' renders with

Buffer-menu-name-width 19

I propose to allow nil as a value here (and default Emacs to it), and
nil would then mean "compute based on window width".  The computation
would end up with 19 as the result if the window is 80 characters long,
but progressively make it longer if the window is wider (according to
some curve), but never make it longer than actual buffer names displayed.

Does this sound reasonable to everybody?

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

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Robert Pluim]

>>>>> On Fri, 07 Aug 2020 11:03:43 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:
    >> Ah, I see.  Yes, that's pretty annoying.  It should expand the buffer
    >> column size based on the window width.

    Lars> To recap: Even when the window is very wide, `C-x b' renders with

    Lars> Buffer-menu-name-width 19

    Lars> I propose to allow nil as a value here (and default Emacs to it), and
    Lars> nil would then mean "compute based on window width".  The computation
    Lars> would end up with 19 as the result if the window is 80 characters long,
    Lars> but progressively make it longer if the window is wider (according to
    Lars> some curve), but never make it longer than actual buffer names displayed.

    Lars> Does this sound reasonable to everybody?

Better. This sounds like "why the hell aren't we doing this already".

+1 from me

Robert

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 07 Aug 2020 11:03:43 +0200
> Cc: 30692@debbugs.gnu.org
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> >> The problem is the Buffer column.
> >
> > [...]
> >
> >> The trouble really starts when one has lots of
> >>     *sent mail to dd...     219 Message          ~/News/drafts/drafts/51
> >>     *sent mail to da...     329 Message          ~/News/drafts/drafts/52
> >>     *sent wide reply...    1024 Message          ~/News/drafts/drafts/53
> >>
> >> indeed one cannot even see one letter of who the last one was sent to.
> >
> > Ah, I see.  Yes, that's pretty annoying.  It should expand the buffer
> > column size based on the window width.
> 
> To recap: Even when the window is very wide, `C-x b' renders with
> 
> Buffer-menu-name-width 19
> 
> I propose to allow nil as a value here (and default Emacs to it), and
> nil would then mean "compute based on window width".  The computation
> would end up with 19 as the result if the window is 80 characters long,
> but progressively make it longer if the window is wider (according to
> some curve), but never make it longer than actual buffer names displayed.

I don't understand the plan, sorry.  Buffer-menu has 2 potentially
long parts: the buffer name and the file name.  I don't understand the
details of your proposal, and thus cannot figure out what will happen
when displaying the full buffer name and the full file name exceeds
the window-width.

Can you describe the proposal in more detail?

In general, I'd say that we should be smarter about how we produce the
shortened versions of these long names, because I think otherwise
whatever we do there will be a scenario where the important part(s)
are hidden.  Which really is the single interesting part of this bug
report, if you ignore the "from the 80's" part, which is just a
teaser.

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't understand the plan, sorry.  Buffer-menu has 2 potentially
> long parts: the buffer name and the file name.  I don't understand the
> details of your proposal, and thus cannot figure out what will happen
> when displaying the full buffer name and the full file name exceeds
> the window-width.
>
> Can you describe the proposal in more detail?

It wouldn't change how the file name is displayed at all -- it would
continue to be truncated by the window width (i.e., it "pokes out").

As the "formula" today is that the file name takes about half the window,
my proposed change would continue to keep that ratio (at least).  That
is, if you make the window 100 characters wide, the buffer name would
grow from 19 to...  (let's see)...  25-ish, and the file's visible area
would increase from 40-ish to 55-ish.

> In general, I'd say that we should be smarter about how we produce the
> shortened versions of these long names, because I think otherwise
> whatever we do there will be a scenario where the important part(s)
> are hidden.  Which really is the single interesting part of this bug
> report, if you ignore the "from the 80's" part, which is just a
> teaser.

That would also be nice, but I think kinda orthogonal to this issue?

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

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: jidanni@jidanni.org,  30692@debbugs.gnu.org
> Date: Fri, 07 Aug 2020 13:51:40 +0200
> 
> It wouldn't change how the file name is displayed at all -- it would
> continue to be truncated by the window width (i.e., it "pokes out").
> 
> As the "formula" today is that the file name takes about half the window,
> my proposed change would continue to keep that ratio (at least).  That
> is, if you make the window 100 characters wide, the buffer name would
> grow from 19 to...  (let's see)...  25-ish, and the file's visible area
> would increase from 40-ish to 55-ish.

So, as one makes the window wider, instead of using the additional
space to display more of the file name, we will use it to display more
of the buffer name?  Even if none of the buffer names is truncated?

> > In general, I'd say that we should be smarter about how we produce the
> > shortened versions of these long names, because I think otherwise
> > whatever we do there will be a scenario where the important part(s)
> > are hidden.  Which really is the single interesting part of this bug
> > report, if you ignore the "from the 80's" part, which is just a
> > teaser.
> 
> That would also be nice, but I think kinda orthogonal to this issue?

Not to me: if we could find a way to show the buffers in a way that
makes the differences between similar names apparent, maybe there
wouldn't be a need to make the buffer name wider.  But it's fine with
me not to handle the latter (and harder) issue for now.

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> It wouldn't change how the file name is displayed at all -- it would
>> continue to be truncated by the window width (i.e., it "pokes out").
>> 
>> As the "formula" today is that the file name takes about half the window,
>> my proposed change would continue to keep that ratio (at least).  That
>> is, if you make the window 100 characters wide, the buffer name would
>> grow from 19 to...  (let's see)...  25-ish, and the file's visible area
>> would increase from 40-ish to 55-ish.
>
> So, as one makes the window wider, instead of using the additional
> space to display more of the file name, we will use it to display more
> of the buffer name?

No, in my calculations above, we increase the width by 20 columns, and
give 5 to the buffer name and 15 to the file name.  (Ish.)

> Even if none of the buffer names is truncated?

No, like I said in the first mail -- it won't be increased beyond the
length of the longest item in the buffer name column.

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

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: jidanni@jidanni.org,  30692@debbugs.gnu.org
> Date: Fri, 07 Aug 2020 14:19:32 +0200
> 
> > So, as one makes the window wider, instead of using the additional
> > space to display more of the file name, we will use it to display more
> > of the buffer name?
> 
> No, in my calculations above, we increase the width by 20 columns, and
> give 5 to the buffer name and 15 to the file name.  (Ish.)
> 
> > Even if none of the buffer names is truncated?
> 
> No, like I said in the first mail -- it won't be increased beyond the
> length of the longest item in the buffer name column.

SGTM, thanks.

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> No, like I said in the first mail -- it won't be increased beyond the
>> length of the longest item in the buffer name column.
>
> SGTM, thanks.

I've now implemented this.

I added an autoload cookie to seq-max, since I'm using that in the
patch, which requires a rebuild of loaddefs.el to get rid of the
compilation warning.  Is there anything a check-in can do to trigger a
rebuild of that file automatically?

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

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 30692@debbugs.gnu.org,  jidanni@jidanni.org
> Date: Sat, 08 Aug 2020 11:39:18 +0200
> 
> I added an autoload cookie to seq-max, since I'm using that in the
> patch, which requires a rebuild of loaddefs.el to get rid of the
> compilation warning.  Is there anything a check-in can do to trigger a
> rebuild of that file automatically?

I don't know, I sometimes need to "make autoloads" manually myself.

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've now implemented this.

Thanks.

> I added an autoload cookie to seq-max, since I'm using that in the
> patch,

You could also just use (apply #'max 0 (mapcar ...)) instead of
(seq-max (mapcar ...)), which will barf on the empty list.

> which requires a rebuild of loaddefs.el to get rid of the
> compilation warning.  Is there anything a check-in can do to trigger a
> rebuild of that file automatically?

Like send an automated email to Glenn? :)

-- 
Basil

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: Eli Zaretskii <eliz@gnu.org>,  30692@debbugs.gnu.org,  jidanni@jidanni.org
> Date: Sat, 08 Aug 2020 11:13:53 +0100
> 
> > which requires a rebuild of loaddefs.el to get rid of the
> > compilation warning.  Is there anything a check-in can do to trigger a
> > rebuild of that file automatically?
> 
> Like send an automated email to Glenn? :)

I think you had ldefs-boot.el in mind.

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Like send an automated email to Glenn? :)
>
> I think you had ldefs-boot.el in mind.

Oh, so should that be a thing we should do after committing a new
;;;###autoload?  Make the loaddefs.el file, and copy it over to
ldefs-boot.el and check it in?

It's always been kinda vague to me how that bit of the building process
actually worked...

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

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>,  30692@debbugs.gnu.org,
>   jidanni@jidanni.org
> Date: Sat, 08 Aug 2020 12:28:52 +0200
> 
> > I think you had ldefs-boot.el in mind.
> 
> Oh, so should that be a thing we should do after committing a new
> ;;;###autoload?  Make the loaddefs.el file, and copy it over to
> ldefs-boot.el and check it in?

No, I think Glenn has a script set up which does that from time to
time.

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Oh, so should that be a thing we should do after committing a new
>> ;;;###autoload?  Make the loaddefs.el file, and copy it over to
>> ldefs-boot.el and check it in?
>
> No, I think Glenn has a script set up which does that from time to
> time.

Right.  But in the meantime people who build will get warnings, which is
annoying...

I see that others check in that file from time to time -- does that
throw a spanner into Glenn's scripts?

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

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Lars Ingebrigtsen]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

>> I added an autoload cookie to seq-max, since I'm using that in the
>> patch,
>
> You could also just use (apply #'max 0 (mapcar ...)) instead of
> (seq-max (mapcar ...)), which will barf on the empty list.

Hm...  it it possible here for that list to be empty?  I thought not...

I just find the seq-* functions to be more readable than (apply ...),
but I can change it to that if that's preferred here.

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

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>>> I added an autoload cookie to seq-max, since I'm using that in the
>>> patch,
>>
>> You could also just use (apply #'max 0 (mapcar ...)) instead of
>> (seq-max (mapcar ...)), which will barf on the empty list.
>
> Hm...  it it possible here for that list to be empty?  I thought not...
>
> I just find the seq-* functions to be more readable than (apply ...),
> but I can change it to that if that's preferred here.

-shrug- I just suggested it as a way of punting the autoload issues.

-- 
Basil

bug#30692: list-buffers has hardwired 80 character width from the 80's

[Lars Ingebrigtsen]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

>> Hm...  it it possible here for that list to be empty?  I thought not...
>>
>> I just find the seq-* functions to be more readable than (apply ...),
>> but I can change it to that if that's preferred here.
>
> -shrug- I just suggested it as a way of punting the autoload issues.

And it is indeed possible for that list to be empty, so I've changed the
code to your suggestion.

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