I sent Bruno's proposal B to rms. He seems to have accepted it in
general. I'll report when there's something concrete to say.
Karl,
Just pinging you to find out if there's been any progress on this
issue in the last few months. The last message that seems to have
been posted in this thread was this one from Bruno on Dec. 14:
http://lists.gnu.org/archive/html/bug-gnulib/2008-12/msg00127.html
--
Michael(tm) Smith
http
Karl Berry wrote:
> What I don't understand with your proposal is how this magical url
> vs. file bit is known.
When producing/printing an error message, this information has to come
from the program. The program certainly knows whether it has used a function
like fopen() or open_url() to access t
Bruno,
What I don't understand with your proposal is how this magical url
vs. file bit is known. For example, if someone runs Henri's validator
in Emacs, it seems to me that next-error is going to have heuristically
guess whether it is a url to know how to interpret %'s.
Anyway, this decision se
Karl Berry wrote:
> Therefore, when you deal with an URI, you should use a different
> algorithm of presentation within a GNU error message than when you
> deal with a filename.
>
> This seems like it adds complexity both in the description and in
> comprehension.
The long description
Therefore, when you deal with an URI, you should use a different
algorithm of presentation within a GNU error message than when you
deal with a filename.
This seems like it adds complexity both in the description and in
comprehension. At least I am having trouble with it -- it seems l
Henri Sivonen wrote:
> > So my proposal is:
> >
> > - For parsing:
> > - If the first character is a '"', then the escaped syntax is
> > in use. The filename is enclosed in "..."; inside,
> > - occurrences of '"' and '%' are escaped as %22 and %25,
> > respectively,
On Dec 3, 2008, at 14:50, Bruno Haible wrote:
So my proposal is:
- For parsing:
- If the first character is a '"', then the escaped syntax is
in use. The filename is enclosed in "..."; inside,
- occurrences of '"' and '%' are escaped as %22 and %25,
respectively,
Hello Karl,
> So, barring further comments/suggestion, I'll propose that to rms in the
> next couple of days.
Thanks. I think newline characters should be escaped as well (for the sake of
programs which
read line by line). So the updated proposal is:
- For parsing:
- If the first charac
Karl Berry wrote:
> > I don't see why \n should be special?
>
> For the same reason why we should escape :, i.e. to ensure that each
> line can be interpreted as FILE:LINE:MESSAGE.
>
> Obviously we have to escape newline characters. In the original
> proposal, they would be escaped a
it is *required* only if the filename
- contains a ':' or newline, or
- starts with a '"'.
Is that the intent?
Yes.
- For parsing:
- If the first character is a '"', then the escaped syntax is
in use. The filename is enclosed in "..."; inside,
Hello Karl,
> new proposal is to use octal escapes \ooo (and
> nothing else). Specifically:
>
> 1) if the first character of the source is a ", the source name extends
>to the next ". (Including :'s, for example.)
> 2) within that "...", \ooo is recognized. For instance, \042=" and \134=\,
Hello Karl,
> new proposal is to use octal escapes \ooo (and
> nothing else). Specifically:
>
> 1) if the first character of the source is a ", the source name extends
>to the next ". (Including :'s, for example.)
> 2) within that "...", \ooo is recognized. For instance, \042=" and \134=\,
> I don't see why \n should be special?
For the same reason why we should escape :, i.e. to ensure that each
line can be interpreted as FILE:LINE:MESSAGE.
Obviously we have to escape newline characters. In the original
proposal, they would be escaped as \012. I thought you were prop
Karl Berry wrote:
> pb> I think for \n too.
>
> I don't see why \n should be special?
For the same reason why we should escape :, i.e. to ensure that each
line can be interpreted as FILE:LINE:MESSAGE.
Paolo
pb> I think for \n too.
I don't see why \n should be special?
> - use \a \b \f \n \r \t \v for ASCII 7-8-12-10-13-9-11
> - use \" \\ for " and \
The simplicity and regularity of having one and only one quoting
mechanism seems appealing to me.
Filenames containing any of these chara
* Paolo Bonzini wrote on Sun, Nov 30, 2008 at 05:09:34PM CET:
>
> > The \ooo convention could be used for any character, but in an 8-bit
> > clean environment, I believe it is only *required* for " and \.
>
> I think for \n too. Also, is this supposed to be machine- or
> human-readable? If it i
> The \ooo convention could be used for any character, but in an 8-bit
> clean environment, I believe it is only *required* for " and \.
I think for \n too. Also, is this supposed to be machine- or
human-readable? If it is human-readable, I think it is better to:
- use \a \b \f \n \r \t \v for
This sounds fine to me; I'll try to make time next week to enhance the
gnulib quotearg module to output this style.
That would be great, but please wait until rms has approved it (if we
propose it). I see little point in spending time on it otherwise.
karl
it would be a good idea for that to correspond to a
style constant for the gnulib quotearg module (default_gnu_style for
example). Even if that constant has the same value as some other name
(blah_octal_quoting_style, whatever)
Agreed.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Karl Berry on 11/28/2008 11:59 AM:
> After some additional discussion with the people who brought up the
> issue in the first place (cc'd), who wanted to use url's in GNU-style
> error messages, my new proposal is to use octal escapes \ooo
On Fri, Nov 28, 2008 at 6:59 PM, Karl Berry <[EMAIL PROTECTED]> wrote:
> Some months ago we discussed a convention for supporting "special"
> characters in filenames ("sources") in error messages. Our conclusion
> then was to support C-style escapes.
I'm all for bringing a measure of consistency
Some months ago we discussed a convention for supporting "special"
characters in filenames ("sources") in error messages. Our conclusion
then was to support C-style escapes.
I wrote a patch for standards.texi saying as much and sent it to rms.
He rejected it, saying the idea was fine, but that th
23 matches
Mail list logo
