GNU bug report logs -
#38519
minibuffer-depth-indicate-mode with enable-recursive-minibuffers
Previous Next
Reported by: Juri Linkov <juri <at> linkov.net>
Date: Sun, 8 Dec 2019 02:55:01 UTC
Severity: normal
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38519 in the body.
You can then email your comments to 38519 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#38519
; Package
emacs
.
(Sun, 08 Dec 2019 02:55:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Juri Linkov <juri <at> linkov.net>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 08 Dec 2019 02:55:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
A recent discussion about enable-recursive-minibuffers reminded
that minibuffer-depth-indicate-mode should be enabled when
enable-recursive-minibuffers is non-nil. It's unusable
without the depth indication that is more error-prone.
It simultaneously enabling minibuffer-depth-indicate-mode
after enable-recursive-minibuffers becomes non-nil is not easy
to implement, then at least these two should mention each other
in the manual.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38519
; Package
emacs
.
(Sun, 08 Dec 2019 17:01:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 38519 <at> debbugs.gnu.org (full text, mbox):
> A recent discussion about enable-recursive-minibuffers reminded
> that minibuffer-depth-indicate-mode should be enabled when
> enable-recursive-minibuffers is non-nil. It's unusable
> without the depth indication that is more error-prone.
>
> It simultaneously enabling minibuffer-depth-indicate-mode
> after enable-recursive-minibuffers becomes non-nil is not easy
> to implement, then at least these two should mention each other
> in the manual.
It's a good question.
1. I agree that the docs should mention each other.
And the doc strings already do that:
`C-h v enable-recursive-minibuffers' says:
Also see `minibuffer-depth-indicate-mode',
which may be handy if this variable is non-nil.
`C-h f minibuffer-depth-indicate-mode' says:
This is only useful if
`enable-recursive-minibuffers' is non-nil.
But this hasn't yet been done in the manuals:
(elisp) `Recursive Mini' and (emacs) `Minibuffer
Edit' cover `enable-recursive-minibuffers', but
`minibuffer-depth-indicate-mode' is mentioned
nowhere, so far.
2. I agree that `minibuffer-depth-indicate-mode'
is useful when `enable-recursive-minibuffers'
is non-nil (generally and only).
3. I think I disagree that there should be
some kind of hard coupling between the two,
which would prevent users from getting
`enable-recursive-minibuffers' without
`minibuffer-depth-indicate-mode'.
It would be OK to automatically turn OFF
`minibuffer-depth-indicate-mode' when
`enable-recursive-minibuffers' is nil. But
that's not necessary (it has no effect), so
it's not useful.
I don't think we should turn `m-d-i-m' ON
systematically when `e-r-m' is non-nil.
That might be OK as a default behavior, but
we shouldn't impose it in a hard-coded way,
so that users have no recourse.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38519
; Package
emacs
.
(Sun, 08 Dec 2019 22:57:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 38519 <at> debbugs.gnu.org (full text, mbox):
> 1. I agree that the docs should mention each other.
> And the doc strings already do that:
>
> `C-h v enable-recursive-minibuffers' says:
> Also see `minibuffer-depth-indicate-mode',
> which may be handy if this variable is non-nil.
>
> `C-h f minibuffer-depth-indicate-mode' says:
> This is only useful if
> `enable-recursive-minibuffers' is non-nil.
>
> But this hasn't yet been done in the manuals:
> (elisp) `Recursive Mini' and (emacs) `Minibuffer
> Edit' cover `enable-recursive-minibuffers', but
> `minibuffer-depth-indicate-mode' is mentioned
> nowhere, so far.
So I added mention of `minibuffer-depth-indicate-mode' to
(emacs) `Minibuffer Edit'. Not sure about
(elisp) `Recursive Mini', probably not needed in (elisp).
> 2. I agree that `minibuffer-depth-indicate-mode'
> is useful when `enable-recursive-minibuffers'
> is non-nil (generally and only).
>
> 3. I think I disagree that there should be
> some kind of hard coupling between the two,
> which would prevent users from getting
> `enable-recursive-minibuffers' without
> `minibuffer-depth-indicate-mode'.
>
> It would be OK to automatically turn OFF
> `minibuffer-depth-indicate-mode' when
> `enable-recursive-minibuffers' is nil. But
> that's not necessary (it has no effect), so
> it's not useful.
Actually turning `m-d-i-m' OFF when `e-r-m' is nil
is not needed because `m-d-i-m' has no visual effect
when `e-r-m' is nil - there is nothing to show
as an indication of the recursive minibuffer
when recursive minibuffers are not enabled.
> I don't think we should turn `m-d-i-m' ON
> systematically when `e-r-m' is non-nil.
> That might be OK as a default behavior, but
> we shouldn't impose it in a hard-coded way,
> so that users have no recourse.
If turning `m-d-i-m' ON when `e-r-m' is non-nil
will be the default behavior, then users could
easily to turn `m-d-i-m' OFF.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38519
; Package
emacs
.
(Mon, 14 Jun 2021 14:35:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 38519 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>> But this hasn't yet been done in the manuals:
>> (elisp) `Recursive Mini' and (emacs) `Minibuffer
>> Edit' cover `enable-recursive-minibuffers', but
>> `minibuffer-depth-indicate-mode' is mentioned
>> nowhere, so far.
>
> So I added mention of `minibuffer-depth-indicate-mode' to
> (emacs) `Minibuffer Edit'. Not sure about
> (elisp) `Recursive Mini', probably not needed in (elisp).
If I understand correctly, this should be a sufficient fix here, so I'm
closing this bug report. If I misunderstood, please respond to the
debbugs address and we'll reopen.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
38519 <at> debbugs.gnu.org and Juri Linkov <juri <at> linkov.net>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 14 Jun 2021 14:35: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
.
(Tue, 13 Jul 2021 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 258 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.