GNU bug report logs - #12098
Optionally support synchronous operation for `M-x man'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12098 in the body.
You can then email your comments to 12098 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: bug-emacs <bug-emacs <at> gnu.org>
Subject: How to trap errors in man?
Date: Tue, 31 Jul 2012 12:53:43 +0100

In a discussion on gnu-prog-discuss today, there was an attempt to
script Emacs as a standalone info reader. It was also desired to make
it format man pages (like the standalone info reader) for programs
that don't have an info manual.

The initial script to do this used woman, but when there are man pages
in multiple sections with the same name, woman prompts for completion,
unlike the standalone info reader, which, like man, just fetches the
"first" man page of the right name.

Hence, I tried to adapt the script to use man instead of woman, but I
found it impossible, because of the way that man works asynchronously,
to trap the error when no man page is found. The problem is that the
error is trapped already, in Man-bgproc-sentinel, so the caller of
"man" cannot find out whether the call was successful.

Personally, I'd just rip out all the asynchronous stuff and make "man"
synchronous (I have man set to "bully" mode in my setup), but I am
guessing that would be an unpopular change, so I'm wondering if
there's some other way to make it possible to use man synchronously
and/or allow man's caller to find out about errors.

-- 
http://rrt.sc3d.org

Message #8 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: Acknowledgement (How to trap errors in man?)
Date: Tue, 31 Jul 2012 14:36:33 +0100

I found a workaround: unbind start-process, which causes man to be run
synchronously, which means that there's no process-sentinel to trap
any error, so the caller can trap it.

Of course, this works for my application (a wrapper for standalone
Emacs), but it's not so good for use in code that is supposed to work
in a normal Emacs session.

-- 
http://rrt.sc3d.org

Message #11 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: Acknowledgement (How to trap errors in man?)
Date: Tue, 31 Jul 2012 19:27:51 +0300

> Date: Tue, 31 Jul 2012 14:36:33 +0100
> From: Reuben Thomas <rrt <at> sc3d.org>
> 
> I found a workaround: unbind start-process, which causes man to be run
> synchronously, which means that there's no process-sentinel to trap
> any error, so the caller can trap it.

Please, when you have time, donate $0.02 to the MSDOS port of Emacs,
which made this possible.

Message #14 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 01 Aug 2012 03:15:40 +0300

> In a discussion on gnu-prog-discuss today, there was an attempt to
> script Emacs as a standalone info reader. It was also desired to make
> it format man pages (like the standalone info reader) for programs
> that don't have an info manual.

The Emacs Info reader can format man pages with the help
of info-man.el.

> Personally, I'd just rip out all the asynchronous stuff and make "man"
> synchronous (I have man set to "bully" mode in my setup), but I am
> guessing that would be an unpopular change,

Yes, the delay when the whole session is freezing during formatting would
be undesirable.  The current situation with asynchronous popping up buffers
is not perfect either.  In bug#9084 we are trying to improve this by
modifying man.el to work more like async shell commands.

> so I'm wondering if there's some other way to make it possible to use
> man synchronously and/or allow man's caller to find out about errors.

You can use `Man-cooked-hook' that is called at the end of
`Man-bgproc-sentinel'.  In this hook you can check whether the value of
`Man-page-list' is nil.

Message #17 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 1 Aug 2012 01:38:17 +0100

On 1 August 2012 01:15, Juri Linkov <juri <at> jurta.org> wrote:
>
> The Emacs Info reader can format man pages with the help
> of info-man.el.

This doesn't appear to be standard.

>> Personally, I'd just rip out all the asynchronous stuff and make "man"
>> synchronous (I have man set to "bully" mode in my setup), but I am
>> guessing that would be an unpopular change,
>
> Yes, the delay when the whole session is freezing during formatting would
> be undesirable.

There are plenty of things that freeze the session for much longer
than the fraction of a second it takes to format most man pages! Even
bash(1) only takes about a second. What workflow do you have in mind
where a user starts a man page and then does something else for at
most a few seconds? The idea of requesting some documentation and then
doing something else for a few seconds is a bit odd to me…

>  In bug#9084 we are trying to improve this by
> modifying man.el to work more like async shell
> commands.

Are you sure about that bug number? I looked and it seems to be about
window layout.

> You can use `Man-cooked-hook' that is called at the end of
> `Man-bgproc-sentinel'.  In this hook you can check whether the value of
> `Man-page-list' is nil.

I can't see how to use this to communicate back to a particular caller
that man failed; help?

-- 
http://rrt.sc3d.org

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 01 Aug 2012 10:27:52 +0200

Juri Linkov <juri <at> jurta.org> writes:

>> In a discussion on gnu-prog-discuss today, there was an attempt to
>> script Emacs as a standalone info reader. It was also desired to make
>> it format man pages (like the standalone info reader) for programs
>> that don't have an info manual.
>
> The Emacs Info reader can format man pages with the help
> of info-man.el.
>
>> Personally, I'd just rip out all the asynchronous stuff and make "man"
>> synchronous (I have man set to "bully" mode in my setup), but I am
>> guessing that would be an unpopular change,
>
> Yes, the delay when the whole session is freezing during formatting would
> be undesirable.  The current situation with asynchronous popping up buffers
> is not perfect either.  In bug#9084 we are trying to improve this by
> modifying man.el to work more like async shell commands.
`Man-getpage-in-background' use (if (fboundp 'start-process) to check if
it start an asynchronous process or not.
Why in Emacs-24 `start-process' would not exists?
Why instead don't you add an optional arg to `Man-getpage-in-background'
to make it synchronous?
It would be instead of (if (fboundp 'start-process):
(if synchronous start-man-synchronously start-man-async
This would allow to make an user variable that allow to choose if man is
async or not.
It is simple and change nothing to actual code.

>> so I'm wondering if there's some other way to make it possible to use
>> man synchronously and/or allow man's caller to find out about errors.
>
> You can use `Man-cooked-hook' that is called at the end of
> `Man-bgproc-sentinel'.  In this hook you can check whether the value of
> `Man-page-list' is nil.
>
>
>
>

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Message #23 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 01 Aug 2012 11:23:30 +0300

> There are plenty of things that freeze the session for much longer
> than the fraction of a second it takes to format most man pages! Even
> bash(1) only takes about a second.

You are right, the largest man page `man bash' takes just 2 sec to format,
so perhaps it makes no sense to run the man command asynchronously nowadays.

The patch below introduces a new variable `Man-async' whose value
could be set to nil to run `man' synchronously.

> Are you sure about that bug number? I looked and it seems to be about
> window layout.

That's right, currently the async mode of man has its peculiarities:
it arranges window layouts after formatting is done, so formatting
can't fit into window layout.

So perhaps we should have two asynchronous modes:
1. delay changes in window configuration
   until the process is finished and man page is formatted.
2. prepare window layout before formatting;

I'm still not sure whether we need the former for backward compatibility,
so `Man-async' could have a special value for it.

> I can't see how to use this to communicate back to a particular caller
> that man failed; help?

I don't know if it's possible with lack of multi-threading
to yield to the command loop while waiting for the process output.
But with the following patch you can run `man' synchronously
by using just `(let ((Man-async nil)) (man "bash"))' when its
default value is not nil.

=== modified file 'lisp/man.el'
--- lisp/man.el	2012-07-11 23:13:41 +0000
+++ lisp/man.el	2012-08-01 08:23:10 +0000
@@ -144,6 +144,20 @@ (defcustom Man-reverse-face 'highlight
   :type 'face
   :group 'man)
 
+(defcustom Man-async nil
+  "Synchronicity of the manpage command.
+If nil, run the manpage command synchronously.
+If t, run the manpage command asynchronously
+preparing output windows before the process is started.
+If the value is `delayed', run the manpage command
+asynchronously but delay changes in window configuration
+until the process is finished and man page is formatted."
+  :type '(choice (const :tag "Synchronous" nil)
+                 (const :tag "Asynchronous" t)
+                 (const :tag "Delayed" delayed))
+  :group 'man
+  :version "24.2")
+
 ;; Use the value of the obsolete user option Man-notify, if set.
 (defcustom Man-notify-method (if (boundp 'Man-notify) Man-notify 'friendly)
   "Selects the behavior when manpage is ready.
@@ -904,16 +920,37 @@ (defun Man-getpage-in-background (topic)
 Return the buffer in which the manpage will appear."
   (let* ((man-args topic)
 	 (bufname (concat "*Man " man-args "*"))
-	 (buffer  (get-buffer bufname)))
+	 (buffer  (get-buffer bufname))
+	 (procbufname (concat " " bufname))
+	 procbuffer)
     (if buffer
 	(Man-notify-when-ready buffer)
       (require 'env)
-      (message "Invoking %s %s in the background" manual-program man-args)
-      (setq buffer (generate-new-buffer bufname))
-      (with-current-buffer buffer
-	(setq buffer-undo-list t)
-	(setq Man-original-frame (selected-frame))
-	(setq Man-arguments man-args))
+      (cond
+       ((eq Man-async 'delayed)
+	(message "Invoking %s %s in the background" manual-program man-args)
+	(setq buffer (generate-new-buffer bufname))
+	(with-current-buffer buffer
+	  (setq buffer-undo-list t)
+	  (setq Man-original-frame (selected-frame))
+	  (setq Man-arguments man-args)))
+       (t
+	(setq buffer (generate-new-buffer bufname))
+	(setq procbuffer (generate-new-buffer procbufname))
+	;; Display empty output buffer.
+	(unless (memq Man-notify-method '(polite quiet meek))
+	  (Man-notify-when-ready buffer))
+	(with-current-buffer buffer
+	  (insert (format "Invoking %s %s in the background\n"
+			  manual-program man-args))
+	  (setq buffer-undo-list t)
+	  (setq Man-original-frame (selected-frame))
+	  (setq Man-arguments man-args))
+	(with-current-buffer procbuffer
+	  (setq buffer-undo-list t)
+	  (setq Man-original-frame (selected-frame))
+	  (setq Man-arguments man-args))))
+
       (let ((process-environment (copy-sequence process-environment))
 	    ;; The following is so Awk script gets \n intact
 	    ;; But don't prevent decoding of the outside.
@@ -952,16 +989,26 @@ (defun Man-getpage-in-background (topic)
 			     (cond
 			      ((and (integerp Man-width) (> Man-width 0))
 			       Man-width)
-			      (Man-width (frame-width))
-			      ((window-width))))))
+			      (Man-width
+			       (if (eq Man-async 'delayed)
+				   (frame-width)
+				 (with-selected-window (get-buffer-window
+							buffer t)
+				   (frame-width))))
+			      (t
+			       (if (eq Man-async 'delayed)
+				   (window-width)
+				 (with-selected-window (get-buffer-window
+							buffer t)
+				   (window-width))))))))
 	(setenv "GROFF_NO_SGR" "1")
 	;; Since man-db 2.4.3-1, man writes plain text with no escape
 	;; sequences when stdout is not a tty.	In 2.5.0, the following
 	;; env-var was added to allow control of this (see Debian Bug#340673).
 	(setenv "MAN_KEEP_FORMATTING" "1")
-	(if (fboundp 'start-process)
+	(if (and Man-async (fboundp 'start-process))
 	    (set-process-sentinel
-	     (start-process manual-program buffer
+	     (start-process manual-program (if (eq Man-async 'delayed) buffer procbuffer)
 			    (if (memq system-type '(cygwin windows-nt))
 				shell-file-name
 			      "sh")
@@ -969,7 +1016,7 @@ (defun Man-getpage-in-background (topic)
 			    (format (Man-build-man-command) man-args))
 	     'Man-bgproc-sentinel)
 	  (let ((exit-status
-		 (call-process shell-file-name nil (list buffer nil) nil
+		 (call-process shell-file-name nil (list procbuffer nil) nil
 			       shell-command-switch
 			       (format (Man-build-man-command) man-args)))
 		(msg ""))
@@ -980,7 +1027,7 @@ (defun Man-getpage-in-background (topic)
 			   (format "exited abnormally with code %d"
 				   exit-status)))
 		(setq msg exit-status))
-	    (Man-bgproc-sentinel bufname msg)))))
+	    (Man-bgproc-sentinel procbufname msg)))))
     buffer))
 
 (defun Man-notify-when-ready (man-buffer)
@@ -1216,16 +1263,18 @@ (defun Man-bgproc-sentinel (process msg)
 synchronously, PROCESS is the name of the buffer where the manpage
 command is run.  Second argument MSG is the exit message of the
 manpage command."
-  (let ((Man-buffer (if (stringp process) (get-buffer process)
-		      (process-buffer process)))
-	(delete-buff nil)
-	(err-mess nil))
+  (let* ((Man-procbuffer (if (stringp process) (get-buffer process)
+			   (process-buffer process)))
+	 (Man-buffer (get-buffer (replace-regexp-in-string
+				  "\\` " "" (buffer-name Man-procbuffer))))
+	 (delete-buff nil)
+	 (err-mess nil))
 
     (if (null (buffer-name Man-buffer)) ;; deleted buffer
 	(or (stringp process)
 	    (set-process-buffer process nil))
 
-      (with-current-buffer Man-buffer
+      (with-current-buffer Man-procbuffer
 	(let ((case-fold-search nil))
 	  (goto-char (point-min))
 	  (cond ((or (looking-at "No \\(manual \\)*entry for")
@@ -1261,11 +1310,17 @@ (defun Man-bgproc-sentinel (process msg)
               (Man-fontify-manpage)
             (Man-cleanup-manpage))
 
+	  (unless (eq Man-async 'delayed)
+	    (copy-to-buffer Man-buffer (point-min) (point-max))))))
+
+      (unless delete-buff
+	(with-current-buffer (if (eq Man-async 'delayed) Man-procbuffer Man-buffer)
           (run-hooks 'Man-cooked-hook)
 	  (Man-mode)
 
@@ -1279,11 +1342,13 @@ (defun Man-bgproc-sentinel (process msg)
 	;; Man-notify-when-ready because it may switch buffers.
 
 	(if (not delete-buff)
-	    (Man-notify-when-ready Man-buffer))
+	    (when (or (eq Man-async 'delayed)
+		      (memq Man-notify-method '(polite quiet meek)))
+	      (Man-notify-when-ready Man-buffer)))
 
 	(if err-mess
 	    (error "%s" err-mess))
-	))))
+	)))
 
 (defun Man-page-from-arguments (args)
   ;; Skip arguments and only print the page name.

Message #26 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 01 Aug 2012 11:41:35 +0300

> `Man-getpage-in-background' use (if (fboundp 'start-process) to check if
> it start an asynchronous process or not.
> Why in Emacs-24 `start-process' would not exists?
> Why instead don't you add an optional arg to `Man-getpage-in-background'
> to make it synchronous?
> It would be instead of (if (fboundp 'start-process):
> (if synchronous start-man-synchronously start-man-async
> This would allow to make an user variable that allow to choose if man is
> async or not.

Yes, this is what is implemented with a new `Man-async'
in another post I just sent.

Do you agree that man should be synchronous by default?

Message #29 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 01 Aug 2012 10:58:20 +0200

Juri Linkov <juri <at> jurta.org> writes:

>> `Man-getpage-in-background' use (if (fboundp 'start-process) to check if
>> it start an asynchronous process or not.
>> Why in Emacs-24 `start-process' would not exists?
>> Why instead don't you add an optional arg to `Man-getpage-in-background'
>> to make it synchronous?
>> It would be instead of (if (fboundp 'start-process):
>> (if synchronous start-man-synchronously start-man-async
>> This would allow to make an user variable that allow to choose if man is
>> async or not.
>
> Yes, this is what is implemented with a new `Man-async'
> in another post I just sent.
Ah! good.

> Do you agree that man should be synchronous by default?
Yes.

Also `Man-notify-method' should be more accessible (more let-bindable)
probably by making it local, but I may be wrong there (need to look at
the code).

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 01 Aug 2012 10:05:59 +0100

On Wed 01 Aug 2012, Reuben Thomas wrote:

> On 1 August 2012 01:15, Juri Linkov <juri <at> jurta.org> wrote:
>>
>> The Emacs Info reader can format man pages with the help
>> of info-man.el.
>
> This doesn't appear to be standard.
>
>>> Personally, I'd just rip out all the asynchronous stuff and make "man"
>>> synchronous (I have man set to "bully" mode in my setup), but I am
>>> guessing that would be an unpopular change,
>>
>> Yes, the delay when the whole session is freezing during formatting would
>> be undesirable.
>
> There are plenty of things that freeze the session for much longer
> than the fraction of a second it takes to format most man pages! Even
> bash(1) only takes about a second. What workflow do you have in mind
> where a user starts a man page and then does something else for at
> most a few seconds? The idea of requesting some documentation and then
> doing something else for a few seconds is a bit odd to me…

things freezing for any reason should be something to be removed
everywhere, not an excuse for allowing more badness.

Async fetching and formatting of man pages is very useful if the man
page is on a remote host running a different OS.

   AndyM

Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 01 Aug 2012 11:29:00 +0200

Thierry Volpiatto <thierry.volpiatto <at> gmail.com> writes:

> Juri Linkov <juri <at> jurta.org> writes:
>
>>> `Man-getpage-in-background' use (if (fboundp 'start-process) to check if
>>> it start an asynchronous process or not.
>>> Why in Emacs-24 `start-process' would not exists?
>>> Why instead don't you add an optional arg to `Man-getpage-in-background'
>>> to make it synchronous?
>>> It would be instead of (if (fboundp 'start-process):
>>> (if synchronous start-man-synchronously start-man-async
>>> This would allow to make an user variable that allow to choose if man is
>>> async or not.
>>
>> Yes, this is what is implemented with a new `Man-async'
>> in another post I just sent.
> Ah! good.
>
>> Do you agree that man should be synchronous by default?
> Yes.
>
> Also `Man-notify-method' should be more accessible (more let-bindable)
> probably by making it local, but I may be wrong there (need to look at
> the code).

Also while you are at it, it would be helpful to add a 't' value to the
require-match arg of completing-read in `man'.

Thanks.
-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Message #38 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 1 Aug 2012 12:11:50 +0100

On 1 August 2012 09:23, Juri Linkov <juri <at> jurta.org> wrote:
>
> You are right, the largest man page `man bash' takes just 2 sec to format,
> so perhaps it makes no sense to run the man command asynchronously nowadays.

I would certainly take that view if it were I who had to maintain the code!

> I don't know if it's possible with lack of multi-threading
> to yield to the command loop while waiting for the process output.
> But with the following patch you can run `man' synchronously
> by using just `(let ((Man-async nil)) (man "bash"))' when its
> default value is not nil.

That looks great if the patch were installed.

-- 
http://rrt.sc3d.org

Message #41 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Thu, 02 Aug 2012 02:10:54 +0300

> things freezing for any reason should be something to be removed
> everywhere, not an excuse for allowing more badness.
>
> Async fetching and formatting of man pages is very useful if the man
> page is on a remote host running a different OS.

I guess the distinction is exactly like between sync and async
shell commands.  When you know that a command will finish quickly,
`shell-command' is more preferable, whereas `async-shell-command'
is better for a long-running process.

Message #44 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Thu, 02 Aug 2012 02:12:05 +0300

> Also `Man-notify-method' should be more accessible (more let-bindable)
> probably by making it local, but I may be wrong there (need to look at
> the code).

This will be possible when you let-bind both `Man-notify-method'
and `Man-async':

  (let ((Man-async nil) (Man-notify-method 'pushy)) (man "bash"))

> Also while you are at it, it would be helpful to add a 't' value to the
> require-match arg of completing-read in `man'.

But what if `man' is unable to get a complete list of all available man pages?
Then you can't read some man pages.  For instance, this happens when
you install a new package with a man page, but Man-completion-cache
is not updated.  This is a very rare problem, and you can still
read the man page by entering its name without completion.

Message #47 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Thu, 02 Aug 2012 07:20:28 +0200

Juri Linkov <juri <at> jurta.org> writes:

>> Also `Man-notify-method' should be more accessible (more let-bindable)
>> probably by making it local, but I may be wrong there (need to look at
>> the code).
>
> This will be possible when you let-bind both `Man-notify-method'
> and `Man-async':
>
>   (let ((Man-async nil) (Man-notify-method 'pushy)) (man "bash"))
Ok thanks.

>> Also while you are at it, it would be helpful to add a 't' value to the
>> require-match arg of completing-read in `man'.
>
> But what if `man' is unable to get a complete list of all available man pages?
> Then you can't read some man pages.  For instance, this happens when
> you install a new package with a man page, but Man-completion-cache
> is not updated.  This is a very rare problem, and you can still
> read the man page by entering its name without completion.
It would be better in this case to reload the cache e.g with a prefix
arg do (setq Man-completion-cache nil) before calling completing-read.
 

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Message #50 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Juri Linkov <juri <at> jurta.org>
Cc: 12098 <at> debbugs.gnu.org, Reuben Thomas <rrt <at> sc3d.org>
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 19 Aug 2020 12:49:39 +0000

severity 12098 wishlist
tags 12098 + patch moreinfo
thanks

Juri Linkov <juri <at> jurta.org> writes:

>> There are plenty of things that freeze the session for much longer
>> than the fraction of a second it takes to format most man pages! Even
>> bash(1) only takes about a second.
>
> You are right, the largest man page `man bash' takes just 2 sec to format,
> so perhaps it makes no sense to run the man command asynchronously nowadays.
>
> The patch below introduces a new variable `Man-async' whose value
> could be set to nil to run `man' synchronously.
>
>> Are you sure about that bug number? I looked and it seems to be about
>> window layout.
>
> That's right, currently the async mode of man has its peculiarities:
> it arranges window layouts after formatting is done, so formatting
> can't fit into window layout.
>
> So perhaps we should have two asynchronous modes:
> 1. delay changes in window configuration
>    until the process is finished and man page is formatted.
> 2. prepare window layout before formatting;
>
> I'm still not sure whether we need the former for backward compatibility,
> so `Man-async' could have a special value for it.
>
>> I can't see how to use this to communicate back to a particular caller
>> that man failed; help?
>
> I don't know if it's possible with lack of multi-threading
> to yield to the command loop while waiting for the process output.
> But with the following patch you can run `man' synchronously
> by using just `(let ((Man-async nil)) (man "bash"))' when its
> default value is not nil.

This patch adds the possibility to run man asynchronously.  I'm not sure
it's worth the added complexity.  Any other opinions?

> === modified file 'lisp/man.el'
> --- lisp/man.el	2012-07-11 23:13:41 +0000
> +++ lisp/man.el	2012-08-01 08:23:10 +0000
> @@ -144,6 +144,20 @@ (defcustom Man-reverse-face 'highlight
>    :type 'face
>    :group 'man)
>
> +(defcustom Man-async nil
> +  "Synchronicity of the manpage command.
> +If nil, run the manpage command synchronously.
> +If t, run the manpage command asynchronously
> +preparing output windows before the process is started.
> +If the value is `delayed', run the manpage command
> +asynchronously but delay changes in window configuration
> +until the process is finished and man page is formatted."
> +  :type '(choice (const :tag "Synchronous" nil)
> +                 (const :tag "Asynchronous" t)
> +                 (const :tag "Delayed" delayed))
> +  :group 'man
> +  :version "24.2")
> +
>  ;; Use the value of the obsolete user option Man-notify, if set.
>  (defcustom Man-notify-method (if (boundp 'Man-notify) Man-notify 'friendly)
>    "Selects the behavior when manpage is ready.
> @@ -904,16 +920,37 @@ (defun Man-getpage-in-background (topic)
>  Return the buffer in which the manpage will appear."
>    (let* ((man-args topic)
>  	 (bufname (concat "*Man " man-args "*"))
> -	 (buffer  (get-buffer bufname)))
> +	 (buffer  (get-buffer bufname))
> +	 (procbufname (concat " " bufname))
> +	 procbuffer)
>      (if buffer
>  	(Man-notify-when-ready buffer)
>        (require 'env)
> -      (message "Invoking %s %s in the background" manual-program man-args)
> -      (setq buffer (generate-new-buffer bufname))
> -      (with-current-buffer buffer
> -	(setq buffer-undo-list t)
> -	(setq Man-original-frame (selected-frame))
> -	(setq Man-arguments man-args))
> +      (cond
> +       ((eq Man-async 'delayed)
> +	(message "Invoking %s %s in the background" manual-program man-args)
> +	(setq buffer (generate-new-buffer bufname))
> +	(with-current-buffer buffer
> +	  (setq buffer-undo-list t)
> +	  (setq Man-original-frame (selected-frame))
> +	  (setq Man-arguments man-args)))
> +       (t
> +	(setq buffer (generate-new-buffer bufname))
> +	(setq procbuffer (generate-new-buffer procbufname))
> +	;; Display empty output buffer.
> +	(unless (memq Man-notify-method '(polite quiet meek))
> +	  (Man-notify-when-ready buffer))
> +	(with-current-buffer buffer
> +	  (insert (format "Invoking %s %s in the background\n"
> +			  manual-program man-args))
> +	  (setq buffer-undo-list t)
> +	  (setq Man-original-frame (selected-frame))
> +	  (setq Man-arguments man-args))
> +	(with-current-buffer procbuffer
> +	  (setq buffer-undo-list t)
> +	  (setq Man-original-frame (selected-frame))
> +	  (setq Man-arguments man-args))))
> +
>        (let ((process-environment (copy-sequence process-environment))
>  	    ;; The following is so Awk script gets \n intact
>  	    ;; But don't prevent decoding of the outside.
> @@ -952,16 +989,26 @@ (defun Man-getpage-in-background (topic)
>  			     (cond
>  			      ((and (integerp Man-width) (> Man-width 0))
>  			       Man-width)
> -			      (Man-width (frame-width))
> -			      ((window-width))))))
> +			      (Man-width
> +			       (if (eq Man-async 'delayed)
> +				   (frame-width)
> +				 (with-selected-window (get-buffer-window
> +							buffer t)
> +				   (frame-width))))
> +			      (t
> +			       (if (eq Man-async 'delayed)
> +				   (window-width)
> +				 (with-selected-window (get-buffer-window
> +							buffer t)
> +				   (window-width))))))))
>  	(setenv "GROFF_NO_SGR" "1")
>  	;; Since man-db 2.4.3-1, man writes plain text with no escape
>  	;; sequences when stdout is not a tty.	In 2.5.0, the following
>  	;; env-var was added to allow control of this (see Debian Bug#340673).
>  	(setenv "MAN_KEEP_FORMATTING" "1")
> -	(if (fboundp 'start-process)
> +	(if (and Man-async (fboundp 'start-process))
>  	    (set-process-sentinel
> -	     (start-process manual-program buffer
> +	     (start-process manual-program (if (eq Man-async 'delayed) buffer procbuffer)
>  			    (if (memq system-type '(cygwin windows-nt))
>  				shell-file-name
>  			      "sh")
> @@ -969,7 +1016,7 @@ (defun Man-getpage-in-background (topic)
>  			    (format (Man-build-man-command) man-args))
>  	     'Man-bgproc-sentinel)
>  	  (let ((exit-status
> -		 (call-process shell-file-name nil (list buffer nil) nil
> +		 (call-process shell-file-name nil (list procbuffer nil) nil
>  			       shell-command-switch
>  			       (format (Man-build-man-command) man-args)))
>  		(msg ""))
> @@ -980,7 +1027,7 @@ (defun Man-getpage-in-background (topic)
>  			   (format "exited abnormally with code %d"
>  				   exit-status)))
>  		(setq msg exit-status))
> -	    (Man-bgproc-sentinel bufname msg)))))
> +	    (Man-bgproc-sentinel procbufname msg)))))
>      buffer))
>
>  (defun Man-notify-when-ready (man-buffer)
> @@ -1216,16 +1263,18 @@ (defun Man-bgproc-sentinel (process msg)
>  synchronously, PROCESS is the name of the buffer where the manpage
>  command is run.  Second argument MSG is the exit message of the
>  manpage command."
> -  (let ((Man-buffer (if (stringp process) (get-buffer process)
> -		      (process-buffer process)))
> -	(delete-buff nil)
> -	(err-mess nil))
> +  (let* ((Man-procbuffer (if (stringp process) (get-buffer process)
> +			   (process-buffer process)))
> +	 (Man-buffer (get-buffer (replace-regexp-in-string
> +				  "\\` " "" (buffer-name Man-procbuffer))))
> +	 (delete-buff nil)
> +	 (err-mess nil))
>
>      (if (null (buffer-name Man-buffer)) ;; deleted buffer
>  	(or (stringp process)
>  	    (set-process-buffer process nil))
>
> -      (with-current-buffer Man-buffer
> +      (with-current-buffer Man-procbuffer
>  	(let ((case-fold-search nil))
>  	  (goto-char (point-min))
>  	  (cond ((or (looking-at "No \\(manual \\)*entry for")
> @@ -1261,11 +1310,17 @@ (defun Man-bgproc-sentinel (process msg)
>                (Man-fontify-manpage)
>              (Man-cleanup-manpage))
>
> +	  (unless (eq Man-async 'delayed)
> +	    (copy-to-buffer Man-buffer (point-min) (point-max))))))
> +
> +      (unless delete-buff
> +	(with-current-buffer (if (eq Man-async 'delayed) Man-procbuffer Man-buffer)
>            (run-hooks 'Man-cooked-hook)
>  	  (Man-mode)
>
> @@ -1279,11 +1342,13 @@ (defun Man-bgproc-sentinel (process msg)
>  	;; Man-notify-when-ready because it may switch buffers.
>
>  	(if (not delete-buff)
> -	    (Man-notify-when-ready Man-buffer))
> +	    (when (or (eq Man-async 'delayed)
> +		      (memq Man-notify-method '(polite quiet meek)))
> +	      (Man-notify-when-ready Man-buffer)))
>
>  	(if err-mess
>  	    (error "%s" err-mess))
> -	))))
> +	)))
>
>  (defun Man-page-from-arguments (args)
>    ;; Skip arguments and only print the page name.

Best regards,
Stefan Kangas

Message #57 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Juri Linkov <juri <at> jurta.org>, 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 19 Aug 2020 13:53:29 +0100

[Message part 1 (text/plain, inline)]

On Wed, 19 Aug 2020 at 13:49, Stefan Kangas <stefan <at> marxist.se> wrote:

>
> This patch adds the possibility to run man asynchronously.  I'm not sure
> it's worth the added complexity.  Any other opinions?
>

I re-read this bug, and I agree: as I said before, I don't think it's worth
the extra complexity.

[Message part 2 (text/html, inline)]

Message #60 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Juri Linkov <juri <at> jurta.org>, 12098 <at> debbugs.gnu.org,
 Reuben Thomas <rrt <at> sc3d.org>
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 19 Aug 2020 15:08:01 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> This patch adds the possibility to run man asynchronously. 

Hm...  but `M-x man' does run asynchronously now?  At least it does when
I try it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #63 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: Juri Linkov <juri <at> jurta.org>, 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 19 Aug 2020 13:08:34 +0000

Reuben Thomas <rrt <at> sc3d.org> writes:

> On Wed, 19 Aug 2020 at 13:49, Stefan Kangas <stefan <at> marxist.se> wrote:
>
>>
>> This patch adds the possibility to run man asynchronously.  I'm not sure
                                              ^ synchronously
>> it's worth the added complexity.  Any other opinions?

Fixed typo above.

> I re-read this bug, and I agree: as I said before, I don't think it's worth
> the extra complexity.

Thanks.  Let's see if anyone else has something to say before we close
it.

Best regards,
Stefan Kangas

Message #66 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Juri Linkov <juri <at> jurta.org>, Stefan Kangas <stefan <at> marxist.se>,
 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 19 Aug 2020 14:10:54 +0100

[Message part 1 (text/plain, inline)]

On Wed, 19 Aug 2020 at 14:08, Lars Ingebrigtsen <larsi <at> gnus.org> wrote:

> Stefan Kangas <stefan <at> marxist.se> writes:
>
> > This patch adds the possibility to run man asynchronously.
>
> Hm...  but `M-x man' does run asynchronously now?  At least it does when
> I try it.
>

Good point. It would be better to run synchronously (only).

-- 
https://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Message #69 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Juri Linkov <juri <at> jurta.org>, 12098 <at> debbugs.gnu.org,
 Reuben Thomas <rrt <at> sc3d.org>
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 19 Aug 2020 13:14:20 +0000

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

>> This patch adds the possibility to run man asynchronously.
>
> Hm...  but `M-x man' does run asynchronously now?  At least it does when
> I try it.

Yes, that was a typo; I meant synchronously (without the a).

Sorry about the confusion.

Best regards,
Stefan Kangas

Message #72 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Reuben Thomas <rrt <at> sc3d.org>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Juri Linkov <juri <at> jurta.org>, 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 19 Aug 2020 13:24:33 +0000

Reuben Thomas <rrt <at> sc3d.org> writes:

> Good point. It would be better to run synchronously (only).

Why?  What is the benefit of running synchronously?

It seems to me that we want more things to run asynchronously, and not
the other way around.

Best regards,
Stefan Kangas

Message #75 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Juri Linkov <juri <at> jurta.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 19 Aug 2020 14:28:15 +0100

[Message part 1 (text/plain, inline)]

On Wed, 19 Aug 2020 at 14:24, Stefan Kangas <stefan <at> marxist.se> wrote:

>
> It seems to me that we want more things to run asynchronously, and not
> the other way around.
>

As I said earlier in the thread, this seems only to add complexity (for
example making it hard to reuse `man` for other things, the reason I filed
this issue originally) for no useful gain on modern machines (the delay
when formatting even the longest man page is short).

-- 
https://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Message #78 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: Juri Linkov <juri <at> jurta.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 19 Aug 2020 13:51:02 +0000

Reuben Thomas <rrt <at> sc3d.org> writes:

> As I said earlier in the thread, this seems only to add complexity (for
> example making it hard to reuse `man` for other things, the reason I filed
> this issue originally) for no useful gain on modern machines (the delay
> when formatting even the longest man page is short).

What if you are running this remotely using TRAMP?  What if you're on a
laggy network with an NFS mounted filesystem?  What if your disk is
failing and this command takes several seconds to complete?  etc.

Best regards,
Stefan Kangas

Message #81 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Juri Linkov <juri <at> jurta.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 19 Aug 2020 14:51:46 +0100

[Message part 1 (text/plain, inline)]

On Wed, 19 Aug 2020 at 14:51, Stefan Kangas <stefan <at> marxist.se> wrote:

> Reuben Thomas <rrt <at> sc3d.org> writes:
>
> > As I said earlier in the thread, this seems only to add complexity (for
> > example making it hard to reuse `man` for other things, the reason I
> filed
> > this issue originally) for no useful gain on modern machines (the delay
> > when formatting even the longest man page is short).
>
> What if you are running this remotely using TRAMP?  What if you're on a
> laggy network with an NFS mounted filesystem?  What if your disk is
> failing and this command takes several seconds to complete?  etc.
>

No different from any other command that interacts with the disc and is
normally run synchronously.

-- 
https://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Message #84 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: Juri Linkov <juri <at> jurta.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 19 Aug 2020 14:12:19 +0000

Reuben Thomas <rrt <at> sc3d.org> writes:

>> What if you are running this remotely using TRAMP?  What if you're on a
>> laggy network with an NFS mounted filesystem?  What if your disk is
>> failing and this command takes several seconds to complete?  etc.
>
> No different from any other command that interacts with the disc and is
> normally run synchronously.

Yes, so your entire Emacs session will block.  In other words, less than
satisfactory.

Best regards,
Stefan Kangas

Message #87 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Juri Linkov <juri <at> jurta.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 19 Aug 2020 15:21:36 +0100

[Message part 1 (text/plain, inline)]

On Wed, 19 Aug 2020 at 15:12, Stefan Kangas <stefan <at> marxist.se> wrote:

> Reuben Thomas <rrt <at> sc3d.org> writes:
>
> >> What if you are running this remotely using TRAMP?  What if you're on a
> >> laggy network with an NFS mounted filesystem?  What if your disk is
> >> failing and this command takes several seconds to complete?  etc.
> >
> > No different from any other command that interacts with the disc and is
> > normally run synchronously.
>
> Yes, so your entire Emacs session will block.  In other words, less than
> satisfactory.
>

Many commands do this; I don't think there's a reason to treat man
specially in this regard and complicate it.

man was not written to be asynchronous because of the things you mention,
but because it could take some time to format the man page. This is no
longer the case.

-- 
https://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Message #90 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: Juri Linkov <juri <at> jurta.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 19 Aug 2020 15:17:56 +0000

Reuben Thomas <rrt <at> sc3d.org> writes:

>> Yes, so your entire Emacs session will block.  In other words, less than
>> satisfactory.
>
> Many commands do this; I don't think there's a reason to treat man
> specially in this regard and complicate it.

I have the exact opposite view: more commands should be asynchronous.

Best regards,
Stefan Kangas

Message #93 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Juri Linkov <juri <at> jurta.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 19 Aug 2020 16:22:10 +0100

[Message part 1 (text/plain, inline)]

On Wed, 19 Aug 2020 at 16:17, Stefan Kangas <stefan <at> marxist.se> wrote:

> Reuben Thomas <rrt <at> sc3d.org> writes:
>
> >> Yes, so your entire Emacs session will block.  In other words, less than
> >> satisfactory.
> >
> > Many commands do this; I don't think there's a reason to treat man
> > specially in this regard and complicate it.
>
> I have the exact opposite view: more commands should be asynchronous.
>

That would be great. It's tough to achieve in Emacs of course, since the
underlying model of operation is synchronous. At the moment, various
packages solve this problem in ad hoc ways. In some (such as man) there's
no longer a need for an ad hoc solution: the extra complexity isn't worth
it. In others, such as TRAMP and ispell, it's obviously fundamental.

-- 
https://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Message #96 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 12098 <at> debbugs.gnu.org,
 Reuben Thomas <rrt <at> sc3d.org>
Subject: Re: bug#12098: How to trap errors in man?
Date: Thu, 20 Aug 2020 03:37:51 +0300

>>> This patch adds the possibility to run man asynchronously.
>>
>> Hm...  but `M-x man' does run asynchronously now?  At least it does when
>> I try it.
>
> Yes, that was a typo; I meant synchronously (without the a).

I think adding an option to run man synchronously will address such wishes as
https://debbugs.gnu.org/40888

Message #99 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Juri Linkov <juri <at> jurta.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 12098 <at> debbugs.gnu.org,
 Reuben Thomas <rrt <at> sc3d.org>
Subject: Re: bug#12098: How to trap errors in man?
Date: Fri, 21 Aug 2020 00:25:45 -0700

tags 12098 - patch moreinfo
thanks

Juri Linkov <juri <at> jurta.org> writes:

>>>> This patch adds the possibility to run man asynchronously.
>>>
>>> Hm...  but `M-x man' does run asynchronously now?  At least it does when
>>> I try it.
>>
>> Yes, that was a typo; I meant synchronously (without the a).
>
> I think adding an option to run man synchronously will address such wishes as
> https://debbugs.gnu.org/40888

Unfortunately the patch here no longer applies but from taking a quick
look it shouldn't be too hard to rewrite for anyone so inclined.

Best regards,
Stefan Kangas

Message #106 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: juri <at> jurta.org, larsi <at> gnus.org, 12098 <at> debbugs.gnu.org, rrt <at> sc3d.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Fri, 21 Aug 2020 10:41:50 +0300

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Fri, 21 Aug 2020 00:25:45 -0700
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Reuben Thomas <rrt <at> sc3d.org>,
>  12098 <at> debbugs.gnu.org
> 
> > I think adding an option to run man synchronously will address such wishes as
> > https://debbugs.gnu.org/40888
> 
> Unfortunately the patch here no longer applies but from taking a quick
> look it shouldn't be too hard to rewrite for anyone so inclined.

Btw, while assessing the speed of running a 'man' command
synchronously, please be sure to do that with a man page that doesn't
have its formatted counterpart stored in man/catN.  Most
implementations of 'man' will store the formatted pages there, and use
them afterwards, thus avoiding the more expensive formatting command.
Displaying a pre-formatted man page is almost instantaneous, but
formatting a large and non-trivial page might be slower.

(The above doesn't mean to imply I object to the proposed change.)

Message #109 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Juri Linkov <juri <at> jurta.org>, Lars Magne Ingebrigtsen <larsi <at> gnus.org>,
 Stefan Kangas <stefan <at> marxist.se>, 12098 <at> debbugs.gnu.org
Subject: Re: bug#12098: How to trap errors in man?
Date: Fri, 21 Aug 2020 10:41:52 +0100

[Message part 1 (text/plain, inline)]

On Fri, 21 Aug 2020 at 08:41, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Stefan Kangas <stefan <at> marxist.se>
> > Date: Fri, 21 Aug 2020 00:25:45 -0700
> > Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Reuben Thomas <rrt <at> sc3d.org>,
> >  12098 <at> debbugs.gnu.org
> >
> > > I think adding an option to run man synchronously will address such
> wishes as
> > > https://debbugs.gnu.org/40888
> >
> > Unfortunately the patch here no longer applies but from taking a quick
> > look it shouldn't be too hard to rewrite for anyone so inclined.
>
> Btw, while assessing the speed of running a 'man' command
> synchronously, please be sure to do that with a man page that doesn't
> have its formatted counterpart stored in man/catN.  Most
> implementations of 'man' will store the formatted pages there, and use
> them afterwards, thus avoiding the more expensive formatting command.
> Displaying a pre-formatted man page is almost instantaneous, but
> formatting a large and non-trivial page might be slower.
>

The times quoted earlier in the thread (specifically, 2s for bash(1)) does
not sound like there was a cached version involved, as that's much too slow!

-- 
https://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Message #112 received at 12098 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Juri Linkov <juri <at> jurta.org>, 12098 <at> debbugs.gnu.org,
 Reuben Thomas <rrt <at> sc3d.org>
Subject: Re: bug#12098: How to trap errors in man?
Date: Wed, 14 Oct 2020 08:05:31 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> It seems to me that we want more things to run asynchronously, and not
> the other way around.

I agree, and I think adding an option to make M-x man be synchronous
again would be counter-productive, so I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.