Directory Servers in Tools menu

Directory Servers in Tools menu

[Glenn Morris]

Does it still make sense to include "Directory Servers" in the Tools
menu by default? Perhaps it could/should only be added after loading eudc?

Re: Directory Servers in Tools menu

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 02 Mar 2018 21:45:11 -0500
> 
> 
> Does it still make sense to include "Directory Servers" in the Tools
> menu by default?

Does anyone remember why we added it in the first place, or can point
to the relevant discussion(s)?

Re: Directory Servers in Tools menu

[Glenn Morris]

Eli Zaretskii wrote:

>> Does it still make sense to include "Directory Servers" in the Tools
>> menu by default?
>
> Does anyone remember why we added it in the first place, or can point
> to the relevant discussion(s)?

The relevant change appears to be 39d632fad8, Jan 2000, which predates
the mailing list archives by several months.

(As a bbdb user, and an ldap admin, I've never used the eudc interface.
I don't think the menu entry is useful to someone unfamiliar with these
things, therefore doesn't need to be there by default.)

Re: Directory Servers in Tools menu

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Sat, 03 Mar 2018 14:31:09 -0500
> Cc: emacs-devel@gnu.org
> 
> (As a bbdb user, and an ldap admin, I've never used the eudc interface.
> I don't think the menu entry is useful to someone unfamiliar with these
> things, therefore doesn't need to be there by default.)

Then I guess you are saying we should obsolete the eudc package
itself, not just remove its menu item.

Re: Directory Servers in Tools menu

[Glenn Morris]

Eli Zaretskii wrote:

> Then I guess you are saying we should obsolete the eudc package
> itself, not just remove its menu item.

No, that's not the point I want to make.

(Background for interest only: I was wondering why
file loaddefs.el  -> "ASCII text, with very long lines"
The worst offender is the eudc menu entry, with included compat cruft.)

Re: Directory Servers in Tools menu

[Thomas Fitzsimmons]

Hi,

Glenn Morris <rgm@gnu.org> writes:

> Eli Zaretskii wrote:
>
>> Then I guess you are saying we should obsolete the eudc package
>> itself, not just remove its menu item.
>
> No, that's not the point I want to make.
>
> (Background for interest only: I was wondering why
> file loaddefs.el  -> "ASCII text, with very long lines"
> The worst offender is the eudc menu entry, with included compat cruft.)

I don't use the menu bar so I've never noticed this entry before.  I can
take a look; maybe the compatibility code isn't needed anymore and we
can remove it.  At the same time, I'll see if the "Directory Servers"
entry might be useful.

Thomas

Re: Directory Servers in Tools menu

[Glenn Morris]

Thomas Fitzsimmons wrote:

> I don't use the menu bar so I've never noticed this entry before.  I can
> take a look; maybe the compatibility code isn't needed anymore and we
> can remove it.  At the same time, I'll see if the "Directory Servers"
> entry might be useful.

Thanks for looking into this.

AFAICS, the compat code is needed if we still want to pretend people are
taking code from Emacs head and using it in XEmacs.

Looking at https://bitbucket.org/xemacs/eudc/src, this is untrue for at
least a decade. Twenty years, if we believe the copyright header.

Re: Directory Servers in Tools menu

[Thomas Fitzsimmons]

Glenn Morris <rgm@gnu.org> writes:

> Thomas Fitzsimmons wrote:
>
>> I don't use the menu bar so I've never noticed this entry before.  I can
>> take a look; maybe the compatibility code isn't needed anymore and we
>> can remove it.  At the same time, I'll see if the "Directory Servers"
>> entry might be useful.
>
> Thanks for looking into this.
>
> AFAICS, the compat code is needed if we still want to pretend people are
> taking code from Emacs head and using it in XEmacs.
>
> Looking at https://bitbucket.org/xemacs/eudc/src, this is untrue for at
> least a decade. Twenty years, if we believe the copyright header.

I looked at this.  There are definitely some simplifications that I'd
like to implement eventually, like deprecating then eliminating the
eudc-options file, and allowing a single search to span multiple
directory servers.  However, an easy first step is deprecating then
removing XEmacs support.  Can I push this NEWS entry to the emacs-26
branch?

Thomas

diff --git a/etc/NEWS b/etc/NEWS
index 4b1f673a7c..f014bff99c 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -733,6 +733,10 @@ with blank space to eshell history.
 major release of Emacs.  Users of BBDB 2.x should plan to upgrade to
 BBDB 3.x.
 
+*** Support for XEmacs is deprecated and will be removed in the next
+major release of Emacs.  XEmacs users can continue using this or a
+prior version of EUDC.
+
 ** eww
 
 *** New 'M-RET' command for opening a link at point in a new eww buffer.

Re: Directory Servers in Tools menu

[Eli Zaretskii]

> From: Thomas Fitzsimmons <fitzsim@fitzsim.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sun, 15 Apr 2018 19:35:20 -0400
> 
> I looked at this.  There are definitely some simplifications that I'd
> like to implement eventually, like deprecating then eliminating the
> eudc-options file, and allowing a single search to span multiple
> directory servers.  However, an easy first step is deprecating then
> removing XEmacs support.  Can I push this NEWS entry to the emacs-26
> branch?
> 
> Thomas
> 
> diff --git a/etc/NEWS b/etc/NEWS
> index 4b1f673a7c..f014bff99c 100644
> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -733,6 +733,10 @@ with blank space to eshell history.
>  major release of Emacs.  Users of BBDB 2.x should plan to upgrade to
>  BBDB 3.x.
>  
> +*** Support for XEmacs is deprecated and will be removed in the next
> +major release of Emacs.  XEmacs users can continue using this or a
> +prior version of EUDC.

Thanks, but I don't understand what is the practical meaning of such
an entry: it doesn't really reflect any real change in Emacs.  The
deprecation doesn't have any expression in the code; using the code
you want to deprecate will not generate any warnings to the effect
that these features are deprecated.

What I suggest instead is to actually remove those parts from the
master branch and mention the removal in NEWS on that branch.