[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev short_url option
From: |
nsh |
Subject: |
Re: lynx-dev short_url option |
Date: |
Sat, 07 Aug 1999 07:44:05 +0900 |
Hi,
This is far from a problem of only lynx. Every browsers have
to solve the same thing. Do you know about other's way?
(Case of Netscape was mentioned.)
In message <address@hidden>
Subject: Re: lynx-dev short_url option
Heather <address@hidden> writes:
> Potentially good point... non-English readers, please pipe in if you folk
> use something else for ellipsis / omission mark?
Of course, non-ASCII languages have different expression.
There are a kanji character that means omission and a symbol
character looks like "..." that means ellipsis too. I myself
just prefer "..." even if they are configurable, though I saw
real "..." in some URL.
>>>> All the more important to show it when it differs from the "expected"
>>>> one. (i.e. from the local host? from that of the current page?)
>>>
>>> From the current page is what I was thinking. Although, it could get real
>>> tiring seeing file:/// in dired mode, too.
>>
>> The "current page" in dired mode has a URL that starts with
>> "file://localhost", so if URL parts that are common between the current
>> page and the current link were omitted you would not see "file://".
>
> might not see "localhost" either. That'd be fine.
>From another aspect, any parts of URLs equal to the current
page are less relevant than the rest, not only hostnames but
also protocols, port numbers and even directories.
>>>>> port number - now *that*'s important.
>>>> Why would it be more important than the hostname or the protocol?
>>> If you have a firewall, [...]
>>
>> Ok.
>>
>> Lynx already discards port specifications durring normal URL parsing
>> if the port is the same as the default port for the scheme, so it
>> seems this is already dealt with in the most convenient way.
Port numbers are very important for firewalls. And some
proxies let you go through with environment variables:
http_proxy, etc.
>> Yes, you wrote something like that, but you are still assuming that
>> talking about "CGI's" makes sense here. I say it doesn't.
>
> It depends. If the intent is to attempt to preserve important information
> as the mangler compresses the URL, then the generic argument "people have
> different opinions about what is important" holds true whether something
> is a weird directory structure to plain pages, CGI, one of a zillion kinds
> of server hooks, or trips through converting proxies.
Hmm... Protocols, hostnames, and port numbers must always be
distinguishable by anyone to communicate each other. On the
other hand, only servers know what really are the rest of URLs.
Am I mis-understanding?
What a head ache! Do we have to accept compromises?
[big snip]
> I think our play back and forth over what it should or shouldn't compress
> in a URL, is good for short_url's design, and should help create something
> that will last many revs.
And could affect other tools widely, if we reach better point
than ever! ;)
> So you didn't mention what you think of the idea of allowing really long URLs
> to spend two lines instead...
More information is very happy to see, IMHO, the number of
statusline should be fixed. We have still "=" key to get
the whole of URLs.
Thank you.
---
address@hidden
- Re: lynx-dev short_url option, T.E.Dickey, 1999/08/04
- Re: lynx-dev short_url option, nsh, 1999/08/05
- Re: lynx-dev short_url option, Heather, 1999/08/05
- Re: lynx-dev short_url option, nsh, 1999/08/05
- Re: lynx-dev short_url option, Klaus Weide, 1999/08/05
- Re: lynx-dev short_url option, Heather, 1999/08/06
- Re: lynx-dev short_url option, Klaus Weide, 1999/08/06
- Re: lynx-dev short_url option, Heather, 1999/08/06
- Re: lynx-dev short_url option,
nsh <=
- Re: lynx-dev short_url option, David Woolley, 1999/08/09
- Re: lynx-dev short_url option, Klaus Weide, 1999/08/07
- Re: lynx-dev short_url option, Mike Castle, 1999/08/08
Re: lynx-dev short_url option, Eduardo Chappa L., 1999/08/05