unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Tino Calancha <f92capac@gmail.com>
Cc: 22679@debbugs.gnu.org
Subject: bug#22679: 25.0.91; ibuffer-do-shell-command-pipe truncate output
Date: Mon, 22 Aug 2016 12:06:59 -0400	[thread overview]
Message-ID: <jwveg5g6c8q.fsf-monnier+emacsbugs@gnu.org> (raw)
In-Reply-To: <alpine.DEB.2.20.1608212336330.31355@calancha-pc> (Tino Calancha's message of "Sun, 21 Aug 2016 23:37:26 +0900 (JST)")

>> Thanks.  Now that I looked at the rest of the patch I see that you use
>> some kind of after/before hooks, so this approach doesn't really lend
>> itself to extracting into a more generally useful function which could
>> be used by shell-command (and others).
> Improving `shell-command' is out of the scope of my patch.  The goal is
> to avoid that these commands truncate the output: currently the output
> buffer just show the output for the last processed buffer.  The reason
> to that is that original implementation uses `shell-command', which used
> to erase the output buffer between two calls.

I understand.  I do not suggest to improve shell-command.
I suggest instead to extract from shell-command a new Elisp function
which includes the part of shell-command that you need, and then rewrite
shell-command by making it use the new function.

So shell-command would still work exactly as before, but its
implementation would now be spread over 2 functions, the inner one of
which would be useful to other Elisp libraries such as ibuffer.

>> Could you explain what made you use this approach, to see if there might
>> be some way to solve the problem while still making the code more
>> generally useful (and reduce redundancy rather than augment it)?
> I used the hooks (*) because at some point i thought that one user
> setting 'shell-command-not-erase-buffer' to a non-nil value, may
> expect that these ibuffer commands also set the point in the output
> buffer according with 'shell-command-not-erase-buffer'.

Hmm... I now see this new variable.  It has several problems indeed.
The "set the point" part is weird and I'm not sure it makes much sense
to fold it this way into the same var as the "don-t erase" part.

> If we decide that the behaviour of these commands should not depend
> on 'shell-command-not-erase-buffer', then a cleaner fix could be
> as follows:

I think we should first aim at a simple and clean fix, yes.

> -  (shell-command-on-region
> -   (point-min) (point-max) command))
> +  (let ((out-buf (get-buffer-create "*Shell Command Output*")))
> +    (with-current-buffer out-buf (goto-char (point-max)))
> +    (call-process-region (point-min) (point-max)
> +                         shell-file-name nil out-buf nil
> +                         shell-command-switch command)))

Here, for example, I'd expect maybe something like

    (new-shell-command-on-region
     (point-min) (point-max) command))

Maybe with one or two new additional args.  Or maybe

    (let ((out-buf (get-buffer-create shell-command-buffer-name)))
      (with-current-buffer out-buf (goto-char (point-max)))
      (call-shell-on-region (point-min) (point-max)
                            out-buf command)))


-- Stefan





  reply	other threads:[~2016-08-22 16:06 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-15 13:21 bug#22679: 25.0.91; ibuffer-do-shell-command-pipe truncate output Tino Calancha
2016-06-10  5:02 ` Glenn Morris
     [not found]   ` <CAMn5WmYDL0CrDppLc_Vs+EM5CkA_wfdb1z+QCmNj_=v6PiYM-g@mail.gmail.com>
2016-06-10  9:08     ` Tino Calancha
2016-07-05 15:58       ` Glenn Morris
2016-07-05 16:27         ` Tino Calancha
2016-07-09 17:28           ` Glenn Morris
2016-07-13 15:27             ` Stefan Monnier
2016-08-19  8:33               ` Tino Calancha
2016-08-19 13:52                 ` Stefan Monnier
2016-08-20  3:28                   ` Tino Calancha
2016-08-20 10:28                   ` Tino Calancha
2016-08-20 12:46                     ` Stefan Monnier
2016-08-21 14:37                       ` Tino Calancha
2016-08-22 16:06                         ` Stefan Monnier [this message]
2016-08-23 15:08                           ` Tino Calancha
2016-08-24 17:05                             ` Stefan Monnier
2016-08-25  9:39                               ` Tino Calancha
2016-08-25 12:36                                 ` Stefan Monnier
2016-08-25 13:26                                   ` Tino Calancha
2017-01-27  6:26                               ` Tino Calancha
2017-02-03  4:25                                 ` Tino Calancha
2017-02-09  9:24                                   ` Tino Calancha
2016-06-11  3:48   ` C. Calancha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwveg5g6c8q.fsf-monnier+emacsbugs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=22679@debbugs.gnu.org \
    --cc=f92capac@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).