On Sat, Jun 16, 2018 at 07:43:04AM -0300, David Bremner wrote:
> Agustin Martin <agmar...@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
