GNU bug report logs -
#30692
list-buffers has hardwired 80 character width from the 80's
Previous Next
Reported by: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Date: Sat, 3 Mar 2018 23:13:02 UTC
Severity: wishlist
Tags: confirmed, fixed
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30692 in the body.
You can then email your comments to 30692 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Sat, 03 Mar 2018 23:13:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
積丹尼 Dan Jacobson <jidanni <at> jidanni.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sat, 03 Mar 2018 23:13:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Sun, 04 Mar 2018 03:41:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 30692 <at> debbugs.gnu.org (full text, mbox):
> From: 積丹尼 Dan Jacobson
> <jidanni <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Mon, 05 Mar 2018 00:24:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 30692 <at> debbugs.gnu.org (full text, mbox):
(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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Mon, 05 Mar 2018 03:36:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 30692 <at> debbugs.gnu.org (full text, mbox):
> From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
> Cc: 30692 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Sat, 14 Apr 2018 19:24:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 30692 <at> debbugs.gnu.org (full text, mbox):
積丹尼 Dan Jacobson <jidanni <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Sun, 15 Apr 2018 10:53:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 30692 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Sun, 15 Apr 2018 12:44:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 30692 <at> debbugs.gnu.org (full text, mbox):
積丹尼 Dan Jacobson <jidanni <at> 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
Added tag(s) confirmed.
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org.
(Sat, 28 Sep 2019 22:02:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Fri, 07 Aug 2020 09:04:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 30692 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Fri, 07 Aug 2020 09:09:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 30692 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 07 Aug 2020 11:03:43 +0200, Lars Ingebrigtsen <larsi <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Fri, 07 Aug 2020 11:45:01 GMT)
Full text and
rfc822 format available.
Message #34 received at 30692 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Fri, 07 Aug 2020 11:03:43 +0200
> Cc: 30692 <at> debbugs.gnu.org
>
> Lars Ingebrigtsen <larsi <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Fri, 07 Aug 2020 11:52:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 30692 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Fri, 07 Aug 2020 12:10:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 30692 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: jidanni <at> jidanni.org, 30692 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Fri, 07 Aug 2020 12:20:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 30692 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Fri, 07 Aug 2020 13:55:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 30692 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: jidanni <at> jidanni.org, 30692 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Sat, 08 Aug 2020 09:40:01 GMT)
Full text and
rfc822 format available.
Message #49 received at 30692 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
Added tag(s) fixed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sat, 08 Aug 2020 09:40:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 28.1, send any further explanations to
30692 <at> debbugs.gnu.org and 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sat, 08 Aug 2020 09:40:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Sat, 08 Aug 2020 09:51:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 30692 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 30692 <at> debbugs.gnu.org, jidanni <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Sat, 08 Aug 2020 10:15:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 30692 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Sat, 08 Aug 2020 10:24:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 30692 <at> debbugs.gnu.org (full text, mbox):
> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 30692 <at> debbugs.gnu.org, jidanni <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Sat, 08 Aug 2020 10:30:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 30692 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Sat, 08 Aug 2020 10:31:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 30692 <at> debbugs.gnu.org (full text, mbox):
"Basil L. Contovounesios" <contovob <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Sat, 08 Aug 2020 10:38:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 30692 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> "Basil L. Contovounesios" <contovob <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Sat, 08 Aug 2020 10:43:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 30692 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 30692 <at> debbugs.gnu.org,
> jidanni <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Sat, 08 Aug 2020 11:01:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 30692 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#30692; Package
emacs.
(Sat, 08 Aug 2020 11:03:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 30692 <at> debbugs.gnu.org (full text, mbox):
"Basil L. Contovounesios" <contovob <at> 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
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 05 Sep 2020 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 232 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.