Re: more url-utils?

[Ted Zlatanov]

On Sun, 15 May 2011 22:26:13 +0800 Jason Rumney <address@hidden> wrote: 

JR> It would be even nicer if the headers were parsed into a buffer
JR> local alist.

Yes, definitely.  That should be done by default regardless of the other
improvements discussed here.

On Mon, 16 May 2011 12:45:03 -0300 Stefan Monnier <address@hidden> wrote: 

SM> On Mon, 16 May 2011 09:19:18 -0600 Tom Tromey <address@hidden> wrote: 
Tom> IIRC, in package.el I had to special-case some URL types, because
Tom> headers are inconsistently used.  E.g., I think the 'ftp' method won't
Tom> leave headers in the buffer.  It would be nice if this bit were handled
Tom> by the url package rather than all the callers.

SM> Sounds like an inconsistency that needs fixing, indeed.  You might want
SM> to make a bug-report for it.

I had problems using a file:// URL with package.el, which made local
testing a pain.  The problem was exactly with the missing headers, same
as the ftp:// URLs.  So I'll second the bug report if Tom opens it, or
open a new one.

On Sun, 15 May 2011 03:59:52 +0200 Lars Magne Ingebrigtsen <address@hidden> 
wrote: 

LMI> For backwards compatibility (i.e., for out-of-bzr users) a binding might
LMI> be preferable (perhaps), but you're right, an extra optional parameter
LMI> `data-only-p' would make more sense.

After looking at many examples in Emacs, I can't find or think of any
need for the headers *as text* in the code I've seen.  I would:

1) rename the function, obsolete the old one, turn headers off by
default in the new version, and hunt down all the cases where code
removes them from the content.  Yes it's a pain.

2) find any real need for the headers as *text* (I found none).  If none
is found, just do the buffer-local alist Jason suggested, and maybe
provide all the headers as a single text string in case someone needs
them.

I realize this is more invasive but backwards compatibility means lots
of unnecessary code to remove the headers will keep being written.  I
volunteer to do both tasks above.

Ted