From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Akira Yokosawa <akiyks@gmail.com>
Subject: Re: [PATCH 7/7] docs: kdoc: pretty up dump_enum()
Date: Fri, 4 Jul 2025 00:29:13 +0200 [thread overview]
Message-ID: <20250704002913.13ce8fcf@foz.lan> (raw)
In-Reply-To: <874ivtkuk9.fsf@trenco.lwn.net>
Em Thu, 03 Jul 2025 12:17:42 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
>
> > Em Tue, 1 Jul 2025 14:57:30 -0600
> > Jonathan Corbet <corbet@lwn.net> escreveu:
> >
> >> self.emit_msg(ln,
> >> - f"expecting prototype for enum {self.entry.identifier}. Prototype was for enum {declaration_name} instead")
> >> + f"expecting prototype for enum {self.entry.identifier}. "
> >> + f"Prototype was for enum {declaration_name} instead")
> >
> > Even being a big one, my personal preference would be to break the long
> > string here, as keeping together is easier for grep, but yeah, I also
> > considered breaking it ;-)
>
> Did you mean your preference would be to *not* break it?
What I meant is that I was in doubt myself of breaking long lines or
not... I opted to not break.
Yet, if you feel it looks better breaking it, go for it ;-)
> There's a non-greppable piece at the break point anyway, so I wasn't
> anticipating making life harder for anybody there.
>
> Thanks,
>
> jon
Thanks,
Mauro
next prev parent reply other threads:[~2025-07-03 22:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-01 20:57 [PATCH 0/7] Further kernel-doc tweakery Jonathan Corbet
2025-07-01 20:57 ` [PATCH 1/7] docs: kdoc: don't reinvent string.strip() Jonathan Corbet
2025-07-03 15:43 ` Mauro Carvalho Chehab
2025-07-01 20:57 ` [PATCH 2/7] docs: kdoc: micro-optimize KernRe Jonathan Corbet
2025-07-03 15:38 ` Mauro Carvalho Chehab
2025-07-03 18:14 ` Jonathan Corbet
2025-07-03 22:27 ` Mauro Carvalho Chehab
2025-07-01 20:57 ` [PATCH 3/7] docs: kdoc: remove the brcount floor in process_proto_type() Jonathan Corbet
2025-07-03 15:39 ` Mauro Carvalho Chehab
2025-07-01 20:57 ` [PATCH 4/7] docs: kdoc: rework type prototype parsing Jonathan Corbet
2025-07-03 15:46 ` Mauro Carvalho Chehab
2025-07-01 20:57 ` [PATCH 5/7] docs: kdoc: some tweaks to process_proto_function() Jonathan Corbet
2025-07-03 15:48 ` Mauro Carvalho Chehab
2025-07-01 20:57 ` [PATCH 6/7] docs: kdoc: Remove a Python 2 comment Jonathan Corbet
2025-07-02 8:23 ` Jani Nikula
2025-07-03 15:49 ` Mauro Carvalho Chehab
2025-07-01 20:57 ` [PATCH 7/7] docs: kdoc: pretty up dump_enum() Jonathan Corbet
2025-07-03 15:57 ` Mauro Carvalho Chehab
2025-07-03 18:17 ` Jonathan Corbet
2025-07-03 22:29 ` Mauro Carvalho Chehab [this message]
2025-07-03 15:01 ` [PATCH 0/7] Further kernel-doc tweakery Akira Yokosawa
2025-07-03 18:20 ` Jonathan Corbet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250704002913.13ce8fcf@foz.lan \
--to=mchehab+huawei@kernel.org \
--cc=akiyks@gmail.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.