Re: checkdoc-batch.el v.3

Re: checkdoc-batch.el v.3

[Stefan Monnier]

> This spot of code runs M-x checkdoc in "batch" style, giving a report of
> problems instead of going through interactively fixing them.

This sounds desirable.

> The implementation is diabolical,

That sounds less so.

I generally like checkdoc, but it's too much in-your-face for my taste.
If you're interested, it would be wonderful if you could change it so it
doesn't signal errors all the time, but just messages/warnings instead.

The intention would be:
- make it possible/bearable to enable checkdoc-mode unconditionally
  (so M-C-x will always check your docstrings, whether you want it or
  not, which clearly requires reducing substantially the
  in-your-faceness factor).
- solve the problem you mention that rejecting one suggestion can make
  you miss subsequent ones.
- make something like checkdoc-batch possible without resorting to
  a diabolical implementation.


        Stefan

Re: checkdoc-batch.el v.3

[Eric M. Ludlam]

Hi,

I missed the first post, and perhaps I have misinterpreted what the 
original post was.

On 05/12/2010 11:10 AM, Stefan Monnier wrote:
>> This spot of code runs M-x checkdoc in "batch" style, giving a report of
>> problems instead of going through interactively fixing them.
>
> This sounds desirable.

If you pass a prefix argument to checkdoc-current-buffer, and a couple 
other functions, it logs all the messages to a buffer.

If you are instead discussing the doc strings in the C code, here is 
some code I posted a long time ago:

http://lists.gnu.org/archive/html/emacs-devel/2001-11/msg00760.html

>> The implementation is diabolical,
>
> That sounds less so.
>
> I generally like checkdoc, but it's too much in-your-face for my taste.

I have found that once code is clean, checkdoc doesn't complain.  If it 
does I fix the code and it stops complaining.  If you work constantly in 
non-compliant code, this would indeed be a pain.

Checkdoc follows a model similar to unit tests for your C code.  If a 
test fails, the build fails, and you have to fix it or you can play with 
your change.

Of course, you can always set the checkdoc-autofix-flag to 'never, which 
won't ask you questions.  I don't really remember what it would do.

> If you're interested, it would be wonderful if you could change it so it
> doesn't signal errors all the time, but just messages/warnings instead.
>
> The intention would be:
> - make it possible/bearable to enable checkdoc-mode unconditionally
>    (so M-C-x will always check your docstrings, whether you want it or
>    not, which clearly requires reducing substantially the
>    in-your-faceness factor).

See above.

> - solve the problem you mention that rejecting one suggestion can make
>    you miss subsequent ones.

Using the log mode I mentioned above solves this.

Eric

Re: checkdoc-batch.el v.3

[Stefan Monnier]

>>> This spot of code runs M-x checkdoc in "batch" style, giving a report of
>>> problems instead of going through interactively fixing them.
>> This sounds desirable.
> If you pass a prefix argument to checkdoc-current-buffer, and a couple other
> functions, it logs all the messages to a buffer.

I know.  That's pretty much the only way I use checkdoc explicitly.
Note that it may still not list all problems (it seems that if there are
problems in the general file layout (e.g. missing trailer) it doesn't
move on to further things).

>> I generally like checkdoc, but it's too much in-your-face for my taste.
> I have found that once code is clean, checkdoc doesn't complain.  If it does
> I fix the code and it stops complaining.  If you work constantly in
> non-compliant code, this would indeed be a pain.

I want to turn it on unconditionally.  That means it should just be
a nag, but not a pain, if you don't care to follow its advice.
BTW, I often don't follow its advice, and other times I do but it
doesn't notice/understand it.

>> - solve the problem you mention that rejecting one suggestion can make
>> you miss subsequent ones.
> Using the log mode I mentioned above solves this.

I don't think it does completely.


        Stefan

Re: checkdoc-batch.el v.3

[Kevin Ryde]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> Note that it may still not list all problems (it seems that if there are
> problems in the general file layout (e.g. missing trailer) it doesn't
> move on to further things).

That and running on a set of files were the two main things I wanted.
I also found it a bit hard to tell quite what an add-on check should do
for multiple problems and querying the user about fix or not.  It may be
just a matter of better words there, though I might have said before it
seems run-hook-with-args-until-success in checkdoc-run-hooks ends up
meaning stop on the first problem detected by an add-on.  But perhaps
that's intended ...