GNU bug report logs - #11354
24.1.50; long lines (214 chars!) in files.el

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 11354 in the body.
You can then email your comments to 11354 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: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.1.50; long lines (214 chars!) in files.el
Date: Thu, 26 Apr 2012 09:22:10 -0700

Emacs Dev makes a big deal about line length whenever anyone submits
code or a patch for inclusion.  Yet you keep using extremely long
lines yourselves.
 
files.el now has a max width of 214 chars!  Supposedly the limit is 80
chars or so.  At least reduce the line lengths to something reasonable.
 
This is not even a code problem (e.g. long function def with many
nesting levels).  It is simply a result of forgetting to use `\' to chop
long strings.  Please DTRT.
 
Here's the longest line, but there are plenty of others that are also
far too long:
 
 
("\\`/etc/\\(?:DIR_COLORS\\|ethers\\|.?fstab\\|.*hosts\\|lesskey\\|login\\.?de\\
(?:fs\\|vperm\\)\\|magic\\|mtab\\|pam\\.d/.*\\|permissions\\(?:\\.d/.+\\)?\\|pro
tocols\\|rpc\\|services\\)\\'" . conf-space-mode)
 
Just chop it:
 
 
("\\`/etc/\\(?:DIR_COLORS\\|ethers\\|.?fstab\\|.*hosts\\|lesskey\\|login\\.?de\
\\(?:fs\\|vperm\\)\\|magic\\|mtab\\|pam\\.d/.*\\|permissions\\(?:\\.d/.+\\)?\
\\|protocols\\|rpc\\|services\\)\\'" . conf-space-mode)


In GNU Emacs 24.1.50.1 (i386-mingw-nt5.1.2600)
 of 2012-04-23 on MARVIN
Bzr revision: 108006
agustin.martin <at> hispalinux.es-20120423103325-xmra3329elgzhmpc
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'
 

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

From: Chong Yidong <cyd <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 11354 <at> debbugs.gnu.org
Subject: Re: bug#11354: 24.1.50; long lines (214 chars!) in files.el
Date: Fri, 27 Apr 2012 01:09:14 +0800

"Drew Adams" <drew.adams <at> oracle.com> writes:

> Emacs Dev makes a big deal about line length whenever anyone submits
> code or a patch for inclusion.  Yet you keep using extremely long
> lines yourselves.
>  
> files.el now has a max width of 214 chars!  Supposedly the limit is 80
> chars or so.  At least reduce the line lengths to something
> reasonable.

Please don't submit frivolous bugs.  Thanks.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> gnu.org>
Cc: 11354 <at> debbugs.gnu.org
Subject: RE: bug#11354: 24.1.50; long lines (214 chars!) in files.el
Date: Thu, 26 Apr 2012 10:32:30 -0700

> Please don't submit frivolous bugs.  Thanks.

Frivolous bugs?

1. I was told clearly by RMS on more than one occasion that I had to shorten
lines in source code I submitted which were only 90 or 100 chars wide.  That was
clearly the GNU Emacs policy - at the time, at least.

2. Lines over 200 chars wide defeat the usefulness of automatically fitting the
frame (or window) to the width of the buffer content.  It requires users who use
such autofitting to then follow up by resizing the frame/window by hand.

Please do not _create_ frivolous bugs.

It is dead simple to chop strings by inserting `\' characters.  Requires no
effort, makes the code more readable, and complies with the GNU policy (such as
it was, at least).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: cyd <at> gnu.org, 11354 <at> debbugs.gnu.org
Subject: Re: bug#11354: 24.1.50; long lines (214 chars!) in files.el
Date: Thu, 26 Apr 2012 20:46:03 +0300

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Thu, 26 Apr 2012 10:32:30 -0700
> Cc: 11354 <at> debbugs.gnu.org
> 
> > Please don't submit frivolous bugs.  Thanks.
> 
> Frivolous bugs?

Yes, frivolous "bugs".  Coding style is not a bug.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: cyd <at> gnu.org, 11354 <at> debbugs.gnu.org
Subject: RE: bug#11354: 24.1.50; long lines (214 chars!) in files.el
Date: Thu, 26 Apr 2012 11:11:48 -0700

> Yes, frivolous "bugs".  Coding style is not a bug.

1. Debatable.  Emacs is about source code, not just executable behavior.  Emacs
users deserve clean, readable code.  The source code is part of Emacs and the
experience of using Emacs.  A big part.  Not to recognize and respect that is to
do a disservice to users.

2. `report-emacs-bug' is not only for bugs, in any case.  It is for improvements
generally, including bugs and enhancement requests.  A suggestion to improve
usability is as valid as a report about a critical security bug, even if the fix
is not as important.

There is no reason for such stubborn resistance to such a reasonable suggestion,
which is after all in line with the GNU policy.  It is trivial to fix this -
takes far less time and effort than your resistance/obstruction.  Is your desire
to improve Emacs or to fight some silly battle?

By declaring this "won't fix" you are effectively deciding that it is _better_
to have such long lines in the code than it is to respect the longstanding
policy of limiting line length.

How so?
a. Because the fix is so trivial.
b. Because leaving such extremely long lines here and there does not discourage
their use elsewhere: it sets a bad example.

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 11354 <at> debbugs.gnu.org
Subject: Re: bug#11354: 24.1.50; long lines (214 chars!) in files.el
Date: Thu, 26 Apr 2012 14:30:15 -0400

> Here's the longest line, but there are plenty of others that are also
> far too long:

Checkout the Bzr, ask for write-access, and fix it yourself.
 
> Just chop it:
 
> ("\\`/etc/\\(?:DIR_COLORS\\|ethers\\|.?fstab\\|.*hosts\\|lesskey\\|login\\.?de\
> \\(?:fs\\|vperm\\)\\|magic\\|mtab\\|pam\\.d/.*\\|permissions\\(?:\\.d/.+\\)?\
> \\|protocols\\|rpc\\|services\\)\\'" . conf-space-mode)

I really dislike long lines, but FWIW the above "chopped up" string, is
no better than the auto-wrapped one, really (i.e. while it does stick to
the letter of the 80-column rule, it doesn't help with the underlying
problem).
In order to do better, you need to use `concat', cut it into logical
units, properly indented, ...


        Stefan

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 11354 <at> debbugs.gnu.org
Subject: RE: bug#11354: 24.1.50; long lines (214 chars!) in files.el
Date: Thu, 26 Apr 2012 11:49:43 -0700

> In order to do better, you need to use `concat', cut it into logical
> units, properly indented, ...

+1 - That's fine too.  The ideal need not be the enemy of the good, however.
Shortening either way means autofitting will not be neutralized perversely,
which is a good thing.

I can understand if someone agrees that shortening such extreme lines is
desirable, but is not a high priority.  But classifying this suggestion as
`won't fix' instead of `wishlist' says in effect that Emacs Dev does NOT think
that shortening such lines is desirable, that it prefers them as they are.

If this had been classified as `wishlist' instead of `won't fix' I would not
have replied at all.

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 11354 <at> debbugs.gnu.org
Subject: Re: bug#11354: 24.1.50; long lines (214 chars!) in files.el
Date: Thu, 26 Apr 2012 16:59:33 -0400

> If this had been classified as `wishlist' instead of `won't fix' I would not
> have replied at all.

It's classified as "you know how to fix it, so please just do it".


        Stefan

Previous Next

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