desktop-entry-spec.xml patch

George jirka at 5z.com
Tue Jul 13 01:41:08 EEST 2004


On Mon, Jul 12, 2004 at 05:14:50PM -0400, Jonathan Blandford wrote:
> Ray Strode <rstrode at redhat.com> writes:
> 
> > I'm not entirely sure making \; an escape sequence like the others is
> > the best approach.  For one, ';' has no special meaning for string
> > values (only lists), so escaping them for strings seems wasteful.  
> > Also, I think it may slightly complicate implementations by making ';'
> > part of the escape sequence (the escaped character be part of the 
> > escape sequence (probably not a big deal though)).
> 
> We have four options here:
> 
>  1) Escape ';' in all strings
> 
>  2) Escape ';' in lists only
> 
>  3) Not support escaping at all.
> 
>  4) Support escaping of ';' only with the MimeType key
> 
> I'm least happy with option 3, as mime-types can validly have a
> semicolon in them.  However, the rest require a change to other parsers.
> Option 4 seems the least intrusive, though it's possible that want
> semicolon's in other lists.

Why would escaping be more intrusive.  To me it seems that now
 Foo=foo\;bar
is illegal nowdays anyway isn't it?  (Well the spec doesn't say one way or
another as far as I'm reading it but maybe I'm reading some old version).  If
you wanted to do that you'd need
 Foo=foo\\;bar

Unknown escapes should be an error IMO.

So it doesn't seem like adding it would make any existing .desktops stop
working (they shouldn't be working in the first place).  So adding the \;
to the spec is equivalent to #3 for all the implementations that don't
support it.  Further if unknown escapes are in fact illegal in all
implementations, then all of the choices have the same negative impact.
That is, nothing that worked before is going to fail, and anything that
needs to use a semicolon is broken in old implementations under all
scenarios.

George

-- 
George <jirka at 5z.com>
   Although prepared for martyrdom, I preferred that it be postponed.
                       -- Sir Winston Churchill




More information about the xdg mailing list