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: not good proposal: "C-z " reserved for users Date: Sat, 20 Feb 2021 17:54:36 +0300 Message-ID: References: <87ft1xurht.fsf@zoho.eu> <87sg5v13bs.fsf@robertthorpeconsulting.com> <87ft1up9ca.fsf@zoho.eu> 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="14338"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0 (3d08634) (2020-11-07) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 20 15:56:49 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 1lDTgf-0003ct-7m for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 20 Feb 2021 15:56:49 +0100 Original-Received: from localhost ([::1]:35848 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lDTge-0006Pb-85 for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 20 Feb 2021 09:56:48 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58924) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lDTfb-0006NB-0b for help-gnu-emacs@gnu.org; Sat, 20 Feb 2021 09:55:43 -0500 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:51821) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lDTfY-0006cE-GB for help-gnu-emacs@gnu.org; Sat, 20 Feb 2021 09:55:42 -0500 Original-Received: from localhost ([::ffff:41.210.155.197]) (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000001E1C0.00000000603122E9.00004AFF; Sat, 20 Feb 2021 07:55:37 -0700 Mail-Followup-To: help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <87ft1up9ca.fsf@zoho.eu> 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:128139 Archived-At: * Emanuel Berg via Users list for the GNU Emacs text editor [2021-02-18 02:24]: > But the point is, if you have tmux you don't need to suspend > your editor in order to do a routine task. This statement comes because of your personalized use of the editor. Millions of users use it in same way and there may be hundreds of thousands or thousands only using it in somewhat different way then you would ever think. I use Emacs sometimes to accept CGI information. Often I use it to process media information for days, that is where suspending makes sense, as it releases CPU, hard disk, it lessens heating of a computer, maybe it allows for a picture to be mogrified before the process continues to run. > You can just bring forward an empty tmux pane anytime and do > whatever task there instead. You are so right, but that is supervision of various processes, not suspending of a process. Sometimes I do use click and pray methods where I am unsure of the outcome and I invoke program to see if it does what I mean it does, sometimes it does not, that is where suspending is first. In Emacs Ctrl-g is first used, but if Ctrl-g does not work, Ctrl-z may work. It is true that Ctrl-g rarely does not work, but last few months of experience tells me that it did not work as expected on multiple occasions, such as those when memory was taken by Emacs extensively, this still happens sometimes, sometimes when emails were sent in the queue, maybe because of various invokations of outside processes. > The very few times one has to kill processes manually sending > signals the shell tools seem more than enough capable and also > fast enough to do this. That is your perception and I agree it is most of time like that, as you do not have any heavy processing. Other people may have processing that takes resources, that makes it not responsive. > - Sir, we have a problem! The shell tools aren't fast enough! > - Son, suspend the text editor! > - Sir yes sir! hahahahhah But sure, I understand that joke, only that editor is not just editor, it has capabilities of looping and processing so much more than just visible text. I see now that development version included --without-modules, so I just think that new version includes modules by default unlike how it was before. One important module I use is PostgreSQL which is connection to the database. No other editor that I know has possibility to connect to the database. Majority of editors is not even extensible. Emacs Lisp is a true programming language, so almost any kind of processing is available with it. My editor is not editor, it processes things without my supervision, it may run in background for days doing tasks and being not-responsive to me, and I may suspend it during my day time. Not that shell tools are not fast enough, in fact, Emacs can be used as shell tool and in batch mode it does same what Guile, MIT Scheme, SBLC or CLISP or other Lisp similar or other shell scripts do. I have 4080 pages in my website revision system, what if all of them in Org mode that has to be exported to HTML? Emacs is not quite fast, but it is currently the only one that can convert the Org mode to HTML. HTML has to be saved. So the WRS (website revision system) is running in background either by using CLISP as Common Lisp or by using Emacs Lisp, and is processing pages, and invoking externala Emacs Lisp script to process Org to HTML, Org is then saved with its HTML template on the hard disk, and later synchronized with webserver. Before I had 30000 pages, what if all of them are in Org mode, then I would have need much more processing power. But most of them I write in markdown and use discount markdown version which is the fastest one, I know it because I have tested all of the markdown versions and discount was fastest, followed by peg markdown. I know that because I have been processing thousands of web pages and expanding them into HTML for Internet marketing. Editor is not just editor. #!/usr/local/bin/emacs --script ;;;; Good idea from https://joelmccracken.github.io/entries/reading-writing-data-in-emacs-batch-via-stdin-stdout/ (defun org-stdin-to-html-full () "Reads org text body from STDIN and export full HTML" (let ((org-document-content "") this-read) (while (setq this-read (ignore-errors (read-from-minibuffer ""))) (setq org-document-content (concat org-document-content this-read "\n"))) (with-temp-buffer (org-mode) (insert org-document-content) (org-html-export-as-html) (princ (buffer-string))))) (defun org-stdin-to-html-body-only () "Reads org text body from STDIN and export full only body HTML" (let ((org-document-content "") this-read) (while (setq this-read (ignore-errors (read-from-minibuffer ""))) (setq org-document-content (concat org-document-content this-read "\n"))) (with-temp-buffer (org-mode) (insert org-document-content) (org-html-export-as-html nil nil nil t) (princ (buffer-string))))) (org-stdin-to-html-body-only)