Re: lynx-dev short_url option

[nsh]

Hi,

I have been very complicated for myself...  I must stay to
think twice.

In message <address@hidden>
        Subject: Re: lynx-dev short_url option
        Klaus Weide <address@hidden> writes:

> What I meant with "/.../" is not that lynx should make up another
> slash, but (if possible) should try to omitt whole path segments,
> so that the despayed string ends up having "/.../" instead of
> "/whatever/was/omitted/".
>
> It seems the patch from <address@hidden> tries to do just that
> (I have not tested it).

I intended to do so, but not completely.  ;(
But before fix that, there remains still something to be
clear.  Besides how to display, yes - that is the problem,
what is the most relevant part of URL?  We'd better define
explicitly the order of them, though the answer depends on
your porpose and situation.

        A. communication protocol
        B. hostname
        C. middle parts of the path
        D. the final leaf

I preferred A > D > B > C without thought, however my patch
has a bug.  Someone differ of course.  The original idea of
short_url is A > B > D > C, isn't it?

In message <address@hidden>
        Subject: Re: lynx-dev short_url option
        "T.E.Dickey" <address@hidden> writes:

> Well - try.  But still some of the leaves may be longer than the screen width
> allows.

Oh, and one more problem here.  If something preferred not to 
be removed is too long for statusline, what is the most
important part of it, the head or the tail or ...?  How to
cut out?  I have no idea anymore...

BTW, Netscape seem to choose more simple way.  They omit a
long URL at the center of it and replace to "...", don't mind 
any confusion with real "...".  There is no reason to follow
them, however, it's another solution.

Thank you.
---
address@hidden