Discussion:
Directory Servers in Tools menu
(too old to reply)
Glenn Morris
2018-03-03 02:45:11 UTC
Permalink
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?
Eli Zaretskii
2018-03-03 08:27:31 UTC
Permalink
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)?
Glenn Morris
2018-03-03 19:31:09 UTC
Permalink
Post by Eli Zaretskii
Post by Glenn Morris
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.)
Eli Zaretskii
2018-03-03 20:00:38 UTC
Permalink
Date: Sat, 03 Mar 2018 14:31:09 -0500
(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.
Glenn Morris
2018-03-05 18:44:11 UTC
Permalink
Post by Eli Zaretskii
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.)
Thomas Fitzsimmons
2018-03-06 00:04:41 UTC
Permalink
Hi,
Post by Glenn Morris
Post by Eli Zaretskii
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
Glenn Morris
2018-03-07 17:53:03 UTC
Permalink
Post by Thomas Fitzsimmons
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.
Thomas Fitzsimmons
2018-04-15 23:35:20 UTC
Permalink
Post by Glenn Morris
Post by Thomas Fitzsimmons
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.
Eli Zaretskii
2018-04-16 18:17:39 UTC
Permalink
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.

Loading...