* bug#39137: 26.3; ispell-really-hunspell sometimes fails in init
@ 2020-01-14 21:25 Bob Rogers
2020-01-18 10:14 ` Eli Zaretskii
0 siblings, 1 reply; 5+ messages in thread
From: Bob Rogers @ 2020-01-14 21:25 UTC (permalink / raw)
To: 39137
Spell checking can die with "(wrong-type-argument stringp nil)" when
ispell-really-hunspell is true. To reproduce (if it reproduces at all
on your system), just do "emacs -Q" with Hunspell installed and M-$ on
any of the words in the startup screen.
On some of the systems I use, it fails reliably when initializing; on
others, it works reliably. All systems are running the openSUSE Leap
15.1 release of GNU/Linux, fully updated, with the identical locally-
built RPM version of Emacs 26.3 (with no local patches) and the distro
Hunspell 1.6.2. The key seems to be whether ispell-dictionary-alist is
initialized before ispell-start-process is called; just a warning to
anyone who fails to reproduce this. But since it fails in "emacs -Q" on
systems with apparently identical software, I am at a complete loss to
figure this out.
When it fails, the backtrace looks like this:
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
string-match("," nil 0)
split-string(nil "," t)
ispell-parse-hunspell-affix-file(nil)
ispell-hunspell-fill-dictionary-entry(nil)
ispell-start-process()
ispell-init-process()
ispell-buffer-local-words()
ispell-accept-buffer-local-defs()
ispell-word(nil nil nil t)
funcall-interactively(ispell-word nil nil nil t)
call-interactively(ispell-word nil nil)
command-execute(ispell-word)
The problem seems to be related to this code in the start of
ispell-start-process:
;; Parse hunspell affix file if using hunspell and entry is uninitialized.
(if ispell-really-hunspell
(or (cadr (assoc ispell-current-dictionary ispell-dictionary-alist))
(ispell-hunspell-fill-dictionary-entry ispell-current-dictionary)))
It appears that "nil" is valid for ispell-current-dictionary and means
"default", but ispell-hunspell-fill-dictionary-entry expects only a
string. On that basis, I would claim that there is a bug that has
perhaps been hidden by being on a rare execution path. But if
ispell-dictionary-alist is already initialized with a "nil" entry, then
ispell-hunspell-fill-dictionary-entry never gets called, leading to the
"reproducible irreproducibility" of this bug. And if
ispell-dictionary-alist should *always* be initialized and contain the
current entry, then this is dead code.
I don't know where or how ispell-current-dictionary is getting set up
on some systems but not on others, nor how it ought to be set up, so I
am unable to take this any further.
-- Bob Rogers
Modular Genetics Inc.
http://www.modulargenetics.com/
------------------------------------------------------------------------
In GNU Emacs 26.3 (build 1, x86_64-suse-linux-gnu, GTK+ Version 3.22.30)
of 2019-11-21 built on yuggoth
Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Entering debugger...
Configured using:
'configure --with-pop --without-dbus --without-gsettings
--without-gconf --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --sharedstatedir=/var/lib --libexecdir=/usr/lib
--with-x --with-xpm=no --with-jpeg --with-tiff --with-gif=no --with-png
--with-x-toolkit=gtk3 --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib64 --build x86_64-suse-linux 'CFLAGS=-g -O2
-fno-optimize-sibling-calls' LDFLAGS=-s'
Configured features:
JPEG TIFF PNG RSVG SOUND GLIB NOTIFY GNUTLS LIBXML2 FREETYPE XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Debugger
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny seq dired
dired-loaddefs format-spec rfc822 mml mml-sec password-cache epa derived
epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils help-mode
easymenu cl-print byte-opt gv bytecomp byte-compile cl-loaddefs cl-lib
cconv debug ispell elec-pair time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads inotify dynamic-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 100243 8442)
(symbols 48 20704 1)
(miscs 40 88 143)
(strings 32 30091 1374)
(string-bytes 1 795489)
(vectors 16 15184)
(vector-slots 8 514416 10616)
(floats 8 55 85)
(intervals 56 284 0)
(buffers 992 12))
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#39137: 26.3; ispell-really-hunspell sometimes fails in init
2020-01-14 21:25 bug#39137: 26.3; ispell-really-hunspell sometimes fails in init Bob Rogers
@ 2020-01-18 10:14 ` Eli Zaretskii
2021-01-29 7:27 ` Lars Ingebrigtsen
0 siblings, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2020-01-18 10:14 UTC (permalink / raw)
To: Bob Rogers; +Cc: 39137
> From: Bob Rogers <rogers@modulargenetics.com>
> Date: Tue, 14 Jan 2020 16:25:07 -0500
>
> Spell checking can die with "(wrong-type-argument stringp nil)" when
> ispell-really-hunspell is true. To reproduce (if it reproduces at all
> on your system), just do "emacs -Q" with Hunspell installed and M-$ on
> any of the words in the startup screen.
Granted, this doesn't reproduce on my system. And I have difficulty
understanding how could it reproduce on _any_ system, especially in
"emacs -Q".
> On some of the systems I use, it fails reliably when initializing; on
> others, it works reliably. All systems are running the openSUSE Leap
> 15.1 release of GNU/Linux, fully updated, with the identical locally-
> built RPM version of Emacs 26.3 (with no local patches) and the distro
> Hunspell 1.6.2. The key seems to be whether ispell-dictionary-alist is
> initialized before ispell-start-process is called
Can you step through the ispell.el's initialization code, and explain
how come ispell-dictionary-alist ends up being uninitialized by the
time ispell-start-process is called for spell-checking? This
shouldn't happen.
> ;; Parse hunspell affix file if using hunspell and entry is uninitialized.
> (if ispell-really-hunspell
> (or (cadr (assoc ispell-current-dictionary ispell-dictionary-alist))
> (ispell-hunspell-fill-dictionary-entry ispell-current-dictionary)))
>
> It appears that "nil" is valid for ispell-current-dictionary and means
> "default", but ispell-hunspell-fill-dictionary-entry expects only a
> string. On that basis, I would claim that there is a bug that has
> perhaps been hidden by being on a rare execution path. But if
> ispell-dictionary-alist is already initialized with a "nil" entry, then
> ispell-hunspell-fill-dictionary-entry never gets called, leading to the
> "reproducible irreproducibility" of this bug. And if
> ispell-dictionary-alist should *always* be initialized and contain the
> current entry, then this is dead code.
It isn't dead code, it just assumes that either
ispell-current-dictionary is nil and there's a nil entry in
ispell-dictionary-alist, or it is a string that specifies a new
dictionary, which is then used to update ispell-dictionary-alist.
We need to establish how come the first assumption is false on those
affected systems.
Thanks.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#39137: 26.3; ispell-really-hunspell sometimes fails in init
2020-01-18 10:14 ` Eli Zaretskii
@ 2021-01-29 7:27 ` Lars Ingebrigtsen
2021-03-23 22:13 ` Bob Rogers
0 siblings, 1 reply; 5+ messages in thread
From: Lars Ingebrigtsen @ 2021-01-29 7:27 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 39137, Bob Rogers
Eli Zaretskii <eliz@gnu.org> writes:
> Can you step through the ispell.el's initialization code, and explain
> how come ispell-dictionary-alist ends up being uninitialized by the
> time ispell-start-process is called for spell-checking? This
> shouldn't happen.
More information was requested, but no response was given within a
year, so I'm closing this bug report. If the problem still exists,
please respond to this email and we'll reopen the bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#39137: 26.3; ispell-really-hunspell sometimes fails in init
2021-01-29 7:27 ` Lars Ingebrigtsen
@ 2021-03-23 22:13 ` Bob Rogers
2021-03-24 8:11 ` Lars Ingebrigtsen
0 siblings, 1 reply; 5+ messages in thread
From: Bob Rogers @ 2021-03-23 22:13 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 39137
From: Lars Ingebrigtsen <larsi@gnus.org>
Date: Fri, 29 Jan 2021 08:27:00 +0100
Eli Zaretskii <eliz@gnu.org> writes:
> Can you step through the ispell.el's initialization code, and explain
> how come ispell-dictionary-alist ends up being uninitialized by the
> time ispell-start-process is called for spell-checking? This
> shouldn't happen.
More information was requested, but no response was given within a
year, so I'm closing this bug report. If the problem still exists,
please respond to this email and we'll reopen the bug report.
My apologies for being so lazy, but I finally got around to checking
this out. I went to reproduce the problem and found that the current
Emacs 27.2-rc2 on the affected system now produces the following error
message:
ispell-find-hunspell-dictionaries: Can t find Hunspell dictionary with a .aff affix file
So it was a Hunspell configuration issue (further investigation found
the missing RPM), and not an Emacs problem. And I'm glad to see that
the Hunspell initialization now reports this intelligibly.
-- Bob
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#39137: 26.3; ispell-really-hunspell sometimes fails in init
2021-03-23 22:13 ` Bob Rogers
@ 2021-03-24 8:11 ` Lars Ingebrigtsen
0 siblings, 0 replies; 5+ messages in thread
From: Lars Ingebrigtsen @ 2021-03-24 8:11 UTC (permalink / raw)
To: Bob Rogers; +Cc: 39137
Bob Rogers <rogers@modulargenetics.com> writes:
> ispell-find-hunspell-dictionaries: Can t find Hunspell dictionary with a .aff affix file
>
> So it was a Hunspell configuration issue (further investigation found
> the missing RPM), and not an Emacs problem. And I'm glad to see that
> the Hunspell initialization now reports this intelligibly.
Thanks for checking.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-03-24 8:11 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-01-14 21:25 bug#39137: 26.3; ispell-really-hunspell sometimes fails in init Bob Rogers
2020-01-18 10:14 ` Eli Zaretskii
2021-01-29 7:27 ` Lars Ingebrigtsen
2021-03-23 22:13 ` Bob Rogers
2021-03-24 8:11 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.