[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Unversioned emacs packages uploaded to experimental



On Sat, Jun 16, 2018 at 07:43:04AM -0300, David Bremner wrote:
> Agustin Martin <agmartin@debian.org> writes:
> > dictionaries-common ships some .el files for Emacs and XEmacs use.
> > Emacs only needs debian-ispell.el, but XEmacs also needs ispell.el and
> > flyspell.el for the spellchecking integration to work.
> 
> I hope that xemacs support is not too much extra work.  I think
> xemacs21-mule now has less users than emacs23 [1], which is present only
> in oldoldstable.  Dropping xemacs support would allow you to use
> dh-elpa, and avoid these particular problems. Of course small groups of
> users may still be unhappy and complain, it's your call.

Hi, David,

XEmacs is in Debian and is currently supported. While I am aware of its
current popularity and of the big difference between the number of
contributors for both, it should remain supported as long as we ship it.

> > I could just avoid symlink setting for unversioned Emacs, but there is
> > an aditional problem with it. For byte-compiled files to be available
> > I'll need to add that path to the search list, which will have as a
> > side effect that ispell.el and flyspell.el will be used by Emacs
> > instead of those provided by the package. No problem for XEmacs.
> 
> Are you worried here about emacs loading the source files instead of the
> byte-compiled ones?  By default emacs loads the .elc even if the .el is
> newer (see the variable load-prefer-newer). It's also usually not that
> big a deal to skip byte compilation (the exception being some uses of
> macros). You could try just putting the .el files in the load path and
> see how that goes. I just tried ispell-buffer uncompiled, and it seems
> fine.

This is true when both files are in the same dir and so, in the same
location in the search path, but not otherwise

$ emacs25 && enable spellchecking && eval (message "%s" ispell-version)
ispell.el 3.6 - 7-Jan-2003

However, this is not true when they are at different dirs in the load-path.
First dir with a match will win

$ cp /usr/share/emacs/site-lisp/dictionaries-common/{i,fly}spell.el /usr/share/emacs/25.2/site-lisp/dictionaries-common
$ emacs25 && enable spellchecking && eval (message "%s" ispell-version)
ispell.el 3.6 - 7-Jan-2003 (+ Debian `dictionaries-common' changes)

So, although {i,fly}spell.elc exists as shipped by Emacs, they are overriden
by {i,fly}spell.el present in /usr/share/emacs/25.2/site-lisp/dictionaries-common

This is the same that I'd expect to happen for unversioned Emacs.

> > This has an additional advantage. Some people use personal Emacs
> > builds and there is sometimes a subdirs.el in
> > /usr/share//emacs/site-lisp/, resulting in ispell.el and flyspell.el
> > being loaded even if it was not intended.
> 
> This seems related to the discussion above about byte-compilation, I'm
> not 100% sure. I would say that user modification of files in
> /usr/share/emacs/site-lisp is not supported (if that's what your
> discussing).

I was active some time in upstream Emacs development regarding ispell.el
and flyspell.el and still track messages from emacs-bugs and emacs-diffs
containing the string "spell".

I have noticed that there is a number of bug reports where
dictionaries-common {i,fly}spell.el is masking {i,fly}spell.elc, although
this should not happen,

/usr/share/emacs/site-lisp/dictionaries-common/ispell hides /usr/share/emacs/25.3/lisp/textmodes/ispell

See e.g.

https://debbugs.gnu.org/31609

I do not know how this can happen, although my guess is the presence of subdirs.el
in /usr/share/emacs/site-lisp, but apart from that guess I am clueless. Did
not ask the submitter for details, sorry.

> > I am thinking about putting the .el files under
> > /usr/share/dictionaries-common/emacs/site-lisp and set symlinks to the
> > contents I need from
> > /usr/share/{emacs,xemacs21}/site-lisp/dictionaries-common/.
> 
> I don't see any problem with this, but I'm not an emacsen-policy expert.

That was just a wild suggestion, I'd still prefer for the .el sources
some place under /usr/share/emacs, but completely outside the load-path,
something like

/usr/share/emacs/debian-addons-elisp

with policy blessings.

Regards,

-- 
Agustin


Reply to: