Bison-1.28: Port IDE error messages; startup arguments

[Hans Aberg]

I can add that in order to make sure that every info/warning/error message
is properly in the IDE message window I deflected stderr into a buffer,
which when the program terminates is fed into the IDE message window.

The difference between this approach and going into the code and feeding
each separate message into the IDE is that the latter approach gives a row
of entries in the IDE message window which each can be identified in the
original file by a click in the window. Thus the latter approach is to be
preferred. But by combining them, I can make sure no message is lost, and
one can dress up the port up as one has time. It is also desirable to have
as few originating info/warning/error functions as possible in the source
code, because then one can just go into just them, replacing those by the
IDE interfacing stuff.

As for this type of IDE, one does not have a Make program really, so the
startup arguments has to be provided by other means. For the global
settings, one can develop a target settings panel, but this does not work
for local, file specific arguments. In the port of the Haskell interpreter
Hugs http:haskell.org/hugs, it uses Bison for Haskell, and I use it for
implementing AppleEvent's, which are binary information packets programs
can pass to each other in communications. Then the problem arouse with
Bison name output conflicts, which can be fixed by "--name-prefix=", but
not via a global GUI control panel.

So all such arguments that are file specific, one should be able to control
by pragmas (or %-commands in Bison).

In the port I made, I fixed this problem by allowing one to add a <name>.ym
("m" for "make") which must reside in the same directory as the
corresponding .y file, and which contains the startup arguments. (And
similarly, with Flex, one can have a .lm file).

Thus the port has full functionality in this respect. (Created files are
flipped into the project, and autmoatically compiled, so a "Make" program
is not need for this part.)

-- As for the problem with not closing files and deleting them, under C++
one can wrap the creation/opening, closing/removing of temporary files in a
class, and then use that as an automatic variable. If one then terminates
the program by throwing an exception, those resources will automatically be
reclaimed, and thus it works as a library as well.

Specifically, it would look something like this:
class TempFile {
    Data: Filepointer, name.
public:
    TempFile(...); // Constructor, creates & opens temp file.
    ~TempFile();   // Destructor, closes & removes file.
    // Other interface stuff.
};

Use:
    ...
    TempFile tmp(...);   // Create & open file. Will automatically
                         // be reclaimed when out of scope.

-- Or whatever variation is good for you. :-)

  Hans Aberg