Date: Mon, 14 Feb 2000 16:18:01 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: salvador cc: djgpp-workers AT delorie DOT com Subject: Re: LFN problem with info ? In-Reply-To: <38A80C62.CC798811@inti.gov.ar> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.