unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#11354: 24.1.50; long lines (214 chars!) in files.el
@ 2012-04-26 16:22 Drew Adams
  2012-04-26 17:09 ` Chong Yidong
  2012-04-26 18:30 ` Stefan Monnier
  0 siblings, 2 replies; 8+ messages in thread
From: Drew Adams @ 2012-04-26 16:22 UTC (permalink / raw)
  To: 11354

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'
 






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

* bug#11354: 24.1.50; long lines (214 chars!) in files.el
  2012-04-26 16:22 bug#11354: 24.1.50; long lines (214 chars!) in files.el Drew Adams
@ 2012-04-26 17:09 ` Chong Yidong
  2012-04-26 17:32   ` Drew Adams
  2012-04-26 18:30 ` Stefan Monnier
  1 sibling, 1 reply; 8+ messages in thread
From: Chong Yidong @ 2012-04-26 17:09 UTC (permalink / raw)
  To: Drew Adams; +Cc: 11354

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





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

* bug#11354: 24.1.50; long lines (214 chars!) in files.el
  2012-04-26 17:09 ` Chong Yidong
@ 2012-04-26 17:32   ` Drew Adams
  2012-04-26 17:46     ` Eli Zaretskii
  0 siblings, 1 reply; 8+ messages in thread
From: Drew Adams @ 2012-04-26 17:32 UTC (permalink / raw)
  To: 'Chong Yidong'; +Cc: 11354

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







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

* bug#11354: 24.1.50; long lines (214 chars!) in files.el
  2012-04-26 17:32   ` Drew Adams
@ 2012-04-26 17:46     ` Eli Zaretskii
  2012-04-26 18:11       ` Drew Adams
  0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2012-04-26 17:46 UTC (permalink / raw)
  To: Drew Adams; +Cc: cyd, 11354

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





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

* bug#11354: 24.1.50; long lines (214 chars!) in files.el
  2012-04-26 17:46     ` Eli Zaretskii
@ 2012-04-26 18:11       ` Drew Adams
  0 siblings, 0 replies; 8+ messages in thread
From: Drew Adams @ 2012-04-26 18:11 UTC (permalink / raw)
  To: 'Eli Zaretskii'; +Cc: cyd, 11354

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






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

* bug#11354: 24.1.50; long lines (214 chars!) in files.el
  2012-04-26 16:22 bug#11354: 24.1.50; long lines (214 chars!) in files.el Drew Adams
  2012-04-26 17:09 ` Chong Yidong
@ 2012-04-26 18:30 ` Stefan Monnier
  2012-04-26 18:49   ` Drew Adams
  1 sibling, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2012-04-26 18:30 UTC (permalink / raw)
  To: Drew Adams; +Cc: 11354

> 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





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

* bug#11354: 24.1.50; long lines (214 chars!) in files.el
  2012-04-26 18:30 ` Stefan Monnier
@ 2012-04-26 18:49   ` Drew Adams
  2012-04-26 20:59     ` Stefan Monnier
  0 siblings, 1 reply; 8+ messages in thread
From: Drew Adams @ 2012-04-26 18:49 UTC (permalink / raw)
  To: 'Stefan Monnier'; +Cc: 11354

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






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

* bug#11354: 24.1.50; long lines (214 chars!) in files.el
  2012-04-26 18:49   ` Drew Adams
@ 2012-04-26 20:59     ` Stefan Monnier
  0 siblings, 0 replies; 8+ messages in thread
From: Stefan Monnier @ 2012-04-26 20:59 UTC (permalink / raw)
  To: Drew Adams; +Cc: 11354

> 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





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

end of thread, other threads:[~2012-04-26 20:59 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-04-26 16:22 bug#11354: 24.1.50; long lines (214 chars!) in files.el Drew Adams
2012-04-26 17:09 ` Chong Yidong
2012-04-26 17:32   ` Drew Adams
2012-04-26 17:46     ` Eli Zaretskii
2012-04-26 18:11       ` Drew Adams
2012-04-26 18:30 ` Stefan Monnier
2012-04-26 18:49   ` Drew Adams
2012-04-26 20:59     ` Stefan Monnier

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