lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev short_url option


From: Eduardo Chappa L.
Subject: Re: lynx-dev short_url option
Date: Thu, 5 Aug 1999 11:31:31 -0700 (PDT)

*** address@hidden (address@hidden) wrote on Aug 6, 1999:

:) 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 purpose 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?
:) 

  Sorry I take too long to answer, I 'm not in town right now. The
original purpose was actually D > A = B and don't care about C. The point
being made was that D was important sometimes and I definitely wanted to
see it. (to distinguish .gif, .html, .tar.gz, .cgi, etc) In order to see A
and B they appeared up to at least 3 + 1 characters less than half of the
columns in the terminal (considering also the "-more-" and/or "-index-"
part). My experience is that A and B have almost always shown complete
(except only once for a link to a place with a long host name, like
barnesandnoble.bfast.com). The code always shows a minimal amount of the
leaf, because it may not be a url for example:
Javascript(something/very/long/here/); is possibly shown as
Javascript(somet.../here/); giving a privilege to the reading of the last
word, but the code does not consider that extremely long leaves are
undesirable either, so that's something where an improvement can be done,
although a criteria for this is really hard to agree on.

  I guess we need to decide what's important. My patch reflects my
opinion, but other ideas are more than welcome. Hopefully this will not be
configurable.

Eduardo
http://www.math.washington.edu/~chappa/personal.html


reply via email to

[Prev in Thread] Current Thread [Next in Thread]