Hi Joel, >> Rather than forcing the caller to deal with the indentation variable, it >> seems like it would be cleaner if warn_at automatically set the >> indentation level in a static global variable. Any subsequent >> warn_at_indent invocation would automatically use that indentation level. >> And the next warn_at invocation would reset it, etc. > > It appears that named reference message blocks have the nice property that > the location printed on the first line is not usually much shorter than > the locations printed on subsequent lines. When that's not the case, > neither your implementation nor my proposed one would indent properly.
Yes, it is correct. I've also elaborated this "nice property" in my mind. I just would like to describe my motivation for the current implementation. It is 100% correct that it is impossible to implement this kind of indentation without buffering. On the other hand, it looks to me a little bit overkilling to introduce buffering just for one kind of error messages. There was no such a need until now. This understanding (that I am doing a solution for a specific case) drove me to give the client code more control on the indentation variable. 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). -- Best regards, Alex Rozenman ([email protected]).
