Hi all,
(1) Many of us are perfectly capable of parsing a longer URL.
(2) Not everyone knows you and doesn't want to trust that
you aren't linking to goatse as a joke.
(3) Many of us do know you and still don't want to trust that
you aren't linking to goatse as a joke.
(3) This also applies when trying to search archives. And it
destroys the search value of terms within the link.
(4) All the links may lose much of their value at any time
if a company stops the service or introduces some mandatory
advertising viewing.
Please at least provide the correct URL alongside the shorter link.
Thanks,
Adam
From: Erik Naggum
Subject: Re: Please stop using makeashorterlink etc.
Date:
Message-ID: <3246476887230839@naggum.no>
* Adam Warner
| Please at least provide the correct URL alongside the shorter link.
Thank you for saying what I think every time someone posts such a URL. If
someone could provide permanent addresses for something, that would be a
useful service, but if they did, I still want to see the original URL as
part of it.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
"Adam Warner" <······@consulting.net.nz> writes:
> Please at least provide the correct URL alongside the shorter
> link.
Well, the original URL might become invalid just as well; I don't
like, either, though, that you can't see where it leads (although
you have a few seconds to look at it before you're redirected).
I'll probably stop using the short ones for this reason.
Regards,
--
Nils G�sche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xD26EF2A0
From: Duane Rettig
Subject: Re: Please stop using makeashorterlink etc.
Date:
Message-ID: <4zns955m2.fsf@beta.franz.com>
"Adam Warner" <······@consulting.net.nz> writes:
> Hi all,
>
> (1) Many of us are perfectly capable of parsing a longer URL.
>
> (2) Not everyone knows you and doesn't want to trust that
> you aren't linking to goatse as a joke.
>
> (3) Many of us do know you and still don't want to trust that
> you aren't linking to goatse as a joke.
>
> (3) This also applies when trying to search archives. And it
> destroys the search value of terms within the link.
>
> (4) All the links may lose much of their value at any time
> if a company stops the service or introduces some mandatory
> advertising viewing.
This is the first negative comment I've heard on makeashorterlink.
I used makeashorterlink once, when the original url was huge (it
spanned more than two lines of my 184 column emacs screen). I had
thought I was doing people a favor by making a textually shorter
link, but apparently not. It's no big deal to me; urls tend to change
anyway, so I'll just fire away with the real one from now on.
> Please at least provide the correct URL alongside the shorter link.
There's no point in even making the shorter link at all to save any
textual space, if one is going to put the longer one beside it.
(although, I guess it might be useful for people whose news browsers
don't handle line wraps very well).
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
>> Please at least provide the correct URL alongside the shorter link.
>
> There's no point in even making the shorter link at all to save any
> textual space, if one is going to put the longer one beside it.
> (although, I guess it might be useful for people whose news browsers
> don't handle line wraps very well).
IMHO it's also useful if you read news on a different machine than the
one you're browser is running on (e.g. through ssh), which is my
set-up (most of the time). so i can only follow a url by
copy&paste. if a long url is wrapped or falls off the screen, it's
quite difficult to c&p it...
--
Joost Kremers http://baserv.uci.kun.nl/~jkremers
lrwxrwxrwx 1 root root 11 nov 2 21:37 vi -> emacsclient*
Joost Kremers <············@yahoo.com> wrote in message news:<··························@catv0149.extern.kun.nl>...
> IMHO it's also useful if you read news on a different machine than the
> one you're browser is running on (e.g. through ssh), which is my
> set-up (most of the time). so i can only follow a url by
> copy&paste. if a long url is wrapped or falls off the screen, it's
> quite difficult to c&p it...
Notice how inelegant software forces bad workarounds. ;) I'm assuming
that the ssh software somehow puts a newline in the cut&paste buffer
where it shouldn't.
Greg Neumann
From: Tim Bradshaw
Subject: Re: Please stop using makeashorterlink etc.
Date:
Message-ID: <ey3el9kqlnh.fsf@cley.com>
* Greg Neumann wrote:
> Notice how inelegant software forces bad workarounds. ;) I'm assuming
> that the ssh software somehow puts a newline in the cut&paste buffer
> where it shouldn't.
No, not at all - ssh just transmits data. However cutting and pasting
from a terminal emulator window often does - the bad software is the
terminal emulator not ssh...
However that's not the reason I don't like makeashorterlink. Using it
is kind of the web equivalent of making a symlink of all files and
directories in a Unix filesystem to gensymmed filenames in the root
directory. It reduces typing, yes, but there is a reason people use
tree-structured (or DAG-structured) namespaces...
--tim
Greg Neumann wrote:
> Joost Kremers <············@yahoo.com> wrote:
>> IMHO it's also useful if you read news on a different machine than the
>> one you're browser is running on (e.g. through ssh), which is my
>> set-up (most of the time). so i can only follow a url by
>> copy&paste. if a long url is wrapped or falls off the screen, it's
>> quite difficult to c&p it...
>
> Notice how inelegant software forces bad workarounds. ;) I'm assuming
> that the ssh software somehow puts a newline in the cut&paste buffer
> where it shouldn't.
no, the problem is that if the url is spread out over multiple lines,
the new-lines are already there. and if it is one long line that is
wider than the screen, slrn doesn't wrap, but only displays the first
part, allowing you to scroll horizontally to see the rest. and if you
tell slrn to wrap, it puts a few spaces before the wrapped lines...
slrn just wasn't designed for this...
--
Joost Kremers http://baserv.uci.kun.nl/~jkremers
lrwxrwxrwx 1 root root 11 nov 2 21:37 vi -> emacsclient*
Joost Kremers <············@yahoo.com> wrote:
+---------------
| Greg Neumann wrote:
| > Joost Kremers <············@yahoo.com> wrote:
| >> IMHO it's also useful if you read news on a different machine than the
| >> one you're browser is running on (e.g. through ssh), which is my
| >> set-up (most of the time). so i can only follow a url by
| >> copy&paste. if a long url is wrapped or falls off the screen, it's
| >> quite difficult to c&p it...
| >
| > Notice how inelegant software forces bad workarounds. ;) I'm assuming
| > that the ssh software somehow puts a newline in the cut&paste buffer
| > where it shouldn't.
|
| no, the problem is that if the url is spread out over multiple lines,
| the new-lines are already there. and if it is one long line that is
| wider than the screen, slrn doesn't wrap, but only displays the first
| part, allowing you to scroll horizontally to see the rest. and if you
| tell slrn to wrap, it puts a few spaces before the wrapped lines...
|
| slrn just wasn't designed for this...
+---------------
IMHO, the problem is that virtually *none* of the mail and/or news
readers (including slrn, apparently) ever bothered to implement the
RFC 1738 "Appendix: Recommendations for URLs in Context", or they would
have no trouble at all with URLs like this one <URL:http://techpubs.
sgi.com/library/tpl/cgi-bin/browse.cgi?coll=0650&db=bks&cmd=toc&pth=
/SGI_Developer/DevDriver_PG>, which I used quite a lot back when I
worked at SGI. ;-} The spec even mandates ignoring leading & trailing
whitespace, so that this gets you to the same place.
<URL:http://techpubs.sgi.com/lib
rary/tpl/cgi-bin/browse.cgi?coll
=0650&db=bks&cmd=toc&pth=/SGI_De
veloper/DevDriver_PG>
-Rob
p.s. Not to be a tease, I herein share a couple of hacks which
make life much easier in dealing with long URLs (especially given
the absence of help from the mail/news readers). In your ~/.twmrc
[or similar, YMMV], in one of the top-level (root) menus, add this
line (yeah, prolly should be called "Sel->NS"):
"Sel->URL" f.exec "sel2url &"
In ~/bin/sel2url:
#!/bin/sh
# Strip whitespace & RFC 1738 Appendix <URL:> marker,
# and URL-encode a few dangerous punctuation chars.
# Also allow <http:> from RFC 2396 Appendix E.
url=`/bin/echo \`xselection PRIMARY\` | \
sed -e 's/[ ]*//g' \
-e 's/\`/%60/g' \
-e 's/,/%2c/g' \
-e 's/^<URL:\(.*\)>$/\1/' \
-e 's/^<http:\(.*\)>$/http:\1/'`
# defensiveness/convenience
case "X$url" in
X"") echo "sel2url: Can't open null URL!"
exit 1
;;
X[0-9][0-9][0-9][0-9][0-9][0-9])
# Six-digit number: Assume this is an Engineering bug number.
# url="http://{CENSORED}/bwxquery.cgi?view_type=Bug&wi=$url"
esac
exec netscape -remote "openURL($url)"
[If you don't have Richard Hesketh's ancient "xselection" program, you
can use "xclip" from the FreeBSD ports collection, or anything similar.]
Then all you have to do is mouse-select some URL -- RFC 1738 bracketed
or not, multiline or not, whitespace or not -- and go to the root menu
and select the "Sel->URL" option, and the selected web page will pop up
on the topmost of the current Netscape windows.
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <······················@giganews.com>,
····@rpw3.org (Rob Warnock) wrote:
> The spec even mandates ignoring leading & trailing
> whitespace, so that this gets you to the same place.
>
> <URL:http://techpubs.sgi.com/lib
> rary/tpl/cgi-bin/browse.cgi?coll
> =0650&db=bks&cmd=toc&pth=/SGI_De
> veloper/DevDriver_PG>
FWIW, I option-clicked somewhere in the first line in MT-NewsWatcher 2.3
(OS X) and the page opened in MSIE with no problems.
-- Bruce
Bruce Hoult <·····@hoult.org> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) wrote:
| > The spec even mandates ignoring leading & trailing
| > whitespace, so that this gets you to the same place.
| >
| > <URL:http://techpubs.sgi.com/lib
| > rary/tpl/cgi-bin/browse.cgi?coll
| > =0650&db=bks&cmd=toc&pth=/SGI_De
| > veloper/DevDriver_PG>
|
| FWIW, I option-clicked somewhere in the first line in MT-NewsWatcher 2.3
| (OS X) and the page opened in MSIE with no problems.
+---------------
Cool! But does it handle *this* <URL:http://techpubs.sgi.com/lib
rary/tpl/cgi-bin/browse.cgi?coll=0650&db=bks&cmd=toc&pth=/SGI_De
veloper/DevDriver_PG> without barfing?
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Bruce Hoult <·····@hoult.org> wrote:
> +---------------
> | ····@rpw3.org (Rob Warnock) wrote:
> | > The spec even mandates ignoring leading & trailing
> | > whitespace, so that this gets you to the same place.
> | >
> | > <URL:http://techpubs.sgi.com/lib
> | > rary/tpl/cgi-bin/browse.cgi?coll
> | > =0650&db=bks&cmd=toc&pth=/SGI_De
> | > veloper/DevDriver_PG>
> |
> | FWIW, I option-clicked somewhere in the first line in MT-NewsWatcher 2.3
> | (OS X) and the page opened in MSIE with no problems.
> +---------------
>
> Cool! But does it handle *this* <URL:http://techpubs.sgi.com/lib
> rary/tpl/cgi-bin/browse.cgi?coll=0650&db=bks&cmd=toc&pth=/SGI_De
> veloper/DevDriver_PG> without barfing?
Just FYI: Emacs/Gnus also handles all of these examples fine for
me. Just last week I was thinking about giving slrn a try because Gnus
can be _really_ slow sometimes. But I guess your article makes one
point against it.
Cheers,
Edi.
Rob Warnock <····@rpw3.org> wrote:
> Bruce Hoult <·····@hoult.org> wrote:
> +---------------
> | ····@rpw3.org (Rob Warnock) wrote:
> | > The spec even mandates ignoring leading & trailing
> | > whitespace, so that this gets you to the same place.
> | >
> | > <URL:http://techpubs.sgi.com/lib
> | > rary/tpl/cgi-bin/browse.cgi?coll
> | > =0650&db=bks&cmd=toc&pth=/SGI_De
> | > veloper/DevDriver_PG>
> |
> | FWIW, I option-clicked somewhere in the first line in MT-NewsWatcher 2.3
> | (OS X) and the page opened in MSIE with no problems.
> +---------------
>
> Cool! But does it handle *this* <URL:http://techpubs.sgi.com/lib
> rary/tpl/cgi-bin/browse.cgi?coll=0650&db=bks&cmd=toc&pth=/SGI_De
> veloper/DevDriver_PG> without barfing?
MacSoup parsed it with no problem (OS9.2, with IE5 as default browser),
as long as I cmd-clicked in the part on the first line. Same with the
first example. I could also highlight the whole URL, and then cmd-click
anywhere in it.
Niether worked as well when quoted -- it stuck the quote characters into
the URL.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT ·······@bcect.com
In article <······················@giganews.com>,
····@rpw3.org (Rob Warnock) wrote:
> Bruce Hoult <·····@hoult.org> wrote:
> +---------------
> | ····@rpw3.org (Rob Warnock) wrote:
> | > The spec even mandates ignoring leading & trailing
> | > whitespace, so that this gets you to the same place.
> | >
> | > <URL:http://techpubs.sgi.com/lib
> | > rary/tpl/cgi-bin/browse.cgi?coll
> | > =0650&db=bks&cmd=toc&pth=/SGI_De
> | > veloper/DevDriver_PG>
> |
> | FWIW, I option-clicked somewhere in the first line in MT-NewsWatcher 2.3
> | (OS X) and the page opened in MSIE with no problems.
> +---------------
>
> Cool! But does it handle *this* <URL:http://techpubs.sgi.com/lib
> rary/tpl/cgi-bin/browse.cgi?coll=0650&db=bks&cmd=toc&pth=/SGI_De
> veloper/DevDriver_PG> without barfing?
Yes, that's fine.
It doesn't work once its quoted with the > down the side though.
Perhaps I should submit a bug report. (or fix it)
-- Bruce
In article <····························@posting.google.com>,
············@yahoo.com (Greg Neumann) wrote:
> Joost Kremers <············@yahoo.com> wrote in message
> news:<··························@catv0149.extern.kun.nl>...
> > IMHO it's also useful if you read news on a different machine than the
> > one you're browser is running on (e.g. through ssh), which is my
> > set-up (most of the time). so i can only follow a url by
> > copy&paste. if a long url is wrapped or falls off the screen, it's
> > quite difficult to c&p it...
>
> Notice how inelegant software forces bad workarounds. ;) I'm assuming
> that the ssh software somehow puts a newline in the cut&paste buffer
> where it shouldn't.
ssh doesn't, but many terminal emulators do e.g. Konsole, xterm etc.
One of the few that doesn't is OS X's "Terminal": something that prints
from a program as one line copies&pastes as one line, even if wrapped on
the screen. Also, if you change the window size the text is re-wrapped.
This doesn't happen in xterm.
Another point is that some browsers automatically rejoin urls with
newlines in them when you paste them into the address box. MSIE on OS X
is an example.
-- Bruce
From: Tim Bradshaw
Subject: Re: Please stop using makeashorterlink etc.
Date:
Message-ID: <ey3of8oqwwu.fsf@cley.com>
* Adam Warner wrote:
> Please at least provide the correct URL alongside the shorter link.
I agree - at least provide the original - it helps people easily see
whether they already know the site, and it's one less thing to break.
--tim