lynx-dev Re: [2.8.1dev.22] patch0.3: UIPs, help files, --enable-gzip-help

[Sinan Kaan Yerli]

(28/08/1998 19:04) Serge MUNHOVEN:

>Question: I didn't fully understand the use of the leading and trailing
>underscores ('href="../_filename.html_#section"' and '.html_'). Could someone
>clarify ?

It is my way of showing 'emphasis' in text. I am sorry, if it is
misunderstood.

href="../_filename.html_#section"
                  ^^^^^^
'.html_'
 ^^^^^^

These are completely different things but it is mixed in my writing.
Sorry. First one is a reference within help (I emphasised the filename:
i.e filename.html), second one is the physical help filename's extension
(no emphasis here).

Marking files is a known trick to make them flexiable for overall
changes. Like if the mail address of the lynx-dev changes we only need
to change it in "help_files.txt" and leave the rest to makefile.
This trick can also be used for 'lynx.man' for directories and lynx.cfg
etc. (Hmmm. I just checked 'lynx.man' and we don't have a section like
'FILES' or 'ENVIRONMENT VARIABLES').

I used this oportunity to _add_ COMPRESS_EXT. Thats all.

So adding an extension to _help_ filenames are not related to marking
help files.

> [suggestion: Scanning through an extension list]
>
>   LOCAL_EXTENSIONS:.gz,.bz2
>
>I don't know how DOS-lynx handles gzipped files though. Perhaps one would have
>to *replace* the '.html' extension of the link by a guessed one rather than
>unix'ishly *appending* another bit that DOS will drop anyway (e.g. if '.html'
>cut down to '.htm' under DOS fails, try '.htz' supposing mime knows what it is
>about).
>
>I don't know if this is workable, but it would let you leave the help tree
>alone and allow policy changes (zipping local files) without having to change
>links to them, or even rebuild lynx (in the particular case of the helpfiles).

This needs more coding. The way it is handled with my patch is done for
_only_ help files, because that's the only thing we have control over
while installing. Besides _zero_ code is added.

But if you start scanning filenames you have to think about this
situation: If the directory have both 'filename.html' and
'filename.html.gz'. Which one do you want to go for it? Which one is the
the real one?

This is the reason I say "we have control over". You will not know what
you have in the directory.

>Thinking about other possible failures: accessing test.html.gz#target works
>fine, but an 'e' keystroke lets you edit the compressed file. Bad idea.

Why do you want to edit a file that has an extension '.gz'?

If you see that it is compressed then you download it to your _local_
place and decompress and then edit. It is the same thing for e.g
'.jpeg', would you dare to press 'e' for this or just do 'right arrow'.
Well, I do right arrow for 'xyz.html.gz' and Lynx decompresses and shows
it properly (i.e text/html). If you "edit" this, your editor has to decide
about the type, which normally does not exist. In case it exists it will
be found out that it is 'text/html'. The editor then will launch for
example, Lynx. Hmmm. I think it is a bad idea to try to edit a .gz file
too.

Sinan.