man integration with tramp

man integration with tramp

[Ergus]

Hi:

Do we have any functionality to support man in tramp mode to access man
pages in the remote node?

The actual implementation of man has call-process so I suppose we
don't. But it doesn't seems too complex to do.

Suggestions?

Should we add a different command, a configuration option or you think
it is not a good idea? Is there anything special to take into account
and I am ignoring so far?

Best
Ergus

Re: man integration with tramp

[Michael Albinus]

Ergus <spacibba@aol.com> writes:

> Hi:

Hi Ergus,

> Do we have any functionality to support man in tramp mode to access man
> pages in the remote node?
>
> The actual implementation of man has call-process so I suppose we
> don't. But it doesn't seems too complex to do.
>
> Suggestions?
>
> Should we add a different command, a configuration option or you think
> it is not a good idea? Is there anything special to take into account
> and I am ignoring so far?

I think it is a good idea. Sometimes, I felt such a need as well. But it
was so rare, that it didn't kick me enough to run.

I see two possibilities to achieve this goal.

- Adapt man.el. Likely, it just needs a prefix argument for `man' and
  related commands. This would control to call the remote counterparts of
  `call-process' and `start-process', resulting man pages from a remote
  host. A proper managemnt of $MANPATH for different hosts is also
  required.

- Configure woman.el. Likely, we don't need to touch the code; just
  instructions are needed how to set `woman-manpath', `woman-path' and
  friends for remote hosts. Maybe we must enable connection-local
  variables in woman.el (this would be a code change, but a small one).

Personally, I prefer the second option, but I haven't digged deeper for
possible problems.

Comments?

> Best
> Ergus

Best regards, Michael.

Re: man integration with tramp

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Thu, 30 Jul 2020 19:58:16 +0200
> Cc: emacs-devel@gnu.org
> 
> I see two possibilities to achieve this goal.
> 
> - Adapt man.el. Likely, it just needs a prefix argument for `man' and
>   related commands. This would control to call the remote counterparts of
>   `call-process' and `start-process', resulting man pages from a remote
>   host. A proper managemnt of $MANPATH for different hosts is also
>   required.
> 
> - Configure woman.el. Likely, we don't need to touch the code; just
>   instructions are needed how to set `woman-manpath', `woman-path' and
>   friends for remote hosts. Maybe we must enable connection-local
>   variables in woman.el (this would be a code change, but a small one).
> 
> Personally, I prefer the second option, but I haven't digged deeper for
> possible problems.
> 
> Comments?

woman.el doesn't support some of the lately-introduced roff
directives, so it cannot always typeset and render every man page one
finds nowadays on modern platforms.  If you want to use woman.el to do
this job, it will need to be enhanced first, I think.

Re: man integration with tramp

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> woman.el doesn't support some of the lately-introduced roff
> directives, so it cannot always typeset and render every man page one
> finds nowadays on modern platforms.  If you want to use woman.el to do
> this job, it will need to be enhanced first, I think.

Yes, I've seen this in the Commentary section of woman.el. Especially,
the lack of the eqn(1) and tbl(1) preprocessor support is mentioned.

I have no idea how serious this limitation in practice is. But this is
an existing limitation; extending woman.el to support remote man pages
doesn't change it for better or worse.

I'm trying to use woman.el as basis for support of remote man pages,
because a short review of man.el gave me the impression that it takes
more than just replacing `call-process' by `process-file' at one place.

Best regards, Michael.

Re: man integration with tramp

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Fri, 31 Jul 2020 11:24:47 +0200
> Cc: spacibba@aol.com, emacs-devel@gnu.org
> 
> Yes, I've seen this in the Commentary section of woman.el. Especially,
> the lack of the eqn(1) and tbl(1) preprocessor support is mentioned.
> 
> I have no idea how serious this limitation in practice is.

I think it's pretty serious.  We had some bug reports against woman.el
during the recent years, which all boiled down to insufficient support
of modern man pages.

> I'm trying to use woman.el as basis for support of remote man pages,
> because a short review of man.el gave me the impression that it takes
> more than just replacing `call-process' by `process-file' at one place.

I understand.  If doing so will solve enough use cases, it's a good
compromise, of course.

Re: man integration with tramp

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> I'm trying to use woman.el as basis for support of remote man pages,
>> because a short review of man.el gave me the impression that it takes
>> more than just replacing `call-process' by `process-file' at one place.
>
> I understand.  If doing so will solve enough use cases, it's a good
> compromise, of course.

I'll give it a try. If it turns out to be too complex, I'll give up with
woman.el, promised!

Btw, one advantage using woman.el instead of man.el would be, that you
could handle remote man pages for Tramp methods which do not support
remote processes, like sftp or maybe even ftp.

Best regards, Michael.

Re: man integration with tramp

[Max Nikulin]

On 31/07/2020 19:41, Michael Albinus wrote:
> Btw, one advantage using woman.el instead of man.el would be, that you 
> could handle remote man pages for Tramp methods which do not support 
> remote processes, like sftp or maybe even ftp.

This thread was indirectly mentioned in another discussion of man.el and 
woman.el, so...

It is possible to run "man" locally. The following may be adapted as a 
filter for content of a buffer:

   man -l - </usr/share/man/man1/man.1.gz

Re: man integration with tramp

[Michael Albinus]

Max Nikulin <manikulin@gmail.com> writes:

Hi Max,

> This thread was indirectly mentioned in another discussion of man.el
> and woman.el, so...
>
> It is possible to run "man" locally. The following may be adapted as a
> filter for content of a buffer:
>
>   man -l - </usr/share/man/man1/man.1.gz

Thanks for the hint. I'll see whether I could integrate this use case
when i start to add remote man pages support in man.el.

However, this will be the second choice only for showing remote man
pages, because the local man command could not handle references well I
fear. And completion candidates for other man pages won't work for remote
hosts either with this approach.

Best regards, Michael.

Re: man integration with tramp

[Max Nikulin]

On 07/10/2023 19:00, Michael Albinus wrote:
> Max Nikulin writes:
>>    man -l - </usr/share/man/man1/man.1.gz
> 
> However, this will be the second choice only for showing remote man
> pages, because the local man command could not handle references well I
> fear. And completion candidates for other man pages won't work for remote
> hosts either with this approach.

I suggested it for Tramp methods which do not support remote processes.

However if a man page is opened through path to the file (instead of 
just page name) then neighbor files and directories should be considered 
before standard MANPATH when another man page is opened from this 
buffer. It does not matter if it is a remote or a local file. Likely the 
current page is from another set that is e.g. newer or older than system 
pages.

WoMan has code that travels through directories to build completion 
list. However I do not like that WoMan does not allow to specify section 
as man(7) and requires additional step to choose appropriate section. 
Perhaps a part of related code may be reused.

Re: man integration with tramp

[Michael Albinus]

Max Nikulin <manikulin@gmail.com> writes:

Hi Max,

> I suggested it for Tramp methods which do not support remote processes.

Yep.

> However if a man page is opened through path to the file (instead of
> just page name) then neighbor files and directories should be
> considered before standard MANPATH when another man page is opened
> from this buffer. It does not matter if it is a remote or a local
> file. Likely the current page is from another set that is e.g. newer
> or older than system pages.

Makes sense. To tell the truth, I haven't investigated too much time yet
in this topic. Perhaps I shall start to work on it, finally ...

(Making pressure on me always works :-)

> WoMan has code that travels through directories to build completion
> list. However I do not like that WoMan does not allow to specify
> section as man(7) and requires additional step to choose appropriate
> section. Perhaps a part of related code may be reused.

Will check.

Best regards, Michael.

Re: man integration with tramp

[Max Nikulin]

On 07/10/2023 23:49, Michael Albinus wrote:
> (Making pressure on me always works 🙂

I have no intention to prioritize handling of remote man files. I was 
curious if discussed obstacles are real blockers or there are ways to 
overcome them with reasonable efforts. Just for a chance that somebody 
will decide to make a step further.

In my opinion e.g. better heuristics to recognize cross-references is 
more important.

Re: man integration with tramp

[Michael Albinus]

Max Nikulin <manikulin@gmail.com> writes:

Hi Max,

>> (Making pressure on me always works 🙂
>
> I have no intention to prioritize handling of remote man files. I was
> curious if discussed obstacles are real blockers or there are ways to
> overcome them with reasonable efforts. Just for a chance that somebody
> will decide to make a step further.
>
> In my opinion e.g. better heuristics to recognize cross-references is
> more important.

Perhaps. However, I'm not involved in man.el maintenance. I have just
the view as Tramp maintainer on it.

Best regards, Michael.