This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Stop putting function comments in foo.h
- From: Doug Evans <dje at google dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Wed, 26 Mar 2014 09:45:27 -0700
- Subject: Re: [RFC] Stop putting function comments in foo.h
- Authentication-results: sourceware.org; auth=none
- References: <CADPb22QBBrYB70YoL-Aqyfi77gphGija4zK5mSgYckwfZ7e84g at mail dot gmail dot com> <53271DC0 dot 3050405 at redhat dot com> <CADPb22Qfo62gA-70Xqo8OUQUKs2U1qpBv-hnpJyAxF6eMnSobg at mail dot gmail dot com>
On Tue, Mar 18, 2014 at 8:59 AM, Doug Evans <dje@google.com> wrote:
> On Mon, Mar 17, 2014 at 9:07 AM, Pedro Alves <palves@redhat.com> wrote:
>> IMO, a module's API documentation should be in its header file, as
>> that's where the module's "public" contract is defined.
>> Needing to peek at the module's implementation feels wrong to me.
>> If the function's documentation isn't clear without looking
>> at the function's body, something is already wrong with
>> the comment.
>
> It use to be that M-. took me to the function definition and its documentation.
>
> I'm curious what other emacs+etags users do now.
fwiw, I'd REALLY like an answer to this.
M-. worked great before people started moving function comments to headers.
I can be looking at any function in the source, put the cursor over
its name, M-. RET, and voila! I'm reading the function's comment or I
I can begin hacking/reading its implementation.
People are breaking a common existing practice without offering a
replacement. Why isn't that "Not cool."?
If I'm missing something I'll happily document it in the wiki, augment
Makefile's, or whatever.
I just want to continue to be able to hack on gdb as easily as I could
before people started doing this.