"man printf" vs "info printf"

[hongy...@gmail.com]

On Ubuntu 20.04, I noticed that the documents given by "man printf" and "info printf" are very different.

Any hints for this design of documentation layouts in this case?

Best,
HY

[Janis Papanagnou]

Generally, 'man' came delivered with the first Unixes as standard
documentation. You see a fixed structure and standard layout. The
pages have been written as text and processed with the *roff set
of tools. (Unix Books like Steven's "Advanced Programming..."
have also been written with the troff tool.) With 'info' you can
structure individual pages and use links to interconnect them.

I suggest to start reading with:
$ man man
$ man info
$ info info
and google for further details is necessary.

Janis

> Best, HY
>

[Janis Papanagnou]

On 09.01.2021 09:11, Janis Papanagnou wrote:
> On 09.01.2021 08:26, hongy...@gmail.com wrote:
>> On Ubuntu 20.04, I noticed that the documents given by "man printf"
>> and "info printf" are very different.

On Linux I've regularly seen that some developers that preferred
'info' just abandoned the man page documentation. Then you often
find only a note in the man page saying you should switch to info
if you want the documentation of the command. So don't expect that
the presented information is equivalent or has the same grade of
detail. In my book, if one really wants to support a second format
of the docs, the information should at least have a common base.

Janis

[Chris Elvidge]

On the other hand - at least in my version of Slackware 14.2 - info vim
brings up the man page, vim.info seems to be missing.

--
Chris Elvidge
England

[Kenny McCormack]

In article <rtbp04$6dj$1...@news-1.m-online.net>,
Janis Papanagnou <janis_pa...@hotmail.com> wrote:
...

>detail. In my book, if one really wants to support a second format
>of the docs, the information should at least have a common base.

When is your book coming out? I look forward to it.

Will it be available on Amazon?

--
1) The only professionals who refer to their customers as "users" are
computer guys and drug dealers.
2) The only professionals who refer to their customers as "clients" are
lawyers and prostitutes.

[Janis Papanagnou]

On 09.01.2021 12:58, Kenny McCormack wrote:
> In article <rtbp04$6dj$1...@news-1.m-online.net>,
> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> ...
>> detail. In my book, if one really wants to support a second format
>> of the docs, the information should at least have a common base.
>
> When is your book coming out? I look forward to it.

"in my book" was meant as
"as far as I can see",
"to my mind",
"to my way of thinking",
"according to my opinion",
"the way I see it",
"for what it's worth",
etc.

Sorry if that was not clear to native speakers. If other wordings
are preferable I am open to suggestions.

Janis (not a native English speaker)

[Janis Papanagnou]

On 09.01.2021 12:48, Chris Elvidge wrote:
>
> On the other hand - at least in my version of Slackware 14.2 - info vim
> brings up the man page, vim.info seems to be missing.

I've never noticed that.

Though a bit funny; in 'man vim' I can navigate with *vi/vim* commands
('G', '1G', '50%', '^D', etc.) but not so in 'info vim'. As a vi/vim
user its obvious what I prefer.

Janis

[Allodoxaphobia]

On Sat, 9 Jan 2021 15:03:44 +0100, Janis Papanagnou wrote:
>
> Sorry if that was not clear to native speakers.

s/native/non-native/

[Chris Elvidge]

On 09/01/2021 02:03 pm, Janis Papanagnou wrote:
> On 09.01.2021 12:58, Kenny McCormack wrote:
>> In article <rtbp04$6dj$1...@news-1.m-online.net>,
>> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> ...
>>> detail. In my book, if one really wants to support a second format
>>> of the docs, the information should at least have a common base.
>>
>> When is your book coming out? I look forward to it.

My take on this was that Kenny was making a joke.

>
> "in my book" was meant as
> "as far as I can see",
> "to my mind",
> "to my way of thinking",
> "according to my opinion",
> "the way I see it",
> "for what it's worth",
> etc.
>
> Sorry if that was not clear to native speakers. If other wordings
> are preferable I am open to suggestions.
>
> Janis (not a native English speaker)
>

--
Chris Elvidge
England

[John McCue]

Use man (or mandoc), also I read somewhere GNU is
looking into replacing info with something else.
I do not remember what it is, but it cannot possibly
be worse then info.

[Christian Weisgerber]

On 2021-01-09, Janis Papanagnou <janis_pa...@hotmail.com> wrote:

>> On Ubuntu 20.04, I noticed that the documents given by "man printf"
>> and "info printf" are very different.
>>
>> Any hints for this design of documentation layouts in this case?
>
> Generally, 'man' came delivered with the first Unixes as standard
> documentation. You see a fixed structure and standard layout. The
> pages have been written as text and processed with the *roff set
> of tools.

The old commerical Unix systems came with printed manuals. The man
pages were simply the source to those manuals.

There are two sets of roff macros for man pages: The old, presentational
man(7) set and the later BSD mdoc(7) set for semantic markup. BSD
systems have now moved on from the troff(1) toolchain and use
mandoc(1) to format man pages. mandoc(1) was designed for mdoc(7),
but eventually grew sufficient man(7) and low-level roff support
to deal with most pages written in man(7).

> With 'info' you can structure individual pages and use links to
> interconnect them.

Info is a GNU invention that was intended to replace man but never
quite took off outside the GNU project. The *.texi documentation
files are compiled into *.info format for the interactive info(1)
viewer. They can also be processed into TeX for printing. The
info(1) interface uses Emacs-style commands.

Info's killer feature was that the info(1) viewer presented a
hypertext format. This stopped being so killer once HTML became
popular.

Regarding the original poster's question about the "design of
documentation layouts":
There is no design. It's Linux, the documentation is a hodgepodge.

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Janis Papanagnou]

Erm.. - I think that Kenny *is* a native speaker.
(My suspicion was that I used a non-popular or wrong wording
that even native speakers do not understand. Although I was
positive that I've seen that phrase used by others as well.)

Janis

[William Unruh]

On 2021-01-09, Janis Papanagnou <janis_pa...@hotmail.com> wrote:

The phrase you used was fine."in my book", meaning "in my opinion" is a
standard colloquialism in English. Of course some could read the
metaphore as reality, but that is always a danger.
> Janis
>

[Spiros Bousbouras]

If you mean info the format , I don't think there is anything wrong with
it. It is basically a text format with some control characters here and there
and it can be read just fine with less .If you mean the utility info , yes
, it is a piece of shit. I think the idea was that info pages would be
navigated and read with emacs so not much effort was put into the info
utility. I don't use emacs so I don't know how well it works to use with
info pages.

--
description="FooBar is a daemon that drinks"
extra_started_commands="drink"
description_drink="Opens mouth and reflexively swallows"
https://wiki.gentoo.org/wiki/Handbook:X86/Working/Initscripts

[Dan Espen]

Spiros Bousbouras <spi...@gmail.com> writes:

> On Sat, 9 Jan 2021 15:51:10 -0000 (UTC)
> John McCue <jmc...@jmclin1.hsd1.ma.comcast.net> wrote:
>> hongy...@gmail.com <hongy...@gmail.com> wrote:
>> > On Ubuntu 20.04, I noticed that the documents given
>> > by "man printf" and "info printf" are very different.
>> >
>> > Any hints for this design of documentation layouts in this case?
>> >
>> > Best,
>> > HY
>>
>> Use man (or mandoc), also I read somewhere GNU is
>> looking into replacing info with something else.
>> I do not remember what it is, but it cannot possibly
>> be worse then info.
>
> If you mean info the format , I don't think there is anything wrong with
> it. It is basically a text format with some control characters here and there
> and it can be read just fine with less .If you mean the utility info , yes
> , it is a piece of shit. I think the idea was that info pages would be
> navigated and read with emacs so not much effort was put into the info
> utility. I don't use emacs so I don't know how well it works to use with
> info pages.

Pretty well, it's well highlighted and you can click the links with a
mouse. No images though.

--
Dan Espen

[John McCue]

Spiros Bousbouras <spi...@gmail.com> wrote:
> On Sat, 9 Jan 2021 15:51:10 -0000 (UTC)
> John McCue <jmc...@jmclin1.hsd1.ma.comcast.net> wrote:
>> hongy...@gmail.com <hongy...@gmail.com> wrote:
>> > On Ubuntu 20.04, I noticed that the documents given
>> > by "man printf" and "info printf" are very different.
>> >
>> > Any hints for this design of documentation layouts in this case?
>> >
>> > Best,
>> > HY
>>
>> Use man (or mandoc), also I read somewhere GNU is
>> looking into replacing info with something else.
>> I do not remember what it is, but it cannot possibly
>> be worse then info.
>

<snip>

>If you mean the utility info , yes, it is a piece of shit.

Yes I am referring to the info(1) utility. When I
first encountered it, I was so annoyed with it I
never looked at its details.

[Ed Morton]

What you said was perfect, idiomatic English. Kennys native language is
Troll so he probably didn't know that, just killfile him like so many of
us have done and you will miss nothing.

Ed.

>
> Janis
>

[Kaz Kylheku]

On 2021-01-09, Spiros Bousbouras <spi...@gmail.com> wrote:
> On Sat, 9 Jan 2021 15:51:10 -0000 (UTC)
> John McCue <jmc...@jmclin1.hsd1.ma.comcast.net> wrote:
>> hongy...@gmail.com <hongy...@gmail.com> wrote:
>> > On Ubuntu 20.04, I noticed that the documents given
>> > by "man printf" and "info printf" are very different.
>> >
>> > Any hints for this design of documentation layouts in this case?
>> >
>> > Best,
>> > HY
>>
>> Use man (or mandoc), also I read somewhere GNU is
>> looking into replacing info with something else.
>> I do not remember what it is, but it cannot possibly
>> be worse then info.
>
> If you mean info the format , I don't think there is anything wrong with
> it. It is basically a text format with some control characters here and there
> and it can be read just fine with less .If you mean the utility info , yes
> , it is a piece of shit. I think the idea was that info pages would be
> navigated and read with emacs so not much effort was put into the info
> utility. I don't use emacs so I don't know how well it works to use with
> info pages.

Info pages can also be spun into halfway okay HTML. The major GNU
programs have their info documentation hosted online, often in more than
one form: all in one HTML page, or multiple pages.

Man pages do not HTML-ize easily.

I sacrificed cows and goats to the god of text munging to make the HTML
form of the TXR man page.

I forked the sources of man-1.6 to create a custom version of the
man2html utility that it provides. I fixed bugs/deficiencies in its
processing of nroff macros, to be able to use more powerful macro
processing in the man page. All in all, 31 commits or so.

You can see them here:

http://www.kylheku.com/cgit/man/log/

One thing I also did is add a way for the man page code to detect
whether it's being run by the above man2html or the real nroff
processor, to do some things conditionally.

Even with all that, substantial post-procesing is applied to get the
HTML in shape.

http://www.kylheku.com/cgit/txr/tree/genman.txr

This program does things like rearrange and rewrite the table of
contents, add Javascript for a collapsible TOC, and cross-indexes the
identifiers to create hyperlinks. Ambiguous terms go to disambiguation
sections added to the bottom, with lots of whitespace to make them look
like separate pages.

For instance, in this section (8.2.4. Consing Dot) if you click on the
symbol lambda, you get to one of these disambiguation blocks.

https://www.nongnu.org/txr/txr-manpage.html#N-0057E40C

In the man page source itself, there is a macro section over 300 lines
long at the top:

http://www.kylheku.com/cgit/txr/tree/txr.1

The document automatically self-numbers its sections, unlike most man
pages.

--
TXR Programming Language: http://nongnu.org/txr

[Keith Thompson]

John McCue <jmc...@jmclin1.hsd1.ma.comcast.net> writes:
> hongy...@gmail.com <hongy...@gmail.com> wrote:
>> On Ubuntu 20.04, I noticed that the documents given
>> by "man printf" and "info printf" are very different.
>>
>> Any hints for this design of documentation layouts in this case?
>

> Use man (or mandoc), also I read somewhere GNU is
> looking into replacing info with something else.
> I do not remember what it is, but it cannot possibly
> be worse then info.

Personally, I have few problems with the info command, and I use it all
the time. It does require familiarity with emacs-style key bindings.

I don't propose to debate whether it's good or bad. I'm just pointing
out that not everyone has a problem with it.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[Kenny McCormack]

In article <87mtxh6...@nosuchdomain.example.com>,

Keith Thompson <Keith.S.T...@gmail.com> wrote:
>John McCue <jmc...@jmclin1.hsd1.ma.comcast.net> writes:
>> hongy...@gmail.com <hongy...@gmail.com> wrote:
>>> On Ubuntu 20.04, I noticed that the documents given
>>> by "man printf" and "info printf" are very different.
>>>
>>> Any hints for this design of documentation layouts in this case?
>>
>> Use man (or mandoc), also I read somewhere GNU is
>> looking into replacing info with something else.
>> I do not remember what it is, but it cannot possibly
>> be worse then info.
>
>Personally, I have few problems with the info command, and I use it all
>the time. It does require familiarity with emacs-style key bindings.
>
>I don't propose to debate whether it's good or bad. I'm just pointing
>out that not everyone has a problem with it.

I'm sure the author of it thinks it is great.

Just remember, every single line of computer code ever written, is
somebody's pride and joy.

I.e., the fact that not everybody hates something - which will always be
true - there will always be somebody somewhere who likes it - is not exactly
a glowing recommendation.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Infallibility

[Christian Weisgerber]

On 2021-01-09, Kenny McCormack <gaz...@shell.xmission.com> wrote:

> Just remember, every single line of computer code ever written, is
> somebody's pride and joy.

There are programs that have been disowned by their authors; procmail
comes to mind.

[Jim Beard]

"In my book" is a widely used synonym for "in my opinion," but almost
invariably used in circumstances when those hearing it or reading it will
know the one using the phrase is not a writer of any book.

If the reader ASSUMES you have written one or more books (a bit of a
compliment there), the "mis"interpretation would follow.

Cheers!

jim b.

--
UNIX is not user-unfriendly, it merely expects users to be computer-
friendly.

[Kenny McCormack]

In article <slrnrvkdj8...@lorvorc.mips.inka.de>,

Christian Weisgerber <na...@mips.inka.de> wrote:
>On 2021-01-09, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>
>> Just remember, every single line of computer code ever written, is
>> somebody's pride and joy.
>
>There are programs that have been disowned by their authors; procmail
>comes to mind.

That's very interesting. I still use procmail to this day; I've been using
it for decades. Does this (it being "disowned" [abandoned]) indicate there
is some problem with it?

--
"Everything Roy (aka, AU8YOG) touches turns to crap."
--citizens of alt.obituaries--

[Javier]

Christian Weisgerber <na...@mips.inka.de> wrote:
> Info is a GNU invention that was intended to replace man but never
> quite took off outside the GNU project.

There are non-gnu projects releasing info manuals. You have manuals
for python (generated with sphynx), perl (generated with pod2texi), or
common lisp released in info format. Most people is not aware of it,
but anything whose documentation is generated with sphynx can be
compiled in info format.

> The *.texi documentation
> files are compiled into *.info format for the interactive info(1)
> viewer. They can also be processed into TeX for printing. The
> info(1) interface uses Emacs-style commands.
>
> Info's killer feature was that the info(1) viewer presented a
> hypertext format. This stopped being so killer once HTML became
> popular.

It's worth investing some time in learning the info mode of emacs (the
standalone info should be avoided).

The nice thing of info with respect to HTML is that it has structure.
You can go up one level with a single key press ('u' or '^'), go to
previous, next section with 'p' or 'n'. In addition to have back and
forward as the browser ('l' and 'r'). Or go directly to the Index
with 'I'. It feels like having a book in your hands, with the bonus
that you can search the full text with 'C-s'. All this is lacking
in HTML.

The disgrace of info is that opening an info file is not straightforward.
One needs to mess with info path, and make an index in that dir.

emacs --exec '(info "/usr/share/info/web2c.info.gz")'

> Regarding the original poster's question about the "design of
> documentation layouts":
> There is no design. It's Linux, the documentation is a hodgepodge.

OpenBSD man pages are much better written. It is always worth to keep
a copy of them, even if only using linux.

https://ftp.openbsd.org/pub/OpenBSD/amd64/6.8/man68.tgz

[Dan Espen]

Emacs should already be configured to look in that directory
and however web2c got installed it should have updated the necessary file
to put it into the index.

--
Dan Espen

[Janis Papanagnou]

On 09.01.2021 21:20, Kaz Kylheku wrote:
>
> Man pages do not HTML-ize easily.

True, if starting from the man page (or from *roff data) instead
of a common formal base.

With Kornshell's 'getopts' command you have that feature inherently
available. It derives all the information from its (quite complex)
optstring definition. To quote [using ksh] from getopts --man

getopts can also be used to generate help messages containing
command usage and detailed descriptions. Specify args as:
-? To generate a usage synopsis.
--?? To generate a verbose usage message.
--??man
To generate a formatted man page.
--??api
To generate an easy to parse usage message.
--??html
To generate a man page in html format.
--??nroff
To generate a man page in nroff format.
--??usage
List the current optstring.
--???name
List version=n, n>0, if the option name is recognized by getopts.


One can check or compare the HTML result by interrogating any ksh
builtin, [using ksh] e.g. by print --man or print --html .

Janis

PS (disclaimer): Not all of the specified getopts tags seem to work
[correctly] with the version of ksh I use.

[Janis Papanagnou]

On 09.01.2021 21:24, Keith Thompson wrote:
> John McCue <jmc...@jmclin1.hsd1.ma.comcast.net> writes:

>> [...], but it cannot possibly be worse then info.

>
> Personally, I have few problems with the info command, and I use it all
> the time. It does require familiarity with emacs-style key bindings.
>
> I don't propose to debate whether it's good or bad. I'm just pointing
> out that not everyone has a problem with it.

I observe that some programs are not forcing the whole community to one
style; a very primitive but also obvious example (to explain the point)
is searching in Firefox (using "Word" or vi-style keys). Another (more
on-topic) example in CUS are the shell's interactive history editing
modes; ksh (probably other shells as well) support vi and emacs editing.

IMO, a tool shall not [unnecessarily] force anyone to switch to from one
familiar and common behavior to another completely different one. (Emacs
and Vi style appear quite antagonistic to me.)

Janis

[Jorgen Grahn]

On Sun, 2021-01-10, Javier wrote:
...

> The nice thing of info with respect to HTML is that it has structure.
> You can go up one level with a single key press ('u' or '^'), go to
> previous, next section with 'p' or 'n'. In addition to have back and
> forward as the browser ('l' and 'r'). Or go directly to the Index
> with 'I'. It feels like having a book in your hands, with the bonus
> that you can search the full text with 'C-s'. All this is lacking
> in HTML.

Actually, it's not. There is[1] a notion of next/prev/context/index and
so on. See <https://www.w3.org/TR/html401/struct/links.html#h-12.1.2>.

It's unclear to me, though, if current browsers choose to support it.
Opera used to. I went looking for Firefox support yesterday, but
didn't find anything obvious.

You mentioned C-s too. That one /is/ good and lacking in HTML; when I
have to read info pages, I use it a lot.

/Jorgen

[1] Unless they removed it in HTML5.

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Janis Papanagnou]

On 10.01.2021 11:09, Jorgen Grahn wrote:
>
> You mentioned C-s too. That one /is/ good and lacking in HTML; when I
> have to read info pages, I use it a lot.

Yes. Info's 'C-s' fixes its *own* inherent issues!

If using a tool that makes it *necessary* to globally search (because
information is spread around many pages) one has two options, at least;
one is to abandon the tool.

(I like to have all information in one page.)

Janis

[Dan Espen]

Jorgen Grahn <grahn...@snipabacken.se> writes:

> On Sun, 2021-01-10, Javier wrote:
> ...
>> The nice thing of info with respect to HTML is that it has structure.
>> You can go up one level with a single key press ('u' or '^'), go to
>> previous, next section with 'p' or 'n'. In addition to have back and
>> forward as the browser ('l' and 'r'). Or go directly to the Index
>> with 'I'. It feels like having a book in your hands, with the bonus
>> that you can search the full text with 'C-s'. All this is lacking
>> in HTML.
>
> Actually, it's not. There is[1] a notion of next/prev/context/index and
> so on. See <https://www.w3.org/TR/html401/struct/links.html#h-12.1.2>.
>
> It's unclear to me, though, if current browsers choose to support it.
> Opera used to. I went looking for Firefox support yesterday, but
> didn't find anything obvious.
>
> You mentioned C-s too. That one /is/ good and lacking in HTML; when I
> have to read info pages, I use it a lot.

In a browser, C-f.

--
Dan Espen

[Javier]

Dan Espen <dan1...@gmail.com> wrote:
>> You mentioned C-s too. That one /is/ good and lacking in HTML; when I
>> have to read info pages, I use it a lot.
>
> In a browser, C-f.

It's not the same thing. C-f searches a single HTML file, not all
files in a directory.

One could arge that an info page is a single file, but the
presentation of information is by sections, which makes reading much
easier than a whole file in a single scrolling. A good example of
this is the bash(1) man page. It's much nicer to read it in the emacs
info mode.

For the web, in general its structure is not transparent.
In most servers you cannot even get the list of all HTML files in a
directory.

[Javier]

Jorgen Grahn <grahn...@snipabacken.se> wrote:
> On Sun, 2021-01-10, Javier wrote:
> ...
>> The nice thing of info with respect to HTML is that it has structure.
>> You can go up one level with a single key press ('u' or '^'), go to
>> previous, next section with 'p' or 'n'. In addition to have back and
>> forward as the browser ('l' and 'r'). Or go directly to the Index
>> with 'I'. It feels like having a book in your hands, with the bonus
>> that you can search the full text with 'C-s'. All this is lacking
>> in HTML.
>
> Actually, it's not. There is[1] a notion of next/prev/context/index and
> so on. See <https://www.w3.org/TR/html401/struct/links.html#h-12.1.2>.
>
> It's unclear to me, though, if current browsers choose to support it.
> Opera used to. I went looking for Firefox support yesterday, but
> didn't find anything obvious.

I doubt any current browser implements it.

For the case of lynx(1) I don't see anything about that in its manpage
or html documentation.

/usr/share/doc/lynx/lynx_help/keystrokes/keystroke_help.html

Documents generated with info2html include the prev/next/index lynx
https://www.gnu.org/software/bash/manual/html_node/index.html

<link href="#Top" rel="start" title="Top">
<link href="Indexes.html" rel="index" title="Indexes">
<link href="#SEC_Contents" rel="contents" title="Table of Contents">
<link href="../dir/index.html" rel="up" title="(dir)">
<link href="Introduction.html" rel="next" title="Introduction">

It's also there in documents generated with sphynx
https://docs.python.org/3/library/index.html

<link rel="author" title="About these documents" href="../about.html" />
<link rel="index" title="Index" href="../genindex.html" />
<link rel="search" title="Search" href="../search.html" />
<link rel="copyright" title="Copyright" href="../copyright.html" />
<link rel="next" title="Introduction" href="intro.html" />
<link rel="prev" title="10. Full Grammar specification" href="../reference/grammar.html" />

[Christian Weisgerber]

On 2021-01-10, Kenny McCormack <gaz...@shell.xmission.com> wrote:

> That's very interesting. I still use procmail to this day; I've been using
> it for decades. Does this (it being "disowned" [abandoned]) indicate there
> is some problem with it?

I'm sure some googling will turn up detailed arguments, e.g. from
the last time someone suggested to remove the FreeBSD port. If you
ask Philip Guenther in person--I have--he will with resigned
exasperation tell you that the code is bad and nobody should use
it.

[Eric Pozharski]

with <rtcdj2$cbr$1...@news-1.m-online.net> Janis Papanagnou wrote:
> On 09.01.2021 12:48, Chris Elvidge wrote:

>> On the other hand - at least in my version of Slackware 14.2 - info
>> vim brings up the man page, vim.info seems to be missing.
*SKIP*
> Though a bit funny; in 'man vim' I can navigate with *vi/vim* commands
> ('G', '1G', '50%', '^D', etc.) but not so in 'info vim'. As a vi/vim
> user its obvious what I prefer.

I abstain from interpretting "in 'man vim' I can navigate", but in
reality (collective) you don't move around in 'man' (for obvious
reasons), you do it through configured pager ('less', by default). That
just happens, 'less' comes with vi-bindings by default. OTOH 'info' is
pager by itself and comes with emacs-bindings (for reasons better
discussed elsewhere, if such elsewhere exists).

And now, after years of suffering, thank *you* for bringing it up --
'info' knows '--vi-keys' and has '~/.infokey'. Now I need some time for
reading, digging, and configuring. Thank *you* again, for making world
just little bit more comfortable.

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

[Dan Espen]

Javier <inv...@invalid.invalid> writes:

> Dan Espen <dan1...@gmail.com> wrote:
>>> You mentioned C-s too. That one /is/ good and lacking in HTML; when I
>>> have to read info pages, I use it a lot.
>>
>> In a browser, C-f.
>
> It's not the same thing. C-f searches a single HTML file, not all
> files in a directory.

Did not know that C-s would leave the current buffer but a quick test
shows it does. Seems odd, because C-h k C-s says C-s is bound to
the normal C-s and the help for incremental search doesn't mention
any special rules for info mode. There must be something non-obvious
going on with info mode. I'm guessing Emacs just hides sections.

That's something you can do with HTML too but I don't know how that
would affect C-f.

> One could arge that an info page is a single file, but the
> presentation of information is by sections, which makes reading much
> easier than a whole file in a single scrolling. A good example of
> this is the bash(1) man page. It's much nicer to read it in the emacs
> info mode.
>
> For the web, in general its structure is not transparent.
> In most servers you cannot even get the list of all HTML files in a
> directory.

True.

Back when I was creating HTML documentation I'd put a document in a
large HTML file with a table of contents. Then you could click on
the TOC to go to a subject. In the subject you could click on
the heading to go back to the TOC. Kept all of that working
with some Perl or Python (I forget which) to keep the links
right.

--
Dan Espen

[Kenny McCormack]

In article <slrnrvmf7c...@lorvorc.mips.inka.de>,

Keep in mind that SvdB is the original author. Guenther seems to have
taken it over at some point. So, given that, it is not entirely surprising
that he might throw some shade on it. FWIW, I have heard that the original
code is pretty god-awful (*), but the point is that it works and it works well.
Hard to argue with that!

FYI, the man page says:

AUTHORS
Stephen R. van den Berg
<s...@cuci.nl>
Philip A. Guenther
<guen...@sendmail.com>

(*) But then again, a lot of early/primitive C code is.
We've grown up a lot since those early days.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:

http://user.xmission.com/~gazelle/Sigs/Security

[Janis Papanagnou]

On 10.01.2021 15:00, Eric Pozharski wrote:
> with <rtcdj2$cbr$1...@news-1.m-online.net> Janis Papanagnou wrote:
>> On 09.01.2021 12:48, Chris Elvidge wrote:
>
>>> On the other hand - at least in my version of Slackware 14.2 - info
>>> vim brings up the man page, vim.info seems to be missing.
> *SKIP*
>> Though a bit funny; in 'man vim' I can navigate with *vi/vim* commands
>> ('G', '1G', '50%', '^D', etc.) but not so in 'info vim'. As a vi/vim
>> user its obvious what I prefer.
>
> I abstain from interpretting "in 'man vim' I can navigate", but in
> reality (collective) you don't move around in 'man' (for obvious
> reasons), you do it through configured pager ('less', by default).

Yes, my formulation was sloppy. I move around in the "document", in
the information that is presented (in whichever form) using some tool.

> That
> just happens, 'less' comes with vi-bindings by default. OTOH 'info' is
> pager by itself and comes with emacs-bindings (for reasons better
> discussed elsewhere, if such elsewhere exists).

> And now, after years of suffering, thank *you* for bringing it up --
> 'info' knows '--vi-keys' and has '~/.infokey'. Now I need some time for
> reading, digging, and configuring. Thank *you* again, for making world
> just little bit more comfortable.

Note that the key-bindings are just one aspect of the topic, the other
one is the separation of paragraphs in many pages. This decision has
a couple consequences; the most obvious is that you have to navigate a
tree structure. This is by itself more clumsy than navigating a linear
document. Tree structured information is great to quickly locate a leaf
in the information tree. The Unix information pages I've seen are quite
different. (But I think it would go too far OT and get too extensive to
be discussed here. After all, folks will use what they like best. The
only issue I see is that such [IMO bad] decisions like introducing info
could affect all users if other established [and IMO more appropriate]
documentation variants get neglected.) Another aspect is also quite
obvious; readability. Start (for example) 'info perl' and 'man perl'
(which seem to carry the same information and are structured the same
way) and compare. Or take 'info/man diff' (that show different content).
In info I see 4-5 line meta-information, plus more wasted lines for
'***'-underlining where the *roff based document is using highlighting.
The actual information is hidden between a lot of waste. (Reminds me
all those distracting advertisements in the Web-universe.) Readability
differences are not that astonishing if considering that 'man' is based
on a typesetting system (that is working even for text-only terminals).

Janis

[Kaz Kylheku]

On 2021-01-09, Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> On 09.01.2021 12:48, Chris Elvidge wrote:
>>
>> On the other hand - at least in my version of Slackware 14.2 - info vim
>> brings up the man page, vim.info seems to be missing.
>

> I've never noticed that.

>
> Though a bit funny; in 'man vim' I can navigate with *vi/vim* commands
> ('G', '1G', '50%', '^D', etc.) but not so in 'info vim'. As a vi/vim
> user its obvious what I prefer.

The big problem with info is that some of the pages are gateways
into more information than you want.

If you hit the wrong key, you end up in irrelevant documentation.

For insance, if I fire up "info ls", and hit "u" (up) a few times I end
up at the table of contents for all of GNU Coreutils.

Why the hell would I want the whole table of contents, when I asked for
"info ls"?

Here is another example. Suppose I run "info ls". Now I search for
something random, say /printf. Now I'm suddenly looking at the
--printf=FORMAT of the ... stat command? I'm in a section 14.3 of
something. When I go "u" (up), from here, I see:

Next: Printing text, Prev: Changing file attributes, Up: Top

14 Disk usage
*************

No disk can hold an infinite amount of data. These commands report how
much disk storage is in use or available, report other file and file
status information, and write buffers to disk.

* Menu:

* df invocation:: Report file system disk space usage.
* du invocation:: Estimate file space usage.
* stat invocation:: Report file or file system status.
* sync invocation:: Synchronize cached writes to persistent storage\
.
* truncate invocation:: Shrink or extend the size of a file.

What?

Look, I just accidentally searched for something that took me totally out of
the context in which I was looking for information. Can I undo this and go
back to my "info ls"?

[Eric Pozharski]

with <202101102...@kylheku.com> Kaz Kylheku wrote:
> On 2021-01-09, Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> On 09.01.2021 12:48, Chris Elvidge wrote:

>>> On the other hand - at least in my version of Slackware 14.2 - info
>>> vim brings up the man page, vim.info seems to be missing.
>> I've never noticed that.
>> Though a bit funny; in 'man vim' I can navigate with *vi/vim*
>> commands ('G', '1G', '50%', '^D', etc.) but not so in 'info vim'. As
>> a vi/vim user its obvious what I prefer.
> The big problem with info is that some of the pages are gateways into
> more information than you want.
> If you hit the wrong key, you end up in irrelevant documentation.

*SKIP*

> Look, I just accidentally searched for something that took me totally
> out of the context in which I was looking for information. Can I undo
> this and go back to my "info ls"?

Yes, you can. These are defaults, I didn't have time to bring
info-browser to senses yet, my knowledge is quite limited because
emacs-bindings are insane. Here comes: [u] moves up (or down, or
whatever) to the super-root, [p] moves to previous page (until that hits
no-prev (sub-?) root, [backspace] moves back screen-wise in reverted
depth-first order (until that hits (start?) of current '*info'), [l]
goes back in history.

So, per your description (in skipped), you hit [l] as many times as
needed.

p.s. As of limitations of my knowledge about 'info'. I don't know how
to go forward in history. But there's more, I don't know how to do next
search -- I've failed to find that combo two decades ago and now I found
vi-bindings. Hooray for me?

[Eric Pozharski]

with <rtglrn$jti$1...@news-1.m-online.net> Janis Papanagnou wrote:
> On 10.01.2021 15:00, Eric Pozharski wrote:
>> with <rtcdj2$cbr$1...@news-1.m-online.net> Janis Papanagnou wrote:
>>> On 09.01.2021 12:48, Chris Elvidge wrote:

*SKIP*

What you are doing is mixing concepts of formats, filters, UI, and
presentation in walls-of-text. And that's *you*. What raises The
Question I'm reluctant to ask.

[Janis Papanagnou]

On 12.01.2021 09:16, Eric Pozharski wrote:
> with <rtglrn$jti$1...@news-1.m-online.net> Janis Papanagnou wrote:
>> On 10.01.2021 15:00, Eric Pozharski wrote:
>>> with <rtcdj2$cbr$1...@news-1.m-online.net> Janis Papanagnou wrote:
>>>> On 09.01.2021 12:48, Chris Elvidge wrote:
>
> *SKIP*
>
> What you are doing is mixing concepts of formats, filters, UI, and
> presentation in walls-of-text. And that's *you*. What raises The
> Question I'm reluctant to ask.

Yes, I was saying that the presentation format of info is a mess, and
the UI controls are badly designed, and particularly the organization
of the chapters inappropriate. - I am sorry if my criticism hits your
personal feelings or if my text is too "wallified" for your taste (or
if it made it incomprehensible for you); obviously it triggered some
hostility-reflex. Too bad.

Good bye and good luck!

[Javier]

Eric Pozharski <why...@pozharski.name> wrote:
> p.s. As of limitations of my knowledge about 'info'. I don't know how
> to go forward in history. But there's more, I don't know how to do next
> search -- I've failed to find that combo two decades ago and now I found
> vi-bindings. Hooray for me?

For next search you keep hitting 'C-s' or 'I' to go to the index.

To go back and forward in history press 'l' and 'r'. 'l' stands for last,
and 'r' for revisit. 'left' and 'right' are also good mnemonics.

See:

info "(info) Help-Int"

You can also read it with

pinfo "(info) Help-Int"

pinfo keybindings are similar to lynx, so it is more suitable to
non-emacs users.

I never use info: I never use info, I use emacs or 'emacs -nw' if I
want to see it in a terminal. Standalone info is too limited and has
unfixed bugs.

emacs --exec '(info "(info) Help-Int")'
emacs -nw --exec '(info "(info) Help-Int")'

[John-Paul Stewart]

On 2021-01-12 8:53 a.m., Javier wrote:
>
> I never use info: I never use info, I use emacs or 'emacs -nw' if I
> want to see it in a terminal. Standalone info is too limited and has
> unfixed bugs.

For non-emacs users, there's also the standalone 'pinfo' program. I
find its default keybindings much more intuitive. I seem to recall
reading (long ago) that it was based on or inspired by the Lynx web
browser. So if you're familiar with it, pinfo will feel natural. It
is pre-packaged in some Linux distributions (I use Debian) and source is
available at github:

https://github.com/baszoetekouw/pinfo

[Spiros Bousbouras]

Do GNU info or pinfo allow you to mark your position in a document and
return to it quickly ? In other words what you can do with ma and 'a (or
some other letter than a) in vi(m) and less .I don't care if the
keybindings are the same , just whether the functionality is there. With the
info format obviously the marking would have to span several files , at
least those you accessed within a single invocation.

Also do they store the history of previous searches so that you can quickly
modify a previously entered search ?

--
The Luxion, despite having a degeneracy generator working at full capacity, was
subjected to infinite acceleration due to its vanishing motor being destroyed.
Gunbuster "science" lesson 2

[Dan Espen]

Spiros Bousbouras <spi...@gmail.com> writes:

> On Tue, 12 Jan 2021 11:26:17 -0500
> John-Paul Stewart <jpst...@personalprojects.net> wrote:
>> On 2021-01-12 8:53 a.m., Javier wrote:
>> >
>> > I never use info: I never use info, I use emacs or 'emacs -nw' if I
>> > want to see it in a terminal. Standalone info is too limited and has
>> > unfixed bugs.
>>
>> For non-emacs users, there's also the standalone 'pinfo' program. I
>> find its default keybindings much more intuitive. I seem to recall
>> reading (long ago) that it was based on or inspired by the Lynx web
>> browser. So if you're familiar with it, pinfo will feel natural. It
>> is pre-packaged in some Linux distributions (I use Debian) and source is
>> available at github:
>>
>> https://github.com/baszoetekouw/pinfo
>
> Do GNU info or pinfo allow you to mark your position in a document and
> return to it quickly ? In other words what you can do with ma and 'a (or
> some other letter than a) in vi(m) and less .I don't care if the
> keybindings are the same , just whether the functionality is there. With the
> info format obviously the marking would have to span several files , at
> least those you accessed within a single invocation.

Yes. Set a bookmark. It's in the menu bar, of course there's also a
key binding.

> Also do they store the history of previous searches so that you can quickly
> modify a previously entered search ?

Searches are stored in the running instance, go to the previous one with M-p.

--
Dan Espen