GNU bug report logs - #22926
24.5; `shell-command', `shell-command-default-error-buffer'

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 22926 in the body.
You can then email your comments to 22926 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.5; `shell-command', `shell-command-default-error-buffer'
Date: Sun, 6 Mar 2016 07:14:47 -0800 (PST)

1. Doc string of `shell-command': Mention that you are prompted for the
   command.

2. `shell-command-default-error-buffer': Make it a user option.

3. In general, orient the doc a bit more toward interactive use.
   Especially since the doc suggests that it is especially for
   interactive use:

    In Elisp, you will often be better served by calling `call-process' or
    `start-process' directly, since it offers more control and does not impose
    the use of a shell (with its need to quote arguments).

4. Also, some lines in the doc string are too long (but not by much: 74
   chars max instead of 70).


In GNU Emacs 24.5.1 (i686-pc-mingw32)
 of 2015-04-11 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/usr --host=i686-pc-mingw32'

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 22926 <at> debbugs.gnu.org
Subject: Re: bug#22926: 24.5;
 `shell-command', `shell-command-default-error-buffer'
Date: Sun, 06 Mar 2016 19:40:04 +0200

> Date: Sun, 6 Mar 2016 07:14:47 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> 
> 1. Doc string of `shell-command': Mention that you are prompted for the
>    command.

Done.

> 2. `shell-command-default-error-buffer': Make it a user option.

Not sure it's necessary.

> 3. In general, orient the doc a bit more toward interactive use.

Upon reading the doc string, it already is: the entire first part of
it is specifically about interactive invocations.  If you have more
specific suggestions, let's hear them.

> 4. Also, some lines in the doc string are too long (but not by much: 74
>    chars max instead of 70).

I don't see how this can be helped, as those lines generally reference
symbols with long names.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22926 <at> debbugs.gnu.org
Subject: RE: bug#22926: 24.5; `shell-command',
 `shell-command-default-error-buffer'
Date: Sun, 6 Mar 2016 13:30:59 -0800 (PST)

> > 1. Doc string of `shell-command': Mention that you are prompted
> >    for the command.
> 
> Done.

Thx.

> > 2. `shell-command-default-error-buffer': Make it a user option.
> 
> Not sure it's necessary.

Why should it be an internal variable?  Did you check how it is used?

> > 4. Also, some lines in the doc string are too long (but not by
> >    much: 74 chars max instead of 70).
> 
> I don't see how this can be helped, as those lines generally
> reference symbols with long names.

Huh?  This is the longest line (but the mailer will perhaps wrap it):

 `start-process' directly, since it offers more control and does not impose

This is the second longest:

 In an interactive call, the variable `shell-command-default-error-buffer'

This the third longest:

 insert output in current buffer.  (This cannot be done asynchronously.)

None of those involves a symbol whose name is 68 or more chars.
They can all be shortened to 70 chars or less.

(All the other lines are 70 chars or less.)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 22926 <at> debbugs.gnu.org
Subject: Re: bug#22926: 24.5; `shell-command',
 `shell-command-default-error-buffer'
Date: Mon, 07 Mar 2016 18:35:48 +0200

> Date: Sun, 6 Mar 2016 13:30:59 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 22926 <at> debbugs.gnu.org
> 
> > > 2. `shell-command-default-error-buffer': Make it a user option.
> > 
> > Not sure it's necessary.
> 
> Why should it be an internal variable?  Did you check how it is used?

I'm just saying it's not obvious we should do that.

> > > 4. Also, some lines in the doc string are too long (but not by
> > >    much: 74 chars max instead of 70).
> > 
> > I don't see how this can be helped, as those lines generally
> > reference symbols with long names.
> 
> Huh?  This is the longest line (but the mailer will perhaps wrap it):
> 
>  `start-process' directly, since it offers more control and does not impose
> 
> This is the second longest:
> 
>  In an interactive call, the variable `shell-command-default-error-buffer'
> 
> This the third longest:
> 
>  insert output in current buffer.  (This cannot be done asynchronously.)

The second one cannot be usefully made shorter (going from 72 columns
to 36 doesn't sound like a move for the best).  And since we have a 72
column line, having a 74-column line in the same doc string doesn't
sound like a disaster to me.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Drew Adams <drew.adams <at> oracle.com>
Cc: 22926 <at> debbugs.gnu.org
Subject: RE: bug#22926: 24.5; `shell-command',
 `shell-command-default-error-buffer'
Date: Mon, 7 Mar 2016 08:52:18 -0800 (PST)

> The second one cannot be usefully made shorter (going from 72
> columns to 36 doesn't sound like a move for the best).

I disagree.  A maximum limit is a maximum limit.  And it can affect
operations and tools such as window/frame fitting.

A 36-column line is not a "disaster".  Even a 2-column line is not
a disaster.

> And since we have a 72 column line, having a 74-column line in the
> same doc string doesn't sound like a disaster to me.

Etc., etc.  And if 74 then why not 76?  And if 76 then why not 78...

The lines should respect the maximum limit.  Simple, clear.  Helps
users both directly and indirectly (e.g. window/frame fitting).

And no, it is not a "disaster" if lines do not respect the rule.
But it is a bug - not all bugs are disasters.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22926 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#22926: 24.5;
 `shell-command', `shell-command-default-error-buffer'
Date: Sun, 01 May 2016 00:55:49 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> 2. `shell-command-default-error-buffer': Make it a user option.
>
> Not sure it's necessary.

I agree.  And I think you covered the other points in this bug report...

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

Previous Next

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