GNU bug report logs - #6675
23.2; field, header and headers

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6675 in the body.
You can then email your comments to 6675 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Leo <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.2; field, header and headers
Date: Tue, 20 Jul 2010 07:32:13 +0100

RFC822, 2822, 5322 all seem very clear about the meaning and use of
'field' and 'header'.

However in function names and arguments in message.el and Gnus, header
usually means 'field' and headers means 'header'. Sometimes field is
used directly to mean 'field' as in message-fetch-field.

I find this inconsistency confusing. I think message.el and Gnus should
follow the same terminology used in the RFCs mentioned above and other
files, for example those in mail/, in Emacs to be consistent with their
use of 'field' and 'header'.

HTH,
Leo

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

From: Štěpán Němec <stepnem <at> gmail.com>
To: Leo <sdl.web <at> gmail.com>
Cc: 6675 <at> debbugs.gnu.org
Subject: Re: bug#6675: 23.2; field, header and headers
Date: Tue, 20 Jul 2010 11:06:50 +0200

Leo <sdl.web <at> gmail.com> writes:

> RFC822, 2822, 5322 all seem very clear about the meaning and use of
> 'field' and 'header'.
>
> However in function names and arguments in message.el and Gnus, header
> usually means 'field' and headers means 'header'. Sometimes field is
> used directly to mean 'field' as in message-fetch-field.
>
> I find this inconsistency confusing. I think message.el and Gnus should
> follow the same terminology used in the RFCs mentioned above and other
> files, for example those in mail/, in Emacs to be consistent with their
> use of 'field' and 'header'.

Just in case you didn't know and it might be of some help/reference:

(info "(gnus)Headers")
(info "(gnus)Terminology")

My take on it is: consistency surely is nice, but I never felt this to
be a problem with Gnus (IOW, I see there is a lot of problems with
inconsistent identifier naming, not only in Gnus, but in Emacs in
general (as in any software of its size), but I don't see a problem with
headers/fields in particular); bigger concern for me is that some
not-necessarily-very-careful-and-well-thought-out change to the manual
or even function names as you seem to suggest would make things only
worse.

Štěpán

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

From: Leo <sdl.web <at> gmail.com>
To: Štěpán Němec <stepnem <at> gmail.com>
Cc: 6675 <at> debbugs.gnu.org
Subject: Re: bug#6675: 23.2; field, header and headers
Date: Tue, 20 Jul 2010 21:29:12 +0100

On 2010-07-20 10:06 +0100, Štěpán Němec wrote:
> Just in case you didn't know and it might be of some help/reference:
>
> (info "(gnus)Headers")
> (info "(gnus)Terminology")

Anyway, having a closer look at mail/, I found it also has
inconsistency.

> My take on it is: consistency surely is nice, but I never felt this to
> be a problem with Gnus (IOW, I see there is a lot of problems with
> inconsistent identifier naming, not only in Gnus, but in Emacs in
> general (as in any software of its size), but I don't see a problem
> with headers/fields in particular); bigger concern for me is that some
> not-necessarily-very-careful-and-well-thought-out change to the manual
> or even function names as you seem to suggest would make things only
> worse.

Gnus seems to be in maintenance mode for years. So I don't suppose
someone would take the trouble to think it out well.

Leo

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

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: 6675 <at> debbugs.gnu.org
Subject: Re: bug#6675: 23.2; field, header and headers
Date: Thu, 30 Jun 2011 02:15:01 +0200

tags 6775 wontfix
close 6775
thanks

Leo <sdl.web <at> gmail.com> writes:

> However in function names and arguments in message.el and Gnus, header
> usually means 'field' and headers means 'header'. Sometimes field is
> used directly to mean 'field' as in message-fetch-field.
>
> I find this inconsistency confusing. I think message.el and Gnus should
> follow the same terminology used in the RFCs mentioned above and other
> files, for example those in mail/, in Emacs to be consistent with their
> use of 'field' and 'header'.

Yes, it's unfortunate that (especially older) functions in Gnus use
"field" where we really mean "header", but changing function names and
breaking third-party code for consistency here isn't worth it.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

From: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#6675: 23.2; field, header and headers
Date: Wed, 29 Jun 2011 20:28:13 -0600

On 6/29/11 6:15 PM, Lars Magne Ingebrigtsen wrote:
> tags 6775 wontfix
> close 6775
> thanks
>
> Leo<sdl.web <at> gmail.com>  writes:
>
>> However in function names and arguments in message.el and Gnus, header
>> usually means 'field' and headers means 'header'. Sometimes field is
>> used directly to mean 'field' as in message-fetch-field.
>>
>> I find this inconsistency confusing. I think message.el and Gnus should
>> follow the same terminology used in the RFCs mentioned above and other
>> files, for example those in mail/, in Emacs to be consistent with their
>> use of 'field' and 'header'.
>
> Yes, it's unfortunate that (especially older) functions in Gnus use
> "field" where we really mean "header", but changing function names and
> breaking third-party code for consistency here isn't worth it.

defalias + make-obsolete = define-obsolete-function-alias

-- 
Kevin Rodgers
Denver, Colorado, USA

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

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
Cc: 6675 <at> debbugs.gnu.org, bugs <at> gnus.org
Subject: Re: bug#6675: 23.2; field, header and headers
Date: Thu, 30 Jun 2011 04:34:54 +0200

tags 6675 wontfix
close 6675
thanks

Kevin Rodgers <kevin.d.rodgers <at> gmail.com> writes:

>> Yes, it's unfortunate that (especially older) functions in Gnus use
>> "field" where we really mean "header", but changing function names and
>> breaking third-party code for consistency here isn't worth it.
>
> defalias + make-obsolete = define-obsolete-function-alias

Not worth the churn.  Or breaking stuff eventually.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

From: Glenn Morris <rgm <at> gnu.org>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 6675 <at> debbugs.gnu.org
Subject: Re: bug#6675: 23.2; field, header and headers
Date: Wed, 29 Jun 2011 23:14:01 -0400

Lars Magne Ingebrigtsen wrote:

> tags 6775 wontfix
> close 6775
> thanks

FYI this kind of thing has no effect unless you cc (I recommend bcc if
you are including non-control stuff for other addresses) control <at> debbugs.

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

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 6675 <at> debbugs.gnu.org, bugs <at> gnus.org
Subject: Re: bug#6675: 23.2; field, header and headers
Date: Thu, 30 Jun 2011 12:56:51 +0200

tags 6675 wontfix
close 6675
thanks

Glenn Morris <rgm <at> gnu.org> writes:

> FYI this kind of thing has no effect unless you cc (I recommend bcc if
> you are including non-control stuff for other addresses) control <at> debbugs.

Thanks again.  One of these centuries I'm going to get the hang of using
debbugs, I'm sure...

(This time with Bcc to control.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Previous Next

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