bug#11354: 24.1.50; long lines (214 chars!) in files.el

bug#11354: 24.1.50; long lines (214 chars!) in files.el

[Drew Adams]

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

bug#11354: 24.1.50; long lines (214 chars!) in files.el

[Chong Yidong]

"Drew Adams" <drew.adams@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.

bug#11354: 24.1.50; long lines (214 chars!) in files.el

[Drew Adams]

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

bug#11354: 24.1.50; long lines (214 chars!) in files.el

[Eli Zaretskii]

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

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

bug#11354: 24.1.50; long lines (214 chars!) in files.el

[Drew Adams]

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

bug#11354: 24.1.50; long lines (214 chars!) in files.el

[Stefan Monnier]

> 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

bug#11354: 24.1.50; long lines (214 chars!) in files.el

[Drew Adams]

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

bug#11354: 24.1.50; long lines (214 chars!) in files.el

[Stefan Monnier]

> 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