From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Patch] reformat man buffer on the fly for man.el Date: Wed, 30 Oct 2013 08:27:15 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1383136051 3156 80.91.229.3 (30 Oct 2013 12:27:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Oct 2013 12:27:31 +0000 (UTC) Cc: emacs-devel@gnu.org To: Darren Hoo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 30 13:27:34 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VbUs2-0002tI-FA for ged-emacs-devel@m.gmane.org; Wed, 30 Oct 2013 13:27:34 +0100 Original-Received: from localhost ([::1]:52138 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbUs2-0006Pf-0H for ged-emacs-devel@m.gmane.org; Wed, 30 Oct 2013 08:27:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53069) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbUrr-0006Od-Sm for emacs-devel@gnu.org; Wed, 30 Oct 2013 08:27:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VbUrk-0005PK-JX for emacs-devel@gnu.org; Wed, 30 Oct 2013 08:27:23 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:61093) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbUrk-0005PF-Fj for emacs-devel@gnu.org; Wed, 30 Oct 2013 08:27:16 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFsoXfp/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOkeoFegxOBSiQ X-IPAS-Result: Av4EABK/CFFsoXfp/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOkeoFegxOBSiQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="36661964" Original-Received: from 108-161-119-233.dsl.teksavvy.com (HELO pastel.home) ([108.161.119.233]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 30 Oct 2013 08:27:15 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 53A8C60309; Wed, 30 Oct 2013 08:27:15 -0400 (EDT) In-Reply-To: (Darren Hoo's message of "Wed, 30 Oct 2013 12:24:45 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:164688 Archived-At: > When I lookup manpage occasionally I prefer reading some of it with > windows side by side. cBut when I find myself need to concentrate on one > looked-up manpage, I would like to C-x 1 then reformat the Man buffer > and read it from begin to end. That makes sense, indeed. >> It will also solve the problem that if generating the manpage takes >> a long time, it ends up popping up in your face unexpectedly (since >> you've lost patience in the mean time and moved on to something >> else). > Generating the manpage is so fast for me that this senario has never > occurred to me. Yes, usually it's very quick. But when it's not (e.g. manpage on a remote server that's temporarily down), it hurts. As you say, when it's very quick, there's no point running the process asynchronously, and neither is it useful to only display the buffer after the rendering is done. > One question about the following code: > (if (fboundp 'start-process) > (start-process ...) > (call-process ...)) > Is it due to once in Emacs history when there is no `start-process' but > only `call-process', Can you fill me in? The FreeDOS build of Emacs doesn't support start-process (because FreeDOS doesn't support multiprocessing). Stefan