GNU bug report logs -
#40238
Trying to customize the ispell choices buffer via display-buffer-alist has no effect
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40238 in the body.
You can then email your comments to 40238 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40238
; Package
emacs
.
(Thu, 26 Mar 2020 14:57:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Konrad Podczeck <konrad.podczeck <at> univie.ac.at>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 26 Mar 2020 14:57:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
There is no effect if in display-buffer-alist the ispell choices buffer is customized, e.g. in the form
("\\*Choices\\*"
(display-buffer-reuse-window display-buffer-pop-up-frame)
(pop-up-frame-parameters
(tool-bar-lines . 0)
(font . "Monaco-12")
(left . 778)
(top . 280) (height . 12) (width . 78)
))
Konrad
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40238
; Package
emacs
.
(Thu, 26 Mar 2020 15:30:03 GMT)
Full text and
rfc822 format available.
Message #8 received at 40238 <at> debbugs.gnu.org (full text, mbox):
> There is no effect if in display-buffer-alist the ispell choices buffer is customized, e.g. in the form
>
> ("\\*Choices\\*"
> (display-buffer-reuse-window display-buffer-pop-up-frame)
> (pop-up-frame-parameters
> (tool-bar-lines . 0)
> (font . "Monaco-12")
> (left . 778)
> (top . 280) (height . 12) (width . 78)
> ))
Intentionally so. IIRC, displaying *Choices* was initially even more
rigid - it didn't use 'display-buffer' at all.
The solution is to set 'ispell-choices-win-default-height' to a very
large value so that in practice 'split-window' can never make a window
that high. If after some time you come to the conclusion that this
trick works satisfactorily, we can mention it somewhere at your choice.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40238
; Package
emacs
.
(Thu, 26 Mar 2020 15:53:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 40238 <at> debbugs.gnu.org (full text, mbox):
Thanks!
Basically this works fine. However, when I type ‘x’ to exit ispell, the buffer which was spelled appears a second time in the frame that showed the choices. If I type ‘q’ to quit ispell, the answer to the “yes-or-no” prompt has not the intended effect but becomes written in the frame showing the choices.
Konrad
> Am 26.03.2020 um 16:29 schrieb martin rudalics <rudalics <at> gmx.at>:
>
> > There is no effect if in display-buffer-alist the ispell choices buffer is customized, e.g. in the form
> >
> > ("\\*Choices\\*"
> > (display-buffer-reuse-window display-buffer-pop-up-frame)
> > (pop-up-frame-parameters
> > (tool-bar-lines . 0)
> > (font . "Monaco-12")
> > (left . 778)
> > (top . 280) (height . 12) (width . 78)
> > ))
>
> Intentionally so. IIRC, displaying *Choices* was initially even more
> rigid - it didn't use 'display-buffer' at all.
>
> The solution is to set 'ispell-choices-win-default-height' to a very
> large value so that in practice 'split-window' can never make a window
> that high. If after some time you come to the conclusion that this
> trick works satisfactorily, we can mention it somewhere at your choice.
>
> martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40238
; Package
emacs
.
(Thu, 26 Mar 2020 16:24:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 40238 <at> debbugs.gnu.org (full text, mbox):
Remembering what you told me, the problem with “x” to exit ispell is solvable by inserting (dedicated . t) in the customization below. The other problem is not affected by this.
Konrad
> Am 26.03.2020 um 16:52 schrieb Konrad Podczeck <konrad.podczeck <at> univie.ac.at>:
>
> Thanks!
>
> Basically this works fine. However, when I type ‘x’ to exit ispell, the buffer which was spelled appears a second time in the frame that showed the choices. If I type ‘q’ to quit ispell, the answer to the “yes-or-no” prompt has not the intended effect but becomes written in the frame showing the choices.
>
> Konrad
>
>
>> Am 26.03.2020 um 16:29 schrieb martin rudalics <rudalics <at> gmx.at>:
>>
>>> There is no effect if in display-buffer-alist the ispell choices buffer is customized, e.g. in the form
>>>
>>> ("\\*Choices\\*"
>>> (display-buffer-reuse-window display-buffer-pop-up-frame)
>>> (pop-up-frame-parameters
>>> (tool-bar-lines . 0)
>>> (font . "Monaco-12")
>>> (left . 778)
>>> (top . 280) (height . 12) (width . 78)
>>> ))
>>
>> Intentionally so. IIRC, displaying *Choices* was initially even more
>> rigid - it didn't use 'display-buffer' at all.
>>
>> The solution is to set 'ispell-choices-win-default-height' to a very
>> large value so that in practice 'split-window' can never make a window
>> that high. If after some time you come to the conclusion that this
>> trick works satisfactorily, we can mention it somewhere at your choice.
>>
>> martin
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40238
; Package
emacs
.
(Thu, 26 Mar 2020 17:37:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 40238 <at> debbugs.gnu.org (full text, mbox):
> Basically this works fine. However, when I type ‘x’ to exit ispell,
> the buffer which was spelled appears a second time in the frame that
> showed the choices. If I type ‘q’ to quit ispell, the answer to the
> “yes-or-no” prompt has not the intended effect but becomes written in
> the frame showing the choices.
It's a 'y-or-n-p' prompt here and it asks me (unfortunately in the
original frame) "Really kill Ispell process? ". If I now type "y" here,
the frame gets killed. With 'ispell-word' via M-$.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40238
; Package
emacs
.
(Thu, 26 Mar 2020 18:06:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 40238 <at> debbugs.gnu.org (full text, mbox):
I see. So, is there a customization, or some code, which gives, only for the ispell problem, an unconditional kill rather than a y-or-n-p?
> Am 26.03.2020 um 18:36 schrieb martin rudalics <rudalics <at> gmx.at>:
>
> > Basically this works fine. However, when I type ‘x’ to exit ispell,
> > the buffer which was spelled appears a second time in the frame that
> > showed the choices. If I type ‘q’ to quit ispell, the answer to the
> > “yes-or-no” prompt has not the intended effect but becomes written in
> > the frame showing the choices.
>
> It's a 'y-or-n-p' prompt here and it asks me (unfortunately in the
> original frame) "Really kill Ispell process? ". If I now type "y" here,
> the frame gets killed. With 'ispell-word' via M-$.
>
> martin
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40238
; Package
emacs
.
(Thu, 26 Mar 2020 18:46:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 40238 <at> debbugs.gnu.org (full text, mbox):
> I see. So, is there a customization, or some code, which gives, only
> for the ispell problem, an unconditional kill rather than a y-or-n-p?
What is the "ispell problem"? Does typing "x" or C-g not do what you
want? My knowledge of ispell.el is limited to the occasional use of M-$
quitting via C-g.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40238
; Package
emacs
.
(Fri, 27 Mar 2020 01:13:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 40238 <at> debbugs.gnu.org (full text, mbox):
The point is that “q” kills the entire (external) ispell process, while “x” or “C-g” do not. But I found the relevant code in ispell.el, and it was an easy matter to change it so that “q” does the job without asking y-or-n.
Konrad
> Am 26.03.2020 um 19:45 schrieb martin rudalics <rudalics <at> gmx.at>:
>
> > I see. So, is there a customization, or some code, which gives, only
> > for the ispell problem, an unconditional kill rather than a y-or-n-p?
>
> What is the "ispell problem"? Does typing "x" or C-g not do what you
> want? My knowledge of ispell.el is limited to the occasional use of M-$
> quitting via C-g.
>
> martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40238
; Package
emacs
.
(Fri, 27 Mar 2020 09:03:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 40238 <at> debbugs.gnu.org (full text, mbox):
> The point is that “q” kills the entire (external) ispell process,
> while “x” or “C-g” do not. But I found the relevant code in ispell.el,
> and it was an easy matter to change it so that “q” does the job
> without asking y-or-n.
But this part of the quit behavior is not related to whether you display
the choices on the same or another frame. Right?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40238
; Package
emacs
.
(Fri, 27 Mar 2020 11:23:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 40238 <at> debbugs.gnu.org (full text, mbox):
> Am 27.03.2020 um 10:02 schrieb martin rudalics <rudalics <at> gmx.at>:
>
> > The point is that “q” kills the entire (external) ispell process,
> > while “x” or “C-g” do not. But I found the relevant code in ispell.el,
> > and it was an easy matter to change it so that “q” does the job
> > without asking y-or-n.
>
> But this part of the quit behavior is not related to whether you display
> the choices on the same or another frame. Right?
This I dont’ know. I just changed the code, in ispell.el, lines 2320 and 2326, from
((= char ?q)
(if (y-or-n-p "Really kill Ispell process? ")
(progn
(ispell-kill-ispell t) ; terminate process.
(setq ispell-quit (or (not ispell-checking-message)
(point))
ispell-pdict-modified-p nil))
t)) ; continue if they don't quit.
into
((= char ?q)
;; (if (y-or-n-p "Really kill Ispell process? ")
(progn
(ispell-kill-ispell t) ; terminate process.
(setq ispell-quit (or (not ispell-checking-message)
(point))
ispell-pdict-modified-p nil))
;; t)
) ; continue if they don't quit.
Konrad
>
> martin
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40238
; Package
emacs
.
(Mon, 30 Mar 2020 02:36:34 GMT)
Full text and
rfc822 format available.
Message #35 received at 40238 <at> debbugs.gnu.org (full text, mbox):
> This I dont’ know. I just changed the code, in ispell.el, lines 2320 and 2326, from
>
> ((= char ?q)
> (if (y-or-n-p "Really kill Ispell process? ")
> (progn
> (ispell-kill-ispell t) ; terminate process.
> (setq ispell-quit (or (not ispell-checking-message)
> (point))
> ispell-pdict-modified-p nil))
> t)) ; continue if they don't quit.
>
> into
>
> ((= char ?q)
> ;; (if (y-or-n-p "Really kill Ispell process? ")
> (progn
> (ispell-kill-ispell t) ; terminate process.
> (setq ispell-quit (or (not ispell-checking-message)
> (point))
> ispell-pdict-modified-p nil))
> ;; t)
> ) ; continue if they don't quit.
We could reserve "Q" for killing Ispell without asking questions. But I
have no idea of the ispell mnemonics and already find "q" for killing
and "X" for suspending (which never suspends anything here IIUC) quite
confusing. Maybe an ispell expert can help us.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40238
; Package
emacs
.
(Thu, 10 Feb 2022 07:21:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 40238 <at> debbugs.gnu.org (full text, mbox):
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
Skimming this bug report, it's not quite clear what the problem is. Do
you have a recipe that reproduces the issue, starting from "emacs -Q"?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 10 Feb 2022 07:21:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40238
; Package
emacs
.
(Sat, 12 Mar 2022 22:44:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 40238 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Skimming this bug report, it's not quite clear what the problem is. Do
> you have a recipe that reproduces the issue, starting from "emacs -Q"?
More information was requested, but no response was given within a
month, 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
bug closed, send any further explanations to
40238 <at> debbugs.gnu.org and Konrad Podczeck <konrad.podczeck <at> univie.ac.at>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 12 Mar 2022 22:44:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 10 Apr 2022 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 354 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.