On 6 August 2015 at 03:39, Eli Zaretskii <e...@gnu.org> wrote:
>> Date: Wed, 5 Aug 2015 21:16:36 +0100
>> From: Gavin Smith <gavinsmith0...@gmail.com>
>> Cc: Rob Browning <r...@defaultvalue.org>, 793...@bugs.debian.org,
>> Texinfo <bug-texinfo@gnu.org>
>>
>> > Symlinks are less portable than init files.
>>
>> What operating systems don't support symlinks
>
> Windows. (Later versions do, but creating a symlink requires
> privileges.)
One idea I had, which could be useful for Windows and other systems
lacking symlinks, is to make an Info file itself operate as a kind of
symlink. When the target is a non-split file, the indirect file would
have the form of a split Info file, with a single file mentioned in
its indirect sub-file table, being the absolute path of the target
file. This would work because sub-files of split files are identical
in format to non-split files. The two possible problems I foresee are
that indirect sub-file tables have hitherto never contained absolute
paths; and sub-files of split files (or files viewed as sub-files)
have never contained tag tables. I haven't tested if either of those
cause breakage but I don't see why they couldn't be fixed if they did.
Likewise, when the target Info file was split, the indirect file would
be the same as the target top-level file, with the indirect table
rewritten to contain absolute paths.
There could be a small utility to create these symlink-like Info files
("infolink"?), which could be easily ignored by people who don't need
it.
>> and why is it important enough to add an extra feature for them that
>> isn't needed on other operating systems, complicating the situation
>> for everybody else who isn't using them?
>
> Init files are a widely used feature, it's not a complication at all.
Clearly it is a complication to design an init file format, write code
to parse it, and explain to users how to write such init files. There
are all kind of problems like how to escape special characters in the
init file, what character encoding the init files are in, backwards
compatibility (how can Info read init files intended for older Info
versions), and forward compatibility (how can Info read init files
intended for Info versions that are released in the future, when we
don't know what will change in the future). If we use a standard file
format for init files, like XML, we have the tedium of investigating
libraries to parse XML and how to incorporate these, and how to avoid
creating extra requirements for people building Texinfo.
