Re: [help-texinfo] Standalone info as a generic info processor?

[Gavin Smith]

On 15 November 2016 at 22:13, Alejandro Sanchez <address@hidden> wrote:
> Status update: I have not reached the point where almost everything is
> implemented and running smoothly. Here is an asciicast if you want to see it
> in action: https://asciinema.org/a/92884
>
> Notice how we have both prompts (available through mappings) and commands,
> and both have tab-completion. The repository is here:
> https://gitlab.com/HiPhish/info.vim

Nice project!

> The features missing are index search, virtual index, text search and
> knowing all the nodes in the file (for the 'g’ Goto node equivalent).
> Virtual index has been implemented on the info-side, but what about the
> rest? Any ideas how I can get that information?

All the information is in the Info file, so any difficulties you have
getting the information is a failure of your implementation. I
understand that you are retrieving information from the Info file
using the "info" program. It's possible that "info" will not be able
to provide all the information you want in an easily processable form.
If that is the case, you would have to read the Info file directly.
That is not the end of the world: it is probably easier than you
think.

Knowing all the nodes in the file: you could do this by recursively
following menus in the file.

Text search: load all the nodes into memory and search them. I can't
be more specific as I haven't studied your program and don't know
anything about writing extensions for Vim.

I am open to adding to or changing the functionality of "info", but
only if it would be likely to be generally useful.

> I have another question as
> well: how do I test whether a file or node even exists? For example, if the
> user types 'info --file herp --node derp’, how do I tell whether the problem
> is that file herp does not exist, or that node derp does not exist? info
> returns error code 0 in both cases, so that’s no use.

Maybe this should be changed to return a non-zero error code.

> Should I set the
> output to /dev/null and then parse the error string?

You can, if that would work.