From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.help Subject: Re: [solved]: Re: Finding last *Async Shell Command* buffer? Date: Fri, 26 Mar 2021 11:55:52 +0300 Message-ID: References: <87k0puihrd.fsf@robertthorpeconsulting.com> <838s6aqtlv.fsf@gnu.org> <8335wiqrek.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36683"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0.6 (2021-03-06) Cc: help-gnu-emacs@gnu.org To: Eli Zaretskii Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Fri Mar 26 09:59:24 2021 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lPiJN-0009Pj-Ts for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 26 Mar 2021 09:59:21 +0100 Original-Received: from localhost ([::1]:46308 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lPiJM-0006n9-U8 for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 26 Mar 2021 04:59:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39458) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lPiJ0-0006n0-3W for help-gnu-emacs@gnu.org; Fri, 26 Mar 2021 04:58:58 -0400 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:55489) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lPiIy-0002iU-2C; Fri, 26 Mar 2021 04:58:57 -0400 Original-Received: from localhost ([::ffff:41.210.143.10]) (AUTH: PLAIN securesender, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000001E0AB.00000000605DA249.00005A8C; Fri, 26 Mar 2021 01:58:48 -0700 Mail-Followup-To: Eli Zaretskii , help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <8335wiqrek.fsf@gnu.org> Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:128610 Archived-At: * Eli Zaretskii [2021-03-26 10:57]: > What happens if that buffer was meanwhile killed? If it gets killed, new buffer with same name is created. But if it really gets killed, most probably I killed it by using the key binding from that function, like `C-c l'. Purpose is to see output of async command, so if there is no output to be seen that new buffer is created does not matter. No, it is not elegant, it is very personal. > Personally, I find it un-Emacsy to write a wrapper command each time > you want to manipulate the results of an existing command. Emacs > provides hooks for that very purpose, so it's best to use those > instead of inventing a new command each time you need something like > that. Yes, I agree. Coming from my experience with databases, for me it would be most usable if buffers have their creation time recorded, as that way would be easy to find the last async buffer, or others. In this specific example users can change the async buffer name or Elisp programs could change last async buffer names. There is no easy and default way how to get last buffer or last few to look into outputs easily. It requires listing, inspecting. But it is terrible when there are many, as the generate-new-buffer will create the next available number in a series and not the next increased number compared to previous buffer. Maybe the function `get-buffer-create' could be changed to increase the number of newly created buffers instead of just taking some of empty numbers in a series? For end users I do not think that would make any difference, as the added buffer number is not interactively influencing users. What do you think about that change? I would not know how to do it in C. > Redefining a key binding each time you run an async command is also > ... inelegant. Ah, definitely.