delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/02/14/11:31:38

Date: Mon, 14 Feb 2000 16:18:01 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: salvador <salvador AT inti DOT gov DOT ar>
cc: djgpp-workers AT delorie DOT com
Subject: Re: LFN problem with info ?
In-Reply-To: <38A80C62.CC798811@inti.gov.ar>
Message-ID: <Pine.SUN.3.91.1000214160308.14365C-100000@is>
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: dj-admin AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Mon, 14 Feb 2000, salvador wrote:

> > There's another difference between Ref and Node in the tag table: when
> > you need to auto-complete node names, you should skip the Ref entries.
> 
> A note: distributing the files in dos format these references are quite
> unuseful because they point some hundreads of bytes before the real point.

Sorry, I don't understand: are you telling that offsets of Ref pointers 
have this problem, while the offsets of Node pointers do not?  They both 
are computed and used in the same way, so they must share all the 
problems (if there are problems; see below).

> With some luck the node before it, but not the real place. That's yet another
> disadvantage of DOS style distribution. I'm tired of pointing out these
> problems.
> Of course I added enough tricky-code to find the node that contains the
> reference, then compute the offset inside the node and finally calculate
> which line is that in the UNIX file, but is an extra complication.

An Info reader should strip all the CR characters after it reads the file
(or read it in text mode).  When this is done, all the pointers point
directly to the correct places, so you don't need any extra computations
and tricks to find the place.

For example, neither info.exe nor Emacs do any tricks, they just go to 
the place where the offset points.  I never had any problems with that,
since they both remove CRs from each line when reading the Info files.

> BTW: these references lose sense if the user handedits the .info files.

If editing is small, then the pointers still work, because The Info 
reader allows for a few KB of mismatch before it complains.  (This
feature is meant for those cases when somebody regenerates the Info
files while the main file with the tag table is loaded into info.exe.)

> Do you
> still thinking enough users will do it to justify all the wasted CPU needed to
> find the exact place?

You sound very angry, as if the current method costs you a lot of 
trouble.  Please explain why do you need all these complications in the 
code, because AFAIK other Info readers don't have those complications
and they still work well.  Perhaps there's some kind of misunderstanding.

The fact that the pointers in the tag table are independent of whether 
the file is in DOS or in Unix format is IMHO a feature.  It makes them
work even if someone runs UTOD or DTOU on them, or edits them with an 
editor (many DOS/Windows editors don't preserve the end-of-line format, 
even if they do support Unix-style EOLs).  So, unless there are grave 
disadvantages to this, I think we need to continue supporting them.

But you already know all this, so I'm probably missing something 
important.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019