* bug#22926: 24.5; `shell-command', `shell-command-default-error-buffer'
[not found] ` <<83ziubv72j.fsf@gnu.org>
@ 2016-03-06 21:30 ` Drew Adams
2016-03-07 16:35 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Drew Adams @ 2016-03-06 21:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22926
> > 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.)
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#22926: 24.5; `shell-command', `shell-command-default-error-buffer'
2016-03-06 21:30 ` bug#22926: 24.5; `shell-command', `shell-command-default-error-buffer' Drew Adams
@ 2016-03-07 16:35 ` Eli Zaretskii
0 siblings, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2016-03-07 16:35 UTC (permalink / raw)
To: Drew Adams; +Cc: 22926
> Date: Sun, 6 Mar 2016 13:30:59 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 22926@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <<<97b7c9cf-83fc-4d10-8f2b-836132fcc5ca@default>]
* bug#22926: 24.5; `shell-command', `shell-command-default-error-buffer'
@ 2016-03-06 15:14 Drew Adams
2016-03-06 17:40 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Drew Adams @ 2016-03-06 15:14 UTC (permalink / raw)
To: 22926
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'
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#22926: 24.5; `shell-command', `shell-command-default-error-buffer'
2016-03-06 15:14 Drew Adams
@ 2016-03-06 17:40 ` Eli Zaretskii
2016-04-30 22:55 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2016-03-06 17:40 UTC (permalink / raw)
To: Drew Adams; +Cc: 22926
> Date: Sun, 6 Mar 2016 07:14:47 -0800 (PST)
> From: Drew Adams <drew.adams@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-04-30 22:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <<97b7c9cf-83fc-4d10-8f2b-836132fcc5ca@default>
[not found] ` <<83ziubv72j.fsf@gnu.org>
2016-03-06 21:30 ` bug#22926: 24.5; `shell-command', `shell-command-default-error-buffer' Drew Adams
2016-03-07 16:35 ` Eli Zaretskii
[not found] <<<97b7c9cf-83fc-4d10-8f2b-836132fcc5ca@default>
[not found] ` <<<83ziubv72j.fsf@gnu.org>
[not found] ` <<4e20bee2-3a48-44d1-8501-f19ccc660b0a@default>
[not found] ` <<834mciuty3.fsf@gnu.org>
2016-03-07 16:52 ` Drew Adams
2016-03-06 15:14 Drew Adams
2016-03-06 17:40 ` Eli Zaretskii
2016-04-30 22:55 ` Lars Ingebrigtsen
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).