bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Keep sub-messages aligned. Fix strings for translation.


From: Joel E. Denny
Subject: Re: [PATCH] Keep sub-messages aligned. Fix strings for translation.
Date: Tue, 6 Oct 2009 12:59:57 -0400 (EDT)
User-agent: Alpine 1.00 (DEB 882 2007-12-20)

On Sat, 3 Oct 2009, Alex Rozenman wrote:

> The real question here: is there other places in Bison, where you
> needed such a complex kind of error message output ? If we will decide
> to implement the buffering, I can do that (the obvious price - more
> complex code in complain.c).

Let's put it off as I'm short on time anyway.  What we have seems to work 
well enough for what we're currently using it for.  Thanks for that.

I pushed this to master.

>From 3c5362b825a9d01eafe257943b7faad92ea43a05 Mon Sep 17 00:00:00 2001
From: Joel E. Denny <address@hidden>
Date: Tue, 6 Oct 2009 12:47:47 -0400
Subject: [PATCH] * TODO (Complaint submessage indentation): New.

---
 ChangeLog |    4 ++++
 TODO      |   17 +++++++++++++++++
 2 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 90f6c23..5bbab03 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2009-10-06  Joel E. Denny  <address@hidden>
+
+       * TODO (Complaint submessage indentation): New.
+
 2009-10-04  Joel E. Denny  <address@hidden>
 
        Minor code cleanup.
diff --git a/TODO b/TODO
index c3aac31..7f4c514 100644
--- a/TODO
+++ b/TODO
@@ -455,6 +455,23 @@ to bison. If you're interested, I'll work on a patch.
 * Better graphics
 Equip the parser with a means to create the (visual) parse tree.
 
+* Complaint submessage indentation.
+We already have an implementation that works fairly well for named
+reference messages, but it would be nice to use it consistently for all
+submessages from Bison.  For example, the "previous definition"
+submessage or the list of correct values for a %define variable might
+look better with indentation.
+
+However, the current implementation makes the assumption that the
+location printed on the first line is not usually much shorter than the
+locations printed on the submessage lines that follow.  That assumption
+may not hold true as often for some kinds of submessages especially if
+we ever support multiple grammar files.
+
+Here's a proposal for how a new implementation might look:
+
+  http://lists.gnu.org/archive/html/bison-patches/2009-09/msg00086.html
+
 -----
 
 Copyright (C) 2001, 2002, 2003, 2004, 2006, 2008-2009 Free Software
-- 
1.5.4.3





reply via email to

[Prev in Thread] Current Thread [Next in Thread]