* bug#40238: Trying to customize the ispell choices buffer via display-buffer-alist has no effect
@ 2020-03-26 14:56 Konrad Podczeck
2020-03-26 15:29 ` martin rudalics
2022-02-10 7:20 ` Lars Ingebrigtsen
0 siblings, 2 replies; 13+ messages in thread
From: Konrad Podczeck @ 2020-03-26 14:56 UTC (permalink / raw)
To: 40238
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#40238: Trying to customize the ispell choices buffer via display-buffer-alist has no effect
2020-03-26 14:56 bug#40238: Trying to customize the ispell choices buffer via display-buffer-alist has no effect Konrad Podczeck
@ 2020-03-26 15:29 ` martin rudalics
2020-03-26 15:52 ` Konrad Podczeck
2022-02-10 7:20 ` Lars Ingebrigtsen
1 sibling, 1 reply; 13+ messages in thread
From: martin rudalics @ 2020-03-26 15:29 UTC (permalink / raw)
To: Konrad Podczeck, 40238
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#40238: Trying to customize the ispell choices buffer via display-buffer-alist has no effect
2020-03-26 15:29 ` martin rudalics
@ 2020-03-26 15:52 ` Konrad Podczeck
2020-03-26 16:23 ` Konrad Podczeck
2020-03-26 17:36 ` martin rudalics
0 siblings, 2 replies; 13+ messages in thread
From: Konrad Podczeck @ 2020-03-26 15:52 UTC (permalink / raw)
To: martin rudalics; +Cc: 40238
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@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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#40238: Trying to customize the ispell choices buffer via display-buffer-alist has no effect
2020-03-26 15:52 ` Konrad Podczeck
@ 2020-03-26 16:23 ` Konrad Podczeck
2020-03-26 17:36 ` martin rudalics
1 sibling, 0 replies; 13+ messages in thread
From: Konrad Podczeck @ 2020-03-26 16:23 UTC (permalink / raw)
To: martin rudalics; +Cc: 40238
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@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@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
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#40238: Trying to customize the ispell choices buffer via display-buffer-alist has no effect
2020-03-26 15:52 ` Konrad Podczeck
2020-03-26 16:23 ` Konrad Podczeck
@ 2020-03-26 17:36 ` martin rudalics
2020-03-26 18:05 ` Konrad Podczeck
1 sibling, 1 reply; 13+ messages in thread
From: martin rudalics @ 2020-03-26 17:36 UTC (permalink / raw)
To: Konrad Podczeck; +Cc: 40238
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#40238: Trying to customize the ispell choices buffer via display-buffer-alist has no effect
2020-03-26 17:36 ` martin rudalics
@ 2020-03-26 18:05 ` Konrad Podczeck
2020-03-26 18:45 ` martin rudalics
0 siblings, 1 reply; 13+ messages in thread
From: Konrad Podczeck @ 2020-03-26 18:05 UTC (permalink / raw)
To: martin rudalics; +Cc: 40238
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@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
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#40238: Trying to customize the ispell choices buffer via display-buffer-alist has no effect
2020-03-26 18:05 ` Konrad Podczeck
@ 2020-03-26 18:45 ` martin rudalics
2020-03-27 1:12 ` Konrad Podczeck
0 siblings, 1 reply; 13+ messages in thread
From: martin rudalics @ 2020-03-26 18:45 UTC (permalink / raw)
To: Konrad Podczeck; +Cc: 40238
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#40238: Trying to customize the ispell choices buffer via display-buffer-alist has no effect
2020-03-26 18:45 ` martin rudalics
@ 2020-03-27 1:12 ` Konrad Podczeck
2020-03-27 9:02 ` martin rudalics
0 siblings, 1 reply; 13+ messages in thread
From: Konrad Podczeck @ 2020-03-27 1:12 UTC (permalink / raw)
To: martin rudalics; +Cc: 40238
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@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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#40238: Trying to customize the ispell choices buffer via display-buffer-alist has no effect
2020-03-27 1:12 ` Konrad Podczeck
@ 2020-03-27 9:02 ` martin rudalics
2020-03-27 11:22 ` Konrad Podczeck
0 siblings, 1 reply; 13+ messages in thread
From: martin rudalics @ 2020-03-27 9:02 UTC (permalink / raw)
To: Konrad Podczeck; +Cc: 40238
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#40238: Trying to customize the ispell choices buffer via display-buffer-alist has no effect
2020-03-27 9:02 ` martin rudalics
@ 2020-03-27 11:22 ` Konrad Podczeck
2020-03-28 18:38 ` martin rudalics
0 siblings, 1 reply; 13+ messages in thread
From: Konrad Podczeck @ 2020-03-27 11:22 UTC (permalink / raw)
To: martin rudalics; +Cc: 40238
> Am 27.03.2020 um 10:02 schrieb martin rudalics <rudalics@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
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#40238: Trying to customize the ispell choices buffer via display-buffer-alist has no effect
2020-03-27 11:22 ` Konrad Podczeck
@ 2020-03-28 18:38 ` martin rudalics
0 siblings, 0 replies; 13+ messages in thread
From: martin rudalics @ 2020-03-28 18:38 UTC (permalink / raw)
To: Konrad Podczeck; +Cc: 40238
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#40238: Trying to customize the ispell choices buffer via display-buffer-alist has no effect
2020-03-26 14:56 bug#40238: Trying to customize the ispell choices buffer via display-buffer-alist has no effect Konrad Podczeck
2020-03-26 15:29 ` martin rudalics
@ 2022-02-10 7:20 ` Lars Ingebrigtsen
2022-03-12 22:42 ` Lars Ingebrigtsen
1 sibling, 1 reply; 13+ messages in thread
From: Lars Ingebrigtsen @ 2022-02-10 7:20 UTC (permalink / raw)
To: Konrad Podczeck; +Cc: 40238
(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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#40238: Trying to customize the ispell choices buffer via display-buffer-alist has no effect
2022-02-10 7:20 ` Lars Ingebrigtsen
@ 2022-03-12 22:42 ` Lars Ingebrigtsen
0 siblings, 0 replies; 13+ messages in thread
From: Lars Ingebrigtsen @ 2022-03-12 22:42 UTC (permalink / raw)
To: Konrad Podczeck; +Cc: 40238
Lars Ingebrigtsen <larsi@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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-03-12 22:42 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-26 14:56 bug#40238: Trying to customize the ispell choices buffer via display-buffer-alist has no effect Konrad Podczeck
2020-03-26 15:29 ` martin rudalics
2020-03-26 15:52 ` Konrad Podczeck
2020-03-26 16:23 ` Konrad Podczeck
2020-03-26 17:36 ` martin rudalics
2020-03-26 18:05 ` Konrad Podczeck
2020-03-26 18:45 ` martin rudalics
2020-03-27 1:12 ` Konrad Podczeck
2020-03-27 9:02 ` martin rudalics
2020-03-27 11:22 ` Konrad Podczeck
2020-03-28 18:38 ` martin rudalics
2022-02-10 7:20 ` Lars Ingebrigtsen
2022-03-12 22:42 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).