GNU bug report logs - #44858
[PATCH] Make byte-compiler warn about wide docstrings

Previous Next

Full log

Message #11 received at 44858 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 44858 <at> debbugs.gnu.org
Subject: Re: bug#44858: [PATCH] Make byte-compiler warn about wide docstrings
Date: Thu, 26 Nov 2020 04:46:25 -0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> I like it.

Thanks.

>> I've been messing around with getting defuns to work, but I can't find a
>> way for it to work reliably.  The problem is that they are already macro
>> expanded when we start issuing warnings, so it's not trivial to reliably
>> separate defuns from other cases where lambda is used.
>
> I'm probably misunderstanding you completely, but do we have to separate
> between lambda and defuns?  lambdas can also have doc strings...

Indeed they can.  The problem I had was how to differentiate between the
many different macros that generate lambdas.  I didn't record the exact
details, but it got pretty messy between `defun', `define-derived-mode',
`cl-defgeneric', etc. etc.  The problem I saw was basically warnings
about symbols only visible after macro expansion, and that warnings
would point to entirely the wrong line and column.  (If anyone wants to
take a look, it should be sufficient to uncomment the lambda part in my
patch and run "make bootstrap".)

I was looking at `byte-defop-compiler-1', but that seems to only be
usable for functions and special forms?  IIUC, when we compile all
macros have been expanded and all information about what macro was used
where is lost.  But it's possible that I'm misunderstanding things, as
I'm still wrapping my head around this code.

>> (If you were to add defuns into the mix, we would get around 700
>> warnings for wide docstrings, several of which would be autogenerated.
>> We should probably look into that at some point...)
>
> Yes, the autogenerated docstrings should be fixed, too -- mostly by
> running them through `fill-paragraph'.

I tried that in e.g. define-derived-mode, but fill.el is loaded after
derived.el.  So it seems like there is some fun to be had in figuring
out the dependencies there...

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.