GNU bug report logs - #16733
messed up unicode chars in package description

Previous Next

Full log

View this message in rfc822 format

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Stefan <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 16733 <at> debbugs.gnu.org
Subject: bug#16733: messed up unicode chars in package description
Date: Sat, 22 Mar 2014 17:46:45 +0100

On Sat, Mar 22, 2014 at 4:55 PM, Stefan <monnier <at> iro.umontreal.ca> wrote:

> I think for url-insert-file-contents, the intention is to pretend URLs
> make up a virtual file-system (that's the point of url-handlers.el).
> From this point of view http://www.gnu.org/nonexistent is a file that
> doesn't exist.  So url-insert-file-contents should signal an error just
> like insert-file-contents would.

The semantics of a missing file in the filesystem and a missing page
in a web site are different; filesystems do not usually have a
"default error file" to return when the search failed; web sites, do,
and in many cases, that page *is* informative; it can contain helpful
links, etc. Try accessing

  http://en.wikipedia.org/wiki/Stefan_Monnier

It returns a 404, but still, the error page created on the fly is
quite useful (with a simple click you can search all mentions of
"Stefan Monnier" in the Wikipedia, for example).

> Similarly, url-insert-file-contents should (and does, IIUC) follow
> redirections so you get to the the destination of the redirection rather
> than the redirection page itself.

Because the semantics of a redirection imply following the
redirection. There's nothing in the semantics of 404 that say that you
should ignore the result page, or not. Is up to the application /
user. 404 is not telling you that you got nothing, only that you
didn't get what you expected.

Anyway, I can see how this discussion could lead us nowhere. We
disagree in two points, so let's recapitulate:

- Currently, url-insert-file-contents does ignore 404 results and most
other response codes. I don't think it's a good idea to change its
long-standing behavior, but if you insist, it's your call. That's only
a matter of changing the function passed as CHECK to
url-whatever-its-name.

- You suggest that url-w-i-n should only call CHECK "in case of a
problem". I do not like this, because I think CHECK is *the* function
tasked with telling whether there's a problem or not. How will you
define what is a problem (what if I really want to get back these 404
pages?) and how to pass back that information to CHECK?

     J

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.