--- Begin Message ---
|
Subject: |
Re: address@hidden: extra compilation patterns] |
|
Date: |
Thu, 28 Oct 2004 17:12:39 +0100 |
|
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/21.2 (gnu/linux) |
address@hidden (Daniel Pfeiffer) writes:
> They shoud force compiler builders to parse their output ? there'd be less
> rubbish!
I got the author to change the format of the main messages some time
ago if I remember correctly.
> This stupid thing has 3 different kinds of output, arbitrarily with
> or without filenames and with "Warning" any number of lines before. A
> nightmare for compile...
People writing tools typically don't expect them to be used like that,
though I'd have hoped at least NAG would have used a standard format
and not changed their old one.
> I've added three constructs that handle everything I found on their website,
The suggestions I sent were based on the actual source and were
tested. At least some examples in the doc were wrong.
> save for
>
> Warning in module COMPAV: Variables may be used before set:
> SUM used at line 14
> SUM set at line 14
>
> which comes out as errors.
That isn't the form of message it currently produces -- see the
examples I gave.
> I'm not very comfortable with this kind of thing, since I get a feeling that
> compilation parsing is already signigicantly slower, than when I first
> submitted it. Piling in crazy regexps to match everything under the sun might
> be the wrong way.
Of course. E.g. the ftnchek patterns probably only make sense in a
Fortran context. They're unlikely to be generated by normal make
targets for packages, for instance. I dare say others are quite
context-dependent.
> I wonder how many people really use the feature of selecting a subset of the
> regexps. Maybe all regexps should be off by default, forcing people to take a
> look at what they really need. Not very covenient...
Surely at least canonical GNU ones should be on. It's possibly
reasonable to turn off a lot by default, but the list should be easier
to customize in that case. The current names are at least confusing
and difficult to understand, with no help in the Custom buffer. You
also can't customize the list to add your own regexps directly.
The compilation buffer could provide users with a facility to select
additional canned patterns by example and to test them against lines
in the buffer.
Other things which still aren't customizable include
compilation-mode-font-lock-keywords, compilation-highlight-regexp,
compilation-environment.
By the way, GNU compilation regexps were supposed to get matches for
the convection used by g77 (which should be supported by other tools).
References to explanations in the manual as trailing items like
`[info -f g77 M GLOBALS]' should hyperlink to the info node.
(I don't know why burley didn't use `[info -f g77 -n GLOBALS]' -- that
should also be matched.)
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: address@hidden: extra compilation patterns] |
|
Date: |
Sun, 31 Oct 2004 14:44:09 +0000 |
|
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/21.2 (gnu/linux) |
address@hidden (Daniel Pfeiffer) writes:
>> Of course. E.g. the ftnchek patterns probably only make sense in a
>> Fortran context. They're unlikely to be generated by normal make
>> targets for packages, for instance. I dare say others are quite
>> context-dependent.
>
> Some modes set up their own patterns. That leaves the clutter out of the
> overall list, but means that you can't call a multicompiler make from those
> buffers...
As I said, ftnchek isn't likely to be called from a normal make
target, because it's not a compiler.
> Other than fairly precise compiler names (often enough with version info)
> would be the only helpful name.
The currently-used names are confusing/misleading in various cases, as
I've said before. `irix' is a case in point. It may be possible to
label them usefully with symbolic names like `in-line-N-of-file-F'
which describe the patterns.
> But then you don't get to have multicompiler
> groups, which accept minor variations. I think by far the best thing is the
> examples file which is linked from the custom buffer ? alas at the very
> bottom, where few will find it.
The pattern examples could be associated with the items in the Custom
buffer. That would be more convenient.
>> The compilation buffer could provide users with a facility to select
>> additional canned patterns by example and to test them against lines
>> in the buffer.
>
> Not quite sure how you intend to do that. So just give it a try and we'll
> see :-)
You allow the user to select an item in the compilation output and try
matching it with all the patterns not currently in the regexp list.
Then they can select from the pattern that match to add to the error
regexp list.
>> Other things which still aren't customizable include
>> compilation-mode-font-lock-keywords, compilation-highlight-regexp,
>> compilation-environment.
>
> The latter sounds ok. But people who can write regexps and even list
> structures can write a setq in front of it!
I don't know what that means. The relevant variables need customizing
and you need to be able to set all the relevant values that way. If
you're trying to discourage people from using Custom, please don't.
I want to use it, and I'm certainly not a naive user.
>> By the way, GNU compilation regexps were supposed to get matches for
>> the convection used by g77 (which should be supported by other tools).
convention
>> References to explanations in the manual as trailing items like
>> `[info -f g77 M GLOBALS]' should hyperlink to the info node.
>> (I don't know why burley didn't use `[info -f g77 -n GLOBALS]' -- that
>> should also be matched.)
>
> You lost me here. I've never seen anything like that. Does this
> program output that string?
Yes.
> And what should it link to precisely?
The string in brackets is the command you're meant to invoke to get an
explanation, equivalent to `(info "(g77)GLOBALS")' in this case.
> A g77 info at page 'GLOBALS'? Is such a notation an emerging
> standard, always in square brackets?
I don't know whether other programs use it now, but rms thought it was
a good idea for GNU programs. As far as I remember, he didn't want
the change made to compilation mode at the time I offered it.
--- End Message ---