GNU bug report logs -
#79070
[PATCH] Fix macOS dictation post NSTextInputClient migration in v30
Previous Next
To reply to this bug, email your comments to 79070 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Mon, 21 Jul 2025 12:27:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Alvaro Ramirez <alvaro <at> xenodium.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 21 Jul 2025 12:27:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi folks!
We lost macOS dictation in Emacs v30 (see
https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-03/msg00585.html)
with the NSTextInputClient migration.
Looks like we can get it back using the new subsystem by
implementing the missing bits for 'selectedRange' in 'nsterm.m'.
Not a NSTextInputClient expert here. Would love for other macOS
users to give the patch a try and confirm they get dictation
back. Similarly, edit as normal so we can rule out there are no
additional side effects.
Álvaro
In GNU Emacs 31.0.50 (build 14, aarch64-apple-darwin24.3.0, NS
appkit-2575.40 Version 15.3.2 (Build 24D81)) of 2025-07-21 built
on jiko.local
Repository revision: e9deec70dac822f2f312497c6d7a7bd6b4e648bb
Repository branch: fixes-macos-dictation-post-v30
Windowing system distributor 'Apple', version 10.3.2575
System Description: macOS 15.3.2
Configured using:
'configure --with-ns
--prefix=.../emacs/nextstep/Emacs.app/Contents/MacOS
--enable-locallisppath=.../emacs/nextstep/Emacs.app/Contents/MacOS'
[0001-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch (text/patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Mon, 21 Jul 2025 13:02:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 79070 <at> debbugs.gnu.org (full text, mbox):
> Cc: gerd.moellmann <at> gmail.com, shipmints <at> gmail.com, kickingvegas <at> gmail.com,
> stefankangas <at> gmail.com
> From: Alvaro Ramirez <alvaro <at> xenodium.com>
> Date: Mon, 21 Jul 2025 13:26:13 +0100
>
> We lost macOS dictation in Emacs v30 (see
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-03/msg00585.html)
> with the NSTextInputClient migration.
Thanks, but I'm not sure I understand why a new bug was in order.
Shouldn't this be discussed as part of bug#76765?
> Looks like we can get it back using the new subsystem by
> implementing the missing bits for 'selectedRange' in 'nsterm.m'.
>
> Not a NSTextInputClient expert here. Would love for other macOS
> users to give the patch a try and confirm they get dictation
> back. Similarly, edit as normal so we can rule out there are no
> additional side effects.
From the discussion of bug#76765, my impression was that the problem
was not caused by any change in the Emacs code. You seem to imply
differently?
And what is 'macOS dictation", anyway? what does it do for Emacs
users?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Mon, 21 Jul 2025 13:10:02 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Pulled and rebased patch to master (now in
0002-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch)
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> Hi folks!
>
> We lost macOS dictation in Emacs v30 (see
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-03/msg00585.html)
> with the NSTextInputClient migration.
>
> Looks like we can get it back using the new subsystem by
> implementing
> the missing bits for 'selectedRange' in 'nsterm.m'.
>
> Not a NSTextInputClient expert here. Would love for other macOS
> users
> to give the patch a try and confirm they get dictation
> back. Similarly, edit as normal so we can rule out there are no
> additional side effects.
>
> Álvaro
>
> In GNU Emacs 31.0.50 (build 14, aarch64-apple-darwin24.3.0, NS
> appkit-2575.40 Version 15.3.2 (Build 24D81)) of 2025-07-21 built
> on
> jiko.local
> Repository revision: e9deec70dac822f2f312497c6d7a7bd6b4e648bb
> Repository branch: fixes-macos-dictation-post-v30
> Windowing system distributor 'Apple', version 10.3.2575
> System Description: macOS 15.3.2
>
> Configured using:
> 'configure --with-ns
> --prefix=.../emacs/nextstep/Emacs.app/Contents/MacOS
> --enable-locallisppath=.../emacs/nextstep/Emacs.app/Contents/MacOS'
>
> [2. text/patch;
> 0001-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch]...
[0002-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Mon, 21 Jul 2025 13:21:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Cc: gerd.moellmann <at> gmail.com, shipmints <at> gmail.com,
>> kickingvegas <at> gmail.com,
>> stefankangas <at> gmail.com
>> From: Alvaro Ramirez <alvaro <at> xenodium.com>
>> Date: Mon, 21 Jul 2025 13:26:13 +0100
>>
>> We lost macOS dictation in Emacs v30 (see
>> https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-03/msg00585.html)
>> with the NSTextInputClient migration.
>
> Thanks, but I'm not sure I understand why a new bug was in
> order.
> Shouldn't this be discussed as part of bug#76765?
Apologies. Still getting the hang of things here. I used `M-x
submit-emacs-patch`, which created new bug.
>> Looks like we can get it back using the new subsystem by
>> implementing the missing bits for 'selectedRange' in
>> 'nsterm.m'.
>>
>> Not a NSTextInputClient expert here. Would love for other macOS
>> users to give the patch a try and confirm they get dictation
>> back. Similarly, edit as normal so we can rule out there are no
>> additional side effects.
>
> From the discussion of bug#76765, my impression was that the
> problem
> was not caused by any change in the Emacs code. You seem to
> imply
> differently?
I looked at changes for v30 and narrowed the regression down to
this change:
https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-07/msg01310.html
To fix macOS dictation, we have two options:
1. Roll back the patch from msg01310 (migrating to
NSTextInputClient) and re-introduce the warning.
2. Roll forward with a fix on top of the NSTextInputClient
migration.
My patch is for 2.
> And what is 'macOS dictation", anyway? what does it do for Emacs
> users?
Pressing a keyboard shortcut on macOS temporarily enables
dictation for any app, so you can speak and transcribe text into
an Emacs buffer. Attaching demo (speech is muted).
[dictation.mov (video/quicktime, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Mon, 21 Jul 2025 13:28:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 79070 <at> debbugs.gnu.org (full text, mbox):
> From: Alvaro Ramirez <alvaro <at> xenodium.com>
> Cc: 79070 <at> debbugs.gnu.org, gerd.moellmann <at> gmail.com, shipmints <at> gmail.com,
> kickingvegas <at> gmail.com, stefankangas <at> gmail.com
> Date: Mon, 21 Jul 2025 14:20:24 +0100
>
> > From the discussion of bug#76765, my impression was that the
> > problem
> > was not caused by any change in the Emacs code. You seem to
> > imply
> > differently?
>
> I looked at changes for v30 and narrowed the regression down to
> this change:
>
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-07/msg01310.html
>
> To fix macOS dictation, we have two options:
>
> 1. Roll back the patch from msg01310 (migrating to
> NSTextInputClient) and re-introduce the warning.
> 2. Roll forward with a fix on top of the NSTextInputClient
> migration.
>
> My patch is for 2.
Gerd, any comments?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Mon, 21 Jul 2025 13:28:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 79070 <at> debbugs.gnu.org (full text, mbox):
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Pressing a keyboard shortcut on macOS temporarily enables
> dictation for any app, so you can speak and transcribe text into
> an Emacs buffer. Attaching demo (speech is muted).
>
> [2. video/quicktime; dictation.mov]...
If attachment causes issues, demo can be seen as gif from a
browser at https://indieweb.social/@xenodium/114891280426640026
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Mon, 21 Jul 2025 14:03:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 79070 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Alvaro Ramirez <alvaro <at> xenodium.com>
>> Cc: 79070 <at> debbugs.gnu.org, gerd.moellmann <at> gmail.com, shipmints <at> gmail.com,
>> kickingvegas <at> gmail.com, stefankangas <at> gmail.com
>> Date: Mon, 21 Jul 2025 14:20:24 +0100
>>
>> > From the discussion of bug#76765, my impression was that the
>> > problem
>> > was not caused by any change in the Emacs code. You seem to
>> > imply
>> > differently?
>>
>> I looked at changes for v30 and narrowed the regression down to
>> this change:
>>
>> https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-07/msg01310.html
>>
>> To fix macOS dictation, we have two options:
>>
>> 1. Roll back the patch from msg01310 (migrating to
>> NSTextInputClient) and re-introduce the warning.
>> 2. Roll forward with a fix on top of the NSTextInputClient
>> migration.
>>
>> My patch is for 2.
>
> Gerd, any comments?
I think (1) is not a good option because Apple says in its
documentation, to cite from bug#69525
Important
NSTextInput protocol is slated for deprecation. Please use the
NSTextInputClient protocol instead.
I guess that's the reason for the warning, and we should switch to using
NSTextInputClient.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Mon, 21 Jul 2025 14:20:03 GMT)
Full text and
rfc822 format available.
Message #28 received at 79070 <at> debbugs.gnu.org (full text, mbox):
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> Pressing a keyboard shortcut on macOS temporarily enables
>> dictation for any app, so you can speak and transcribe text into
>> an Emacs buffer. Attaching demo (speech is muted).
>>
>> [2. video/quicktime; dictation.mov]...
>
> If attachment causes issues, demo can be seen as gif from a browser at
> https://indieweb.social/@xenodium/114891280426640026
I've tried with the 0002 patch, and it doesn't seem to work for me. I'm
running macOS 15.5 on arm64. Dictation works with other applications. In
emacs -Q GUI, pressing the dictation key produces no reaction; I mean no
small blue indicator with the microphone symbol appears.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Mon, 21 Jul 2025 15:17:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On 21 Jul 2025, at 15:19, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>
> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>
>> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>>
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>
>>> Pressing a keyboard shortcut on macOS temporarily enables
>>> dictation for any app, so you can speak and transcribe text into
>>> an Emacs buffer. Attaching demo (speech is muted).
>>>
>>> [2. video/quicktime; dictation.mov]...
>>
>> If attachment causes issues, demo can be seen as gif from a browser at
>> https://indieweb.social/@xenodium/114891280426640026
>
> I've tried with the 0002 patch, and it doesn't seem to work for me. I'm
> running macOS 15.5 on arm64. Dictation works with other applications. In
> emacs -Q GUI, pressing the dictation key produces no reaction; I mean no
> small blue indicator with the microphone symbol appears.
Ah, did you enable ns while configuring? Someone else just managed to apply and confirm https://social.vivaldi.net/@veer66/114891733359274099
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Mon, 21 Jul 2025 15:20:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On 21. Jul 2025, at 17:15, Alvaro Ramirez <alvaro <at> xenodium.com> wrote:
>
>> I've tried with the 0002 patch, and it doesn't seem to work for me. I'm
>> running macOS 15.5 on arm64. Dictation works with other applications. In
>> emacs -Q GUI, pressing the dictation key produces no reaction; I mean no
>> small blue indicator with the microphone symbol appears.
>
> Ah, did you enable ns while configuring? Someone else just managed to apply and confirm https://social.vivaldi.net/@veer66/114891733359274099
Yes, I did. That's why I wrote emacs -Q GUI above :-).
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Mon, 21 Jul 2025 15:35:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On 21 Jul 2025, at 16:19, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>
>
>
>> On 21. Jul 2025, at 17:15, Alvaro Ramirez <alvaro <at> xenodium.com> wrote:
>>
>>> I've tried with the 0002 patch, and it doesn't seem to work for me. I'm
>>> running macOS 15.5 on arm64. Dictation works with other applications. In
>>> emacs -Q GUI, pressing the dictation key produces no reaction; I mean no
>>> small blue indicator with the microphone symbol appears.
>>
>> Ah, did you enable ns while configuring? Someone else just managed to apply and confirm https://social.vivaldi.net/@veer66/114891733359274099
>
> Yes, I did. That's why I wrote emacs -Q GUI above :-).
Oops. Missed that. Hmmm… I’m wondering if this is a missing macOS permission issue?
It’s possible to explicitly trigger microphone permission request by running these from *eshell*:
1. ffmpeg -f avfoundation -list_devices true -i “” ;; to find microphone id
2. ffmpeg -f avfoundation -i ":0" -t 10 audiocapture.mp3 ;; using :id from 1.
Or maybe checking under System Settings > Privacy & Security > Microphone and verifying Emacs is listed there?
Just thinking out loud here to troubleshoot things. Anything else that comes to mind we can try?
I’ll try to clear all permissions here and see if I can reproduce the issue.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Mon, 21 Jul 2025 16:01:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 79070 <at> debbugs.gnu.org (full text, mbox):
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> It’s possible to explicitly trigger microphone permission request by running these from *eshell*:
>
> 1. ffmpeg -f avfoundation -list_devices true -i “” ;; to find microphone id
> 2. ffmpeg -f avfoundation -i ":0" -t 10 audiocapture.mp3 ;; using :id
> from 1.
That works here when executed from a terminal. The MBP microphone is :1
here, and I can record something. When I do the same from a running
Emacs, in Eshell (or Vterm, for that matter), I get
~ $ ffmpeg -f avfoundation -i ":1" -t 10 audiocapture.mp3
ffmpeg version 7.1.1 Copyright (c) 2000-2025 the FFmpeg developers
built with Apple clang version 17.0.0 (clang-1700.0.13.3)
configuration: --prefix=/opt/homebrew/Cellar/ffmpeg/7.1.1_3 --enable-shared --enable-pthreads --enable-version3 --cc=clang --host-cflags= --host-ldflags='-Wl,-ld_classic' --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libaribb24 --enable-libbluray --enable-libdav1d --enable-libharfbuzz --enable-libjxl --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librist --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libspeex --enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack --enable-videotoolbox --enable-audiotoolbox --enable-neon
libavutil 59. 39.100 / 59. 39.100
libavcodec 61. 19.101 / 61. 19.101
libavformat 61. 7.100 / 61. 7.100
libavdevice 61. 3.100 / 61. 3.100
libavfilter 10. 4.100 / 10. 4.100
libswscale 8. 3.100 / 8. 3.100
libswresample 5. 3.100 / 5. 3.100
libpostproc 58. 3.100 / 58. 3.100
2025-07-21 17:50:23.313 ffmpeg[19167:11461232] WARNING: Add NSCameraUseContinuityCameraDeviceType to your Info.plist to use AVCaptureDeviceTypeContinuityCamera.
2025-07-21 17:50:23.404 ffmpeg[19167:11461232] WARNING: AVCaptureDeviceTypeExternal is deprecated for Continuity Cameras. Please use AVCaptureDeviceTypeContinuityCamera and add NSCameraUseContinuityCameraDeviceType to your Info.plist.
abort trap: 6
(That's an unpatched Emacs from master, if that matters.)
>
> Or maybe checking under System Settings > Privacy & Security >
> Microphone and verifying Emacs is listed there?
Emacs isn't there, but there also seems to be no way to add an
application there.
>
> Just thinking out loud here to troubleshoot things. Anything else that comes to mind we can try?
>
> I’ll try to clear all permissions here and see if I can reproduce the issue.
Thanks, that's definitely far beyond my expertise :-).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Mon, 21 Jul 2025 16:12:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 79070 <at> debbugs.gnu.org (full text, mbox):
Gerd -
If you are running macOS on a laptop, I've found that suspend can intermittently put the speech recognition daemon ~corespeechd~ in a bad state. This impacts Siri, so you can test if you are in this state accordingly. Killing ~corespeechd~ will fix this as ~launchd~ will automatically restart it. This occurs enough that I've written an Elisp function to do just that.
#+BEGIN_SRC elisp :lexical no
(defun cc/dictation-reset ()
"Reset macOS dictation service corespeechd."
(interactive)
(process-lines "killall" "corespeechd"))
#+END_SRC
Perhaps this is why dictation is not working for you?
Regards -
Charles
—
Charles Y. Choi, Ph.D.
kickingvegas <at> gmail.com
> On Jul 21, 2025, at 9:00 AM, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>
> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>
>> It’s possible to explicitly trigger microphone permission request by running these from *eshell*:
>>
>> 1. ffmpeg -f avfoundation -list_devices true -i “” ;; to find microphone id
>> 2. ffmpeg -f avfoundation -i ":0" -t 10 audiocapture.mp3 ;; using :id
>> from 1.
>
> That works here when executed from a terminal. The MBP microphone is :1
> here, and I can record something. When I do the same from a running
> Emacs, in Eshell (or Vterm, for that matter), I get
>
> ~ $ ffmpeg -f avfoundation -i ":1" -t 10 audiocapture.mp3
> ffmpeg version 7.1.1 Copyright (c) 2000-2025 the FFmpeg developers
> built with Apple clang version 17.0.0 (clang-1700.0.13.3)
> configuration: --prefix=/opt/homebrew/Cellar/ffmpeg/7.1.1_3 --enable-shared --enable-pthreads --enable-version3 --cc=clang --host-cflags= --host-ldflags='-Wl,-ld_classic' --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libaribb24 --enable-libbluray --enable-libdav1d --enable-libharfbuzz --enable-libjxl --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librist --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libspeex --enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack --enable-videotoolbox --enable-audiotoolbox --enable-neon
> libavutil 59. 39.100 / 59. 39.100
> libavcodec 61. 19.101 / 61. 19.101
> libavformat 61. 7.100 / 61. 7.100
> libavdevice 61. 3.100 / 61. 3.100
> libavfilter 10. 4.100 / 10. 4.100
> libswscale 8. 3.100 / 8. 3.100
> libswresample 5. 3.100 / 5. 3.100
> libpostproc 58. 3.100 / 58. 3.100
> 2025-07-21 17:50:23.313 ffmpeg[19167:11461232] WARNING: Add NSCameraUseContinuityCameraDeviceType to your Info.plist to use AVCaptureDeviceTypeContinuityCamera.
> 2025-07-21 17:50:23.404 ffmpeg[19167:11461232] WARNING: AVCaptureDeviceTypeExternal is deprecated for Continuity Cameras. Please use AVCaptureDeviceTypeContinuityCamera and add NSCameraUseContinuityCameraDeviceType to your Info.plist.
> abort trap: 6
>
> (That's an unpatched Emacs from master, if that matters.)
>
>>
>> Or maybe checking under System Settings > Privacy & Security >
>> Microphone and verifying Emacs is listed there?
>
> Emacs isn't there, but there also seems to be no way to add an
> application there.
>
>>
>> Just thinking out loud here to troubleshoot things. Anything else that comes to mind we can try?
>>
>> I’ll try to clear all permissions here and see if I can reproduce the issue.
>
> Thanks, that's definitely far beyond my expertise :-).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Mon, 21 Jul 2025 16:27:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 79070 <at> debbugs.gnu.org (full text, mbox):
Charles Choi <kickingvegas <at> gmail.com> writes:
> Gerd -
>
> If you are running macOS on a laptop, I've found that suspend can
> intermittently put the speech recognition daemon ~corespeechd~ in a
> bad state. This impacts Siri, so you can test if you are in this state
> accordingly. Killing ~corespeechd~ will fix this as ~launchd~ will
> automatically restart it. This occurs enough that I've written an
> Elisp function to do just that.
>
> #+BEGIN_SRC elisp :lexical no
> (defun cc/dictation-reset ()
> "Reset macOS dictation service corespeechd."
> (interactive)
> (process-lines "killall" "corespeechd"))
> #+END_SRC
>
> Perhaps this is why dictation is not working for you?
Thanks for the tip, but it's not that, I'm afraid. It's only Emacs where
dictation isn't working, when I switch to, say, Textedit, it works.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Mon, 21 Jul 2025 17:03:04 GMT)
Full text and
rfc822 format available.
Message #49 received at 79070 <at> debbugs.gnu.org (full text, mbox):
> On 21 Jul 2025, at 17:00, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>
> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>
>> It’s possible to explicitly trigger microphone permission request by running these from *eshell*:
>>
>> 1. ffmpeg -f avfoundation -list_devices true -i “” ;; to find microphone id
>> 2. ffmpeg -f avfoundation -i ":0" -t 10 audiocapture.mp3 ;; using :id
>> from 1.
>
> That works here when executed from a terminal. The MBP microphone is :1
> here, and I can record something. When I do the same from a running
> Emacs, in Eshell (or Vterm, for that matter), I get
>
> ~ $ ffmpeg -f avfoundation -i ":1" -t 10 audiocapture.mp3
> ffmpeg version 7.1.1 Copyright (c) 2000-2025 the FFmpeg developers
> built with Apple clang version 17.0.0 (clang-1700.0.13.3)
> configuration: --prefix=/opt/homebrew/Cellar/ffmpeg/7.1.1_3 --enable-shared --enable-pthreads --enable-version3 --cc=clang --host-cflags= --host-ldflags='-Wl,-ld_classic' --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libaribb24 --enable-libbluray --enable-libdav1d --enable-libharfbuzz --enable-libjxl --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librist --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libspeex --enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack --enable-videotoolbox --enable-audiotoolbox --enable-neon
> libavutil 59. 39.100 / 59. 39.100
> libavcodec 61. 19.101 / 61. 19.101
> libavformat 61. 7.100 / 61. 7.100
> libavdevice 61. 3.100 / 61. 3.100
> libavfilter 10. 4.100 / 10. 4.100
> libswscale 8. 3.100 / 8. 3.100
> libswresample 5. 3.100 / 5. 3.100
> libpostproc 58. 3.100 / 58. 3.100
> 2025-07-21 17:50:23.313 ffmpeg[19167:11461232] WARNING: Add NSCameraUseContinuityCameraDeviceType to your Info.plist to use AVCaptureDeviceTypeContinuityCamera.
> 2025-07-21 17:50:23.404 ffmpeg[19167:11461232] WARNING: AVCaptureDeviceTypeExternal is deprecated for Continuity Cameras. Please use AVCaptureDeviceTypeContinuityCamera and add NSCameraUseContinuityCameraDeviceType to your Info.plist.
> abort trap: 6
>
> (That's an unpatched Emacs from master, if that matters.)
Handy to know. Thanks for this.
It’s looking like Microphone permission may have been rejected at some point.
Can you try resetting the permission with:
tccutil reset Microphone org.gnu.Emacs
And then attempt to record using ffmpeg via eshell. Must be from Emacs process (not a separate terminal app).
It should display the Microphone permission dialog
Once permission is accepted, ffmpeg recording should work again.
>>
>> Or maybe checking under System Settings > Privacy & Security >
>> Microphone and verifying Emacs is listed there?
>
> Emacs isn't there, but there also seems to be no way to add an
> application there.
>
>>
>> Just thinking out loud here to troubleshoot things. Anything else that comes to mind we can try?
>>
>> I’ll try to clear all permissions here and see if I can reproduce the issue.
>
> Thanks, that's definitely far beyond my expertise :-).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Mon, 21 Jul 2025 17:22:01 GMT)
Full text and
rfc822 format available.
Message #52 received at 79070 <at> debbugs.gnu.org (full text, mbox):
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> It’s looking like Microphone permission may have been rejected at some point.
>
> Can you try resetting the permission with:
>
> tccutil reset Microphone org.gnu.Emacs
That says
/Users/gerd % tccutil reset Microphone org.gnu.Emacs
Successfully reset Microphone approval status for org.gnu.Emacs
Successfully reset Microphone approval status for org.gnu.Emacs
Successfully reset Microphone approval status for org.gnu.Emacs
Successfully reset Microphone approval status for org.gnu.Emacs
Successfully reset Microphone approval status for org.gnu.Emacs
Successfully reset Microphone approval status for org.gnu.Emacs
Successfully reset Microphone approval status for org.gnu.Emacs
Successfully reset Microphone approval status for org.gnu.Emacs
Successfully reset Microphone approval status for org.gnu.Emacs
gerd <at> pro2 2025-07-21 19:14
> And then attempt to record using ffmpeg via eshell. Must be from Emacs
> process (not a separate terminal app).
~ $ ffmpeg -f avfoundation -i ":1" -t 10 audiocapture.mp3
ffmpeg version 7.1.1 Copyright (c) 2000-2025 the FFmpeg developers
built with Apple clang version 17.0.0 (clang-1700.0.13.3)
configuration: --prefix=/opt/homebrew/Cellar/ffmpeg/7.1.1_3 --enable-shared --enable-pthreads --enable-version3 --cc=clang --host-cflags= --host-ldflags='-Wl,-ld_classic' --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libaribb24 --enable-libbluray --enable-libdav1d --enable-libharfbuzz --enable-libjxl --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librist --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libspeex --enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack --enable-videotoolbox --enable-audiotoolbox --enable-neon
libavutil 59. 39.100 / 59. 39.100
libavcodec 61. 19.101 / 61. 19.101
libavformat 61. 7.100 / 61. 7.100
libavdevice 61. 3.100 / 61. 3.100
libavfilter 10. 4.100 / 10. 4.100
libswscale 8. 3.100 / 8. 3.100
libswresample 5. 3.100 / 5. 3.100
libpostproc 58. 3.100 / 58. 3.100
2025-07-21 19:15:17.829 ffmpeg[43320:11581784] WARNING: Add NSCameraUseContinuityCameraDeviceType to your Info.plist to use AVCaptureDeviceTypeContinuityCamera.
2025-07-21 19:15:17.977 ffmpeg[43320:11581784] WARNING: AVCaptureDeviceTypeExternal is deprecated for Continuity Cameras. Please use AVCaptureDeviceTypeContinuityCamera and add NSCameraUseContinuityCameraDeviceType to your Info.plist.
abort trap: 6
So that's identical to before.
> It should display the Microphone permission dialog
Maybe it doesn't come that far because of the SIGABRT?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Mon, 21 Jul 2025 17:24:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 79070 <at> debbugs.gnu.org (full text, mbox):
Hold on! After the tcutil..., the dictation indicator, the blue little
thingy, is displayed with your patch. So it works!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Mon, 21 Jul 2025 17:30:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 79070 <at> debbugs.gnu.org (full text, mbox):
> On 21 Jul 2025, at 18:25, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>
> Hold on! After the tcutil..., the dictation indicator, the blue little
> thingy, is displayed with your patch. So it works!
Success! Thanks for troubleshooting.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Mon, 21 Jul 2025 18:03:01 GMT)
Full text and
rfc822 format available.
Message #61 received at 79070 <at> debbugs.gnu.org (full text, mbox):
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>> On 21 Jul 2025, at 18:25, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>>
>> Hold on! After the tcutil..., the dictation indicator, the blue little
>> thingy, is displayed with your patch. So it works!
>
> Success! Thanks for troubleshooting.
Congrats! Maybe that's something for etc/PROBLEMS.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Mon, 21 Jul 2025 19:30:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>
>>> On 21 Jul 2025, at 18:25, Gerd Möllmann
>>> <gerd.moellmann <at> gmail.com> wrote:
>>>
>>> Hold on! After the tcutil..., the dictation indicator, the
>>> blue little
>>> thingy, is displayed with your patch. So it works!
>>
>> Success! Thanks for troubleshooting.
>
> Congrats! Maybe that's something for etc/PROBLEMS.
Good idea. Included in latest patch
(0003-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch)
[0003-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 03:13:02 GMT)
Full text and
rfc822 format available.
Message #67 received at 79070 <at> debbugs.gnu.org (full text, mbox):
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>>
>>>> On 21 Jul 2025, at 18:25, Gerd Möllmann <gerd.moellmann <at> gmail.com>
>>>> wrote:
>>>>
>>>> Hold on! After the tcutil..., the dictation indicator, the blue
>>>> little
>>>> thingy, is displayed with your patch. So it works!
>>>
>>> Success! Thanks for troubleshooting.
>>
>> Congrats! Maybe that's something for etc/PROBLEMS.
>
> Good idea. Included in latest patch
> (0003-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch)
Ok to install, Eli?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 07:55:01 GMT)
Full text and
rfc822 format available.
Message #70 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>>> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>>>
>>>>> On 21 Jul 2025, at 18:25, Gerd Möllmann
>>>>> <gerd.moellmann <at> gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hold on! After the tcutil..., the dictation indicator, the
>>>>> blue
>>>>> little
>>>>> thingy, is displayed with your patch. So it works!
>>>>
>>>> Success! Thanks for troubleshooting.
>>>
>>> Congrats! Maybe that's something for etc/PROBLEMS.
>>
>> Good idea. Included in latest patch
>> (0003-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch)
Looks like the patch may not apply cleanly for some. Here's a
rebased one
(0004-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch)
[0004-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 13:04:02 GMT)
Full text and
rfc822 format available.
Message #73 received at 79070 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 79070 <at> debbugs.gnu.org,
> shipmints <at> gmail.com, kickingvegas <at> gmail.com, Stefan Kangas
> <stefankangas <at> gmail.com>
> Date: Tue, 22 Jul 2025 05:12:00 +0200
>
> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>
> > Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> >
> >> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> >>
> >>>> On 21 Jul 2025, at 18:25, Gerd Möllmann <gerd.moellmann <at> gmail.com>
> >>>> wrote:
> >>>>
> >>>> Hold on! After the tcutil..., the dictation indicator, the blue
> >>>> little
> >>>> thingy, is displayed with your patch. So it works!
> >>>
> >>> Success! Thanks for troubleshooting.
> >>
> >> Congrats! Maybe that's something for etc/PROBLEMS.
> >
> > Good idea. Included in latest patch
> > (0003-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch)
>
> Ok to install, Eli?
Maybe. I'm not sure I understand what are the conclusions from your
experience, which eventually needed to use tcutil. Are we sure this
is just a fluke and not a more fundamental problem?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 13:11:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 79070 <at> debbugs.gnu.org (full text, mbox):
> From: Alvaro Ramirez <alvaro <at> xenodium.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 79070 <at> debbugs.gnu.org,
> shipmints <at> gmail.com, kickingvegas <at> gmail.com, Stefan Kangas
> <stefankangas <at> gmail.com>
> Date: Tue, 22 Jul 2025 08:54:09 +0100
>
> diff --git a/etc/PROBLEMS b/etc/PROBLEMS
> index 20fe9134da5..1323f02a1e9 100644
> --- a/etc/PROBLEMS
> +++ b/etc/PROBLEMS
> @@ -3566,6 +3566,14 @@ file; for example:
> "/usr/local/opt/libgccjit/lib/gcc/11"
> "/usr/local/opt/gcc/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0") ":"))
>
> +** macOS text dictation isn't recognising keyboard shortcut
> +
> +There's a chance that microphone permission may have been rejected in the past.
> +
> +Try clearing this permission with:
> +
> + tccutil reset Microphone org.gnu.Emacs
> +
This should explain better what are the indications of the problem.
> --- a/src/nsterm.m
> +++ b/src/nsterm.m
> @@ -7413,7 +7413,24 @@ - (NSRange)selectedRange
> {
> if (NS_KEYLOG)
> NSLog (@"selectedRange request");
> - return NSMakeRange (NSNotFound, 0);
> +
> + struct window *w = XWINDOW (FRAME_SELECTED_WINDOW (emacsframe));
> + struct buffer *buf = XBUFFER (w->contents);
> + ptrdiff_t point = BUF_PT (buf);
> +
> + if (NILP (BVAR (buf, mark_active)))
> + {
> + NSUInteger selection_location = point - BUF_BEGV (buf);
> + return NSMakeRange (selection_location, 0);
> + }
> +
> + ptrdiff_t mark = marker_position (BVAR (buf, mark));
> + ptrdiff_t region_start = min (point, mark);
> + ptrdiff_t region_end = max (point, mark);
> + NSUInteger selection_location = region_start - BUF_BEGV (buf);
> + NSUInteger selection_length = region_end - region_start;
> +
> + return NSMakeRange (selection_location, selection_length);
Can we have a comment there explaining why this code is needed?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 13:23:01 GMT)
Full text and
rfc822 format available.
Message #79 received at 79070 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Ok to install, Eli?
>
> Maybe. I'm not sure I understand what are the conclusions from your
> experience, which eventually needed to use tcutil. Are we sure this
> is just a fluke and not a more fundamental problem?
tccutil is a program that removes entries from a database containing
application-specific privacy settings. For example, if an app wants to
use the microphone or camera and such, it has to ask for permission, and
the result of that lands in that TCC database. 'tcc reset' clears such
entries.
It's very possible that I denied Emacs access to the microphone in the
past because I routinely do that :-). Also to the camera, of course, and
such things. That may have been years ago, because I migrate my settings
from machine to machine for a very long time. And if so, it would have
been for a different dictation system because that whole thing changed
some years ago, around macOS 14, not sure.
Anyway, the current dictation system apparently doesn't require special
privacy privileges, i.e. macOS doesn't ask for permission to use the
microphone for the current incarnation of dictation. But dictation also
doesn't work if one has "deny settings" in the TCC database. After
clearing these entries in with `tccutil reset`, Emacs now works like any
other app.
So it seems at least. That's about what I can say.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 13:26:03 GMT)
Full text and
rfc822 format available.
Message #82 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Jul 22, 2025 at 9:22 AM Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Ok to install, Eli?
> >
> > Maybe. I'm not sure I understand what are the conclusions from your
> > experience, which eventually needed to use tcutil. Are we sure this
> > is just a fluke and not a more fundamental problem?
>
> tccutil is a program that removes entries from a database containing
> application-specific privacy settings. For example, if an app wants to
> use the microphone or camera and such, it has to ask for permission, and
> the result of that lands in that TCC database. 'tcc reset' clears such
> entries.
>
> It's very possible that I denied Emacs access to the microphone in the
> past because I routinely do that :-). Also to the camera, of course, and
> such things. That may have been years ago, because I migrate my settings
> from machine to machine for a very long time. And if so, it would have
> been for a different dictation system because that whole thing changed
> some years ago, around macOS 14, not sure.
>
> Anyway, the current dictation system apparently doesn't require special
> privacy privileges, i.e. macOS doesn't ask for permission to use the
> microphone for the current incarnation of dictation. But dictation also
> doesn't work if one has "deny settings" in the TCC database. After
> clearing these entries in with `tccutil reset`, Emacs now works like any
> other app.
>
> So it seems at least. That's about what I can say.
>
So far, the patch does not work on macOS 12.7.6 (the only version I use
across my Intel Macs). So something else is missing?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 13:42:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 79070 <at> debbugs.gnu.org (full text, mbox):
Stéphane Marks <shipmints <at> gmail.com> writes:
> On Tue, Jul 22, 2025 at 9:22 AM Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Ok to install, Eli?
> >
> > Maybe. I'm not sure I understand what are the conclusions from your
> > experience, which eventually needed to use tcutil. Are we sure this
> > is just a fluke and not a more fundamental problem?
>
> tccutil is a program that removes entries from a database containing
> application-specific privacy settings. For example, if an app wants to
> use the microphone or camera and such, it has to ask for permission, and
> the result of that lands in that TCC database. 'tcc reset' clears such
> entries.
>
> It's very possible that I denied Emacs access to the microphone in the
> past because I routinely do that :-). Also to the camera, of course, and
> such things. That may have been years ago, because I migrate my settings
> from machine to machine for a very long time. And if so, it would have
> been for a different dictation system because that whole thing changed
> some years ago, around macOS 14, not sure.
>
> Anyway, the current dictation system apparently doesn't require special
> privacy privileges, i.e. macOS doesn't ask for permission to use the
> microphone for the current incarnation of dictation. But dictation also
> doesn't work if one has "deny settings" in the TCC database. After
> clearing these entries in with `tccutil reset`, Emacs now works like any
> other app.
>
> So it seems at least. That's about what I can say.
>
> So far, the patch does not work on macOS 12.7.6 (the only version I use across my Intel Macs). So something else is missing?
Time for OCLP, given that Monterey not longer receives security updates?
https://dortania.github.io/OpenCore-Legacy-Patcher/
(I've used OCLP very successfully on a MBP from 2013 until it finally
died a year ago :-(.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 13:56:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Jul 22, 2025 at 9:41 AM Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:
> Stéphane Marks <shipmints <at> gmail.com> writes:
>
> > On Tue, Jul 22, 2025 at 9:22 AM Gerd Möllmann <gerd.moellmann <at> gmail.com>
> wrote:
> >
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> > >> Ok to install, Eli?
> > >
> > > Maybe. I'm not sure I understand what are the conclusions from your
> > > experience, which eventually needed to use tcutil. Are we sure this
> > > is just a fluke and not a more fundamental problem?
> >
> > tccutil is a program that removes entries from a database containing
> > application-specific privacy settings. For example, if an app wants to
> > use the microphone or camera and such, it has to ask for permission, and
> > the result of that lands in that TCC database. 'tcc reset' clears such
> > entries.
> >
> > It's very possible that I denied Emacs access to the microphone in the
> > past because I routinely do that :-). Also to the camera, of course, and
> > such things. That may have been years ago, because I migrate my settings
> > from machine to machine for a very long time. And if so, it would have
> > been for a different dictation system because that whole thing changed
> > some years ago, around macOS 14, not sure.
> >
> > Anyway, the current dictation system apparently doesn't require special
> > privacy privileges, i.e. macOS doesn't ask for permission to use the
> > microphone for the current incarnation of dictation. But dictation also
> > doesn't work if one has "deny settings" in the TCC database. After
> > clearing these entries in with `tccutil reset`, Emacs now works like any
> > other app.
> >
> > So it seems at least. That's about what I can say.
> >
> > So far, the patch does not work on macOS 12.7.6 (the only version I use
> across my Intel Macs). So something else is missing?
>
> Time for OCLP, given that Monterey not longer receives security updates?
>
> https://dortania.github.io/OpenCore-Legacy-Patcher/
>
> (I've used OCLP very successfully on a MBP from 2013 until it finally
> died a year ago :-(.)
>
Without knowing precisely what the issue is, it's hard to say that's a
great suggestion? Previous versions of Emacs work fine on 12.7.6, so it's
clearly not an O/S issue, but one with the API change to NSTextInputClient
that's missing something else? All other apps I've tried seem to support
dictation just fine.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 14:00:03 GMT)
Full text and
rfc822 format available.
Message #91 received at 79070 <at> debbugs.gnu.org (full text, mbox):
Stéphane Marks <shipmints <at> gmail.com> writes:
> Time for OCLP, given that Monterey not longer receives security updates?
>
> https://dortania.github.io/OpenCore-Legacy-Patcher/
>
> (I've used OCLP very successfully on a MBP from 2013 until it finally
> died a year ago :-(.)
>
> Without knowing precisely what the issue is, it's hard to say that's a great suggestion? Previous versions of Emacs work fine on
> 12.7.6, so it's clearly not an O/S issue, but one with the API change to NSTextInputClient that's missing something else? All
> other apps I've tried seem to support dictation just fine.
I meant that as an advertisement for OCLP. And against running an OS
that doesn't get security updates.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 14:01:02 GMT)
Full text and
rfc822 format available.
Message #94 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On 22 Jul 2025, at 14:41, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>
> Stéphane Marks <shipmints <at> gmail.com> writes:
>
>> On Tue, Jul 22, 2025 at 9:22 AM Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> Ok to install, Eli?
>>>
>>> Maybe. I'm not sure I understand what are the conclusions from your
>>> experience, which eventually needed to use tcutil. Are we sure this
>>> is just a fluke and not a more fundamental problem?
>>
>> tccutil is a program that removes entries from a database containing
>> application-specific privacy settings. For example, if an app wants to
>> use the microphone or camera and such, it has to ask for permission, and
>> the result of that lands in that TCC database. 'tcc reset' clears such
>> entries.
>>
>> It's very possible that I denied Emacs access to the microphone in the
>> past because I routinely do that :-). Also to the camera, of course, and
>> such things. That may have been years ago, because I migrate my settings
>> from machine to machine for a very long time. And if so, it would have
>> been for a different dictation system because that whole thing changed
>> some years ago, around macOS 14, not sure.
>>
>> Anyway, the current dictation system apparently doesn't require special
>> privacy privileges, i.e. macOS doesn't ask for permission to use the
>> microphone for the current incarnation of dictation. But dictation also
>> doesn't work if one has "deny settings" in the TCC database. After
>> clearing these entries in with `tccutil reset`, Emacs now works like any
>> other app.
>>
>> So it seems at least. That's about what I can say.
>>
>> So far, the patch does not work on macOS 12.7.6 (the only version I use across my Intel Macs). So something else is missing?
>
> Time for OCLP, given that Monterey not longer receives security updates?
+1 I’d like to propose we treat macOS 12.7.6 / Intel as a separate issue if that’s ok?
We have a handful of folks who validated the fix is working in this thread https://indieweb.social/@xenodium/114891280426640026
I’ve validated on macOS 15.3 / ARM myself. The thread also mentions macOS 15.5 validated.
> https://dortania.github.io/OpenCore-Legacy-Patcher/
>
> (I've used OCLP very successfully on a MBP from 2013 until it finally
> died a year ago :-(.)
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 14:03:02 GMT)
Full text and
rfc822 format available.
Message #97 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Jul 22, 2025 at 10:00 AM Alvaro Ramirez <alvaro <at> xenodium.com> wrote:
>
>
> On 22 Jul 2025, at 14:41, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>
> Stéphane Marks <shipmints <at> gmail.com> writes:
>
> On Tue, Jul 22, 2025 at 9:22 AM Gerd Möllmann <gerd.moellmann <at> gmail.com>
> wrote:
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Ok to install, Eli?
>
>
> Maybe. I'm not sure I understand what are the conclusions from your
> experience, which eventually needed to use tcutil. Are we sure this
> is just a fluke and not a more fundamental problem?
>
>
> tccutil is a program that removes entries from a database containing
> application-specific privacy settings. For example, if an app wants to
> use the microphone or camera and such, it has to ask for permission, and
> the result of that lands in that TCC database. 'tcc reset' clears such
> entries.
>
> It's very possible that I denied Emacs access to the microphone in the
> past because I routinely do that :-). Also to the camera, of course, and
> such things. That may have been years ago, because I migrate my settings
> from machine to machine for a very long time. And if so, it would have
> been for a different dictation system because that whole thing changed
> some years ago, around macOS 14, not sure.
>
> Anyway, the current dictation system apparently doesn't require special
> privacy privileges, i.e. macOS doesn't ask for permission to use the
> microphone for the current incarnation of dictation. But dictation also
> doesn't work if one has "deny settings" in the TCC database. After
> clearing these entries in with `tccutil reset`, Emacs now works like any
> other app.
>
> So it seems at least. That's about what I can say.
>
> So far, the patch does not work on macOS 12.7.6 (the only version I use
> across my Intel Macs). So something else is missing?
>
>
> Time for OCLP, given that Monterey not longer receives security updates?
>
>
> +1 I’d like to propose we treat macOS 12.7.6 / Intel as a separate issue
> if that’s ok?
>
> We have a handful of folks who validated the fix is working in this thread
> https://indieweb.social/@xenodium/114891280426640026
>
> I’ve validated on macOS 15.3 / ARM myself. The thread also mentions macOS
> 15.5 validated.
>
I'd be in favor of that ONLY if macOS 12.7.6 is specifically considered
unsupported. Let's spend a little more time figuring out what's missing.
There are reports that emacs-mac works fine with dictation on 12.7.6 so
take a look at that code and see what they're doing differently?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 14:07:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 79070 <at> debbugs.gnu.org (full text, mbox):
> On 22 Jul 2025, at 14:02, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> Maybe. I'm not sure I understand what are the conclusions from your
> experience, which eventually needed to use tcutil. Are we sure this
> is just a fluke and not a more fundamental problem?
I can deterministically apply/remove the patch and validate the fix is present/absent at runtime, without touching macOS permissions.
tcutil seems to be needed if one ever explicitly rejected Emacs permission to access the microphone.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 14:17:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On 22 Jul 2025, at 15:02, Stéphane Marks <shipmints <at> gmail.com> wrote:
>
> I'd be in favor of that ONLY if macOS 12.7.6 is specifically considered unsupported. Let's spend a little more time figuring out what's missing.
Why not do both? Apply a fix that works on officially supported hardware (by macOS) now and continue looking for a fix that can be backported to older macOS 12 / Intel? They seem to be separate issues anyway.
> There are reports that emacs-mac works fine with dictation on 12.7.6 so take a look at that code and see what they're doing differently?
Happy to take a look. Can you share details please?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 14:21:04 GMT)
Full text and
rfc822 format available.
Message #106 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Jul 22, 2025 at 10:15 AM Alvaro Ramirez <alvaro <at> xenodium.com> wrote:
>
> On 22 Jul 2025, at 15:02, Stéphane Marks <shipmints <at> gmail.com> wrote:
>
> I'd be in favor of that ONLY if macOS 12.7.6 is specifically considered
> unsupported. Let's spend a little more time figuring out what's missing.
>
>
> Why not do both? Apply a fix that works on officially supported hardware
> (by macOS) now and continue looking for a fix that can be backported to
> older macOS 12 / Intel? They seem to be separate issues anyway.
>
> There are reports that emacs-mac works fine with dictation on 12.7.6 so
> take a look at that code and see what they're doing differently?
>
>
> Happy to take a look. Can you share details please?
>
A version of the emacs-mac code base that's been regularly merged with more
recent Emacs changes lives here https://github.com/jdtsmith/emacs-mac
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 14:22:03 GMT)
Full text and
rfc822 format available.
Message #109 received at 79070 <at> debbugs.gnu.org (full text, mbox):
> From: Alvaro Ramirez <alvaro <at> xenodium.com>
> Date: Tue, 22 Jul 2025 15:00:18 +0100
> Cc: Stéphane Marks <shipmints <at> gmail.com>,
> Eli Zaretskii <eliz <at> gnu.org>,
> 79070 <at> debbugs.gnu.org,
> kickingvegas <at> gmail.com,
> stefankangas <at> gmail.com
>
> +1 I’d like to propose we treat macOS 12.7.6 / Intel as a separate issue if that’s ok?
If that is what we want to do, then the PROBLEMS entry should be
updated to say that older versions of macOS are not supported by this
feature in Emacs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 14:24:01 GMT)
Full text and
rfc822 format available.
Message #112 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On 22 Jul 2025, at 14:54, Stéphane Marks <shipmints <at> gmail.com> wrote:
>
> Without knowing precisely what the issue is, it's hard to say that's a great suggestion? Previous versions of Emacs work fine on 12.7.6, so it's clearly not an O/S issue, but one with the API change to NSTextInputClient that's missing something else? All other apps I've tried seem to support dictation just fine.
We narrowed down the regression. We have two options to fix (a roll back and roll forward): https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79070#14
The rollback isn’t super desirable as it relies on deprecated APIs which will be removed.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 14:24:03 GMT)
Full text and
rfc822 format available.
Message #115 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Jul 22, 2025 at 10:21 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Alvaro Ramirez <alvaro <at> xenodium.com>
> > Date: Tue, 22 Jul 2025 15:00:18 +0100
> > Cc: Stéphane Marks <shipmints <at> gmail.com>,
> > Eli Zaretskii <eliz <at> gnu.org>,
> > 79070 <at> debbugs.gnu.org,
> > kickingvegas <at> gmail.com,
> > stefankangas <at> gmail.com
> >
> > +1 I’d like to propose we treat macOS 12.7.6 / Intel as a separate issue
> if that’s ok?
>
> If that is what we want to do, then the PROBLEMS entry should be
> updated to say that older versions of macOS are not supported by this
> feature in Emacs.
>
But, older than what specific macOS version will be the question to answer,
and why it's broken/incomplete is another question. I think we spend a
little more time on this before declaring this patch a success.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 14:57:02 GMT)
Full text and
rfc822 format available.
Message #118 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On 22 Jul 2025, at 15:23, Stéphane Marks <shipmints <at> gmail.com> wrote:
>
> On Tue, Jul 22, 2025 at 10:21 AM Eli Zaretskii <eliz <at> gnu.org <mailto:eliz <at> gnu.org>> wrote:
>> > From: Alvaro Ramirez <alvaro <at> xenodium.com <mailto:alvaro <at> xenodium.com>>
>> > Date: Tue, 22 Jul 2025 15:00:18 +0100
>> > Cc: Stéphane Marks <shipmints <at> gmail.com <mailto:shipmints <at> gmail.com>>,
>> > Eli Zaretskii <eliz <at> gnu.org <mailto:eliz <at> gnu.org>>,
>> > 79070 <at> debbugs.gnu.org <mailto:79070 <at> debbugs.gnu.org>,
>> > kickingvegas <at> gmail.com <mailto:kickingvegas <at> gmail.com>,
>> > stefankangas <at> gmail.com <mailto:stefankangas <at> gmail.com>
>> >
>> > +1 I’d like to propose we treat macOS 12.7.6 / Intel as a separate issue if that’s ok?
>>
>> If that is what we want to do, then the PROBLEMS entry should be
>> updated to say that older versions of macOS are not supported by this
>> feature in Emacs.
>
> But, older than what specific macOS version will be the question to answer,
We can only go with the information we have available as of today, given the hardware and macOS versions we have access to. With new data points, we would update this info.
I’m happy to update PROBLEMS with the data we know today (maybe something like “There are reports of this feature being unavailable for macOS 12 users").
> and why it's broken/incomplete is another question.
I’m running out of ideas to fix on hardware (and OS version) I don’t have access to. One thing that comes to mind is patching with the rollback, since I was able to get dictation working that way also. This may not be a future-proof solution to submit upstream, but helps unblock your use-case using local builds.
> I think we spend a little more time on this before declaring this patch a success.
We have deterministic evidence the patch is working on macOS 15, the latest stable release.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 14:57:02 GMT)
Full text and
rfc822 format available.
Message #121 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On 22 Jul 2025, at 15:23, Stéphane Marks <shipmints <at> gmail.com> wrote:
>
> On Tue, Jul 22, 2025 at 10:21 AM Eli Zaretskii <eliz <at> gnu.org <mailto:eliz <at> gnu.org>> wrote:
>> > From: Alvaro Ramirez <alvaro <at> xenodium.com <mailto:alvaro <at> xenodium.com>>
>> > Date: Tue, 22 Jul 2025 15:00:18 +0100
>> > Cc: Stéphane Marks <shipmints <at> gmail.com <mailto:shipmints <at> gmail.com>>,
>> > Eli Zaretskii <eliz <at> gnu.org <mailto:eliz <at> gnu.org>>,
>> > 79070 <at> debbugs.gnu.org <mailto:79070 <at> debbugs.gnu.org>,
>> > kickingvegas <at> gmail.com <mailto:kickingvegas <at> gmail.com>,
>> > stefankangas <at> gmail.com <mailto:stefankangas <at> gmail.com>
>> >
>> > +1 I’d like to propose we treat macOS 12.7.6 / Intel as a separate issue if that’s ok?
>>
>> If that is what we want to do, then the PROBLEMS entry should be
>> updated to say that older versions of macOS are not supported by this
>> feature in Emacs.
>
> But, older than what specific macOS version will be the question to answer,
We can only go with the information we have available as of today, given the hardware and macOS versions we have access to. With new data points, we would update this info.
I’m happy to update PROBLEMS with the data we know today (maybe something like “There are reports of this feature being unavailable for macOS 12 users").
> and why it's broken/incomplete is another question.
I’m running out of ideas to fix on hardware (and OS version) I don’t have access to. One thing that comes to mind is patching with the rollback, since I was able to get dictation working that way also. This may not be a future-proof solution to submit upstream, but helps unblock your use-case using local builds.
> I think we spend a little more time on this before declaring this patch a success.
We can reliable verify the patch is working on macOS 15, the latest stable release.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 16:16:01 GMT)
Full text and
rfc822 format available.
Message #124 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> On 22 Jul 2025, at 15:23, Stéphane Marks <shipmints <at> gmail.com>
> wrote:
>
> On Tue, Jul 22, 2025 at 10:21 AM Eli Zaretskii <eliz <at> gnu.org>
> wrote:
>
> > From: Alvaro Ramirez <alvaro <at> xenodium.com>
> > Date: Tue, 22 Jul 2025 15:00:18 +0100
> > Cc: Stéphane Marks <shipmints <at> gmail.com>,
> > Eli Zaretskii <eliz <at> gnu.org>,
> > 79070 <at> debbugs.gnu.org,
> > kickingvegas <at> gmail.com,
> > stefankangas <at> gmail.com
> >
> > +1 I’d like to propose we treat macOS 12.7.6 / Intel as a
> > separate issue if that’s ok?
>
> If that is what we want to do, then the PROBLEMS entry should
> be
> updated to say that older versions of macOS are not supported
> by this
> feature in Emacs.
>
> But, older than what specific macOS version will be the
> question to answer,
>
> We can only go with the information we have available as of
> today, given the hardware and macOS versions we have
> access to. With new data points, we would update this info.
>
> I’m happy to update PROBLEMS with the data we know today (maybe
> something like “There are reports of this feature
> being unavailable for macOS 12 users").
Updated PROBLEMS (attaching
0005-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch)
> and why it's broken/incomplete is another question.
>
> I’m running out of ideas to fix on hardware (and OS version) I
> don’t have access to. One thing that comes to mind is
> patching with the rollback, since I was able to get dictation
> working that way also. This may not be a future-proof solution
> to submit upstream, but helps unblock your use-case using local
> builds.
A tiny bit of additional info with respect to roll back (yields
deprecation warning) vs roll forward fix... macOS seems to use a
different dictation mechanism after NSTextInputClient was
introduced (Emacs v30). Attaching screenshots showing different UI
dictation triggered by either patch.
[rollback.jpg (image/jpeg, attachment)]
[rollforward.jpg (image/jpeg, attachment)]
[0005-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 17:33:02 GMT)
Full text and
rfc822 format available.
Message #127 received at 79070 <at> debbugs.gnu.org (full text, mbox):
Alvaro Ramirez <alvaro <at> xenodium.com> writes:
> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>> I’m running out of ideas to fix on hardware (and OS version) I
>> don’t
>> have access to. One thing that comes to mind is
>> patching with the rollback, since I was able to get dictation
>> working that way also. This may not be a future-proof solution
>> to submit upstream, but helps unblock your use-case using local
>> builds.
Reached out to a friend with an Intel Macbook. The closest
hardware setup I could find is his:
M-x emacs-version RET
GNU Emacs 31.0.50 (build 1, x86_64-apple-darwin24.5.0, NS
appkit-2575.60 Version 15.5 (Build 24F74)) of 2025-07-22
Macbook Pro 16-inch 2019 - Running macOS 15.5.
He was able to install the patch and verify dictation works for
this configuration.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Tue, 22 Jul 2025 17:38:01 GMT)
Full text and
rfc822 format available.
Message #130 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Jul 22, 2025 at 1:32 PM Alvaro Ramirez <alvaro <at> xenodium.com> wrote:
> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>
> > Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>
> >> I’m running out of ideas to fix on hardware (and OS version) I
> >> don’t
> >> have access to. One thing that comes to mind is
> >> patching with the rollback, since I was able to get dictation
> >> working that way also. This may not be a future-proof solution
> >> to submit upstream, but helps unblock your use-case using local
> >> builds.
>
> Reached out to a friend with an Intel Macbook. The closest
> hardware setup I could find is his:
>
> M-x emacs-version RET
>
> GNU Emacs 31.0.50 (build 1, x86_64-apple-darwin24.5.0, NS
> appkit-2575.60 Version 15.5 (Build 24F74)) of 2025-07-22
>
> Macbook Pro 16-inch 2019 - Running macOS 15.5.
>
> He was able to install the patch and verify dictation works for
> this configuration.
>
It surely isn't chip related but some API work that's needed. I tried to
do some research on this and read through several code bases (e.g.,
chromium) that work correctly on macOS 12, but came up short on specifics
for nsterm.
At least it seems the patch does no harm so I don't object at all to its
adoption, just the idea that it should be considered "complete" without
more work as users running < 15.5 may complain when it doesn't.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Wed, 23 Jul 2025 10:47:02 GMT)
Full text and
rfc822 format available.
Message #133 received at 79070 <at> debbugs.gnu.org (full text, mbox):
> From: Alvaro Ramirez <alvaro <at> xenodium.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, gerd.moellmann <at> gmail.com,
> 79070 <at> debbugs.gnu.org, kickingvegas <at> gmail.com, stefankangas <at> gmail.com
> Date: Tue, 22 Jul 2025 17:15:27 +0100
>
>
> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>
> > On 22 Jul 2025, at 15:23, Stéphane Marks <shipmints <at> gmail.com>
> > wrote:
> >
> > On Tue, Jul 22, 2025 at 10:21 AM Eli Zaretskii <eliz <at> gnu.org>
> > wrote:
> >
> > > From: Alvaro Ramirez <alvaro <at> xenodium.com>
> > > Date: Tue, 22 Jul 2025 15:00:18 +0100
> > > Cc: Stéphane Marks <shipmints <at> gmail.com>,
> > > Eli Zaretskii <eliz <at> gnu.org>,
> > > 79070 <at> debbugs.gnu.org,
> > > kickingvegas <at> gmail.com,
> > > stefankangas <at> gmail.com
> > >
> > > +1 I’d like to propose we treat macOS 12.7.6 / Intel as a
> > > separate issue if that’s ok?
> >
> > If that is what we want to do, then the PROBLEMS entry should
> > be
> > updated to say that older versions of macOS are not supported
> > by this
> > feature in Emacs.
> >
> > But, older than what specific macOS version will be the
> > question to answer,
> >
> > We can only go with the information we have available as of
> > today, given the hardware and macOS versions we have
> > access to. With new data points, we would update this info.
> >
> > I’m happy to update PROBLEMS with the data we know today (maybe
> > something like “There are reports of this feature
> > being unavailable for macOS 12 users").
>
> Updated PROBLEMS (attaching
> 0005-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch)
Thanks, but one of my previous comments, viz.:
This should explain better what are the indications of the problem.
is still not addressed.
> A tiny bit of additional info with respect to roll back (yields
> deprecation warning) vs roll forward fix... macOS seems to use a
> different dictation mechanism after NSTextInputClient was
> introduced (Emacs v30). Attaching screenshots showing different UI
> dictation triggered by either patch.
Could you please spell out what that means for Emacs users?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Wed, 23 Jul 2025 13:03:01 GMT)
Full text and
rfc822 format available.
Message #136 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> Thanks, but one of my previous comments, viz.:
>
> This should explain better what are the indications of the
> problem.
>
> is still not addressed.
Updated PROBLEMS in
0006-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch.
Hope that's better now.
>> A tiny bit of additional info with respect to roll back (yields
>> deprecation warning) vs roll forward fix... macOS seems to use
>> a
>> different dictation mechanism after NSTextInputClient was
>> introduced (Emacs v30). Attaching screenshots showing different
>> UI
>> dictation triggered by either patch.
>
> Could you please spell out what that means for Emacs users?
Not much really. This is more of a macOS implementation
detail. Emacs users will get their dictation feature back,
regressed in Emacs 30. Fixing the regression leads to using a
newer API, which triggers a slightly different-looking UI. The way
the feature is triggered (global keyboard shortcut) and
transcription behaviour remain the same, so no significant change
in expectation as to how the feature works.
In a little more detail...
Introducing NSTextInputClient in Emacs v30 broke/removed dictation
as a side effect. This introduction seems to signal to macOS to
rely more on NSTextInputClient (new class) and less on NSTextInput
(deprecated class) to power separate internal dictation
subsystems. The screenshots I shared show the slightly
different-looking UI for each internal subsystem. One uses a large
microphone icon vs the tiny blue microphone icon (newer). Enabling
dictation (global keyboard shortcut) and transcription behaviour
remain the same.
[0006-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Wed, 23 Jul 2025 13:12:01 GMT)
Full text and
rfc822 format available.
Message #139 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Jul 23, 2025 at 9:02 AM Alvaro Ramirez <alvaro <at> xenodium.com> wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Thanks, but one of my previous comments, viz.:
> >
> > This should explain better what are the indications of the
> > problem.
> >
> > is still not addressed.
>
> Updated PROBLEMS in
> 0006-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch.
> Hope that's better now.
>
> >> A tiny bit of additional info with respect to roll back (yields
> >> deprecation warning) vs roll forward fix... macOS seems to use
> >> a
> >> different dictation mechanism after NSTextInputClient was
> >> introduced (Emacs v30). Attaching screenshots showing different
> >> UI
> >> dictation triggered by either patch.
> >
> > Could you please spell out what that means for Emacs users?
>
> Not much really. This is more of a macOS implementation
> detail. Emacs users will get their dictation feature back,
> regressed in Emacs 30. Fixing the regression leads to using a
> newer API, which triggers a slightly different-looking UI.
I think that's a feature of macOS which changed the UI, not a function of
the patch?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Wed, 23 Jul 2025 13:38:02 GMT)
Full text and
rfc822 format available.
Message #142 received at 79070 <at> debbugs.gnu.org (full text, mbox):
Stéphane Marks <shipmints <at> gmail.com> writes:
> On Wed, Jul 23, 2025 at 9:02 AM Alvaro Ramirez
> <alvaro <at> xenodium.com> wrote:
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Thanks, but one of my previous comments, viz.:
> >
> > This should explain better what are the indications of the
> > problem.
> >
> > is still not addressed.
>
> Updated PROBLEMS in
> 0006-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch.
> Hope that's better now.
>
> >> A tiny bit of additional info with respect to roll back
> >> (yields
> >> deprecation warning) vs roll forward fix... macOS seems to
> >> use
> >> a
> >> different dictation mechanism after NSTextInputClient was
> >> introduced (Emacs v30). Attaching screenshots showing
> >> different
> >> UI
> >> dictation triggered by either patch.
> >
> > Could you please spell out what that means for Emacs users?
>
> Not much really. This is more of a macOS implementation
> detail. Emacs users will get their dictation feature back,
> regressed in Emacs 30. Fixing the regression leads to using a
> newer API, which triggers a slightly different-looking UI.
>
> I think that's a feature of macOS which changed the UI, not a
> function of the patch?
While dictation UI is a macOS implementation detail, we do have a
choice to patch by rolling back vs forward which would trigger one
UI over the other (even on the same macOS version). We've so far
agreed to roll forward (to move away from deprecated APIs).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Wed, 23 Jul 2025 14:01:01 GMT)
Full text and
rfc822 format available.
Message #145 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Jul 23, 2025 at 9:37 AM Alvaro Ramirez <alvaro <at> xenodium.com> wrote:
> Stéphane Marks <shipmints <at> gmail.com> writes:
>
> > On Wed, Jul 23, 2025 at 9:02 AM Alvaro Ramirez
> > <alvaro <at> xenodium.com> wrote:
> >
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> > > Thanks, but one of my previous comments, viz.:
> > >
> > > This should explain better what are the indications of the
> > > problem.
> > >
> > > is still not addressed.
> >
> > Updated PROBLEMS in
> > 0006-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch.
> > Hope that's better now.
> >
> > >> A tiny bit of additional info with respect to roll back
> > >> (yields
> > >> deprecation warning) vs roll forward fix... macOS seems to
> > >> use
> > >> a
> > >> different dictation mechanism after NSTextInputClient was
> > >> introduced (Emacs v30). Attaching screenshots showing
> > >> different
> > >> UI
> > >> dictation triggered by either patch.
> > >
> > > Could you please spell out what that means for Emacs users?
> >
> > Not much really. This is more of a macOS implementation
> > detail. Emacs users will get their dictation feature back,
> > regressed in Emacs 30. Fixing the regression leads to using a
> > newer API, which triggers a slightly different-looking UI.
> >
> > I think that's a feature of macOS which changed the UI, not a
> > function of the patch?
>
> While dictation UI is a macOS implementation detail, we do have a
> choice to patch by rolling back vs forward which would trigger one
> UI over the other (even on the same macOS version). We've so far
> agreed to roll forward (to move away from deprecated APIs).
>
Forward is good. I see only the conventional UI on macOS 12 across all
other apps and NSTextInputClient is available since macOS 10. I think any
commentary should say something like "visual presentation may vary across
macOS versions."
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Wed, 23 Jul 2025 14:12:01 GMT)
Full text and
rfc822 format available.
Message #148 received at 79070 <at> debbugs.gnu.org (full text, mbox):
Stéphane Marks <shipmints <at> gmail.com> writes:
> Forward is good. I see only the conventional UI on macOS 12
> across all other apps and NSTextInputClient is available
> since macOS 10. I think any commentary should say something
> like "visual presentation may vary across macOS
> versions."
Luckily not needed as the visual representation is consistent
across macOS versions and only changes if we change our patch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Wed, 23 Jul 2025 14:29:02 GMT)
Full text and
rfc822 format available.
Message #151 received at 79070 <at> debbugs.gnu.org (full text, mbox):
Stéphane Marks <shipmints <at> gmail.com> writes:
> Forward is good. I see only the conventional UI on macOS 12 across all
> other apps and NSTextInputClient is available since macOS 10. I think
> any commentary should say something like "visual presentation may vary
> across macOS versions."
It's not just the UI. In macOS 14, the dictation system has been
reworked to e.g. allow simultaneous dictation and keyboard input. If you
see the old UI, that means that you don't get that feature. I don't
think that Emacs and especially PROBLEMS should explain that. MacOS
users should know.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Wed, 23 Jul 2025 15:18:01 GMT)
Full text and
rfc822 format available.
Message #154 received at 79070 <at> debbugs.gnu.org (full text, mbox):
> On 23 Jul 2025, at 15:28, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>
> Stéphane Marks <shipmints <at> gmail.com> writes:
>
>> Forward is good. I see only the conventional UI on macOS 12 across all
>> other apps and NSTextInputClient is available since macOS 10. I think
>> any commentary should say something like "visual presentation may vary
>> across macOS versions."
>
> It's not just the UI. In macOS 14, the dictation system has been
> reworked to e.g. allow simultaneous dictation and keyboard input. If you
> see the old UI, that means that you don't get that feature. I don't
> think that Emacs and especially PROBLEMS should explain that.
+1 Also prone to outdating due to external factors.
> MacOS
> users should know.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Wed, 23 Jul 2025 16:24:04 GMT)
Full text and
rfc822 format available.
Message #157 received at 79070 <at> debbugs.gnu.org (full text, mbox):
> From: Alvaro Ramirez <alvaro <at> xenodium.com>
> Cc: shipmints <at> gmail.com, gerd.moellmann <at> gmail.com, 79070 <at> debbugs.gnu.org,
> kickingvegas <at> gmail.com, stefankangas <at> gmail.com
> Date: Wed, 23 Jul 2025 14:02:28 +0100
>
> > This should explain better what are the indications of the
> > problem.
> >
> > is still not addressed.
>
> Updated PROBLEMS in
> 0006-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch.
> Hope that's better now.
Are you sure you sent the right patch? The text in PROBLEMS looks the
same to me.
What I had in mind is something like this:
** Text dictation doesn't work on macOS
The indication is that <describe here what users will see>.
One reason for this is that the Emacs permissions for using the
microphone were rejected in the past. To reset the permissions, run
this command:
etc.
> >> A tiny bit of additional info with respect to roll back (yields
> >> deprecation warning) vs roll forward fix... macOS seems to use a
> >> different dictation mechanism after NSTextInputClient was
> >> introduced (Emacs v30). Attaching screenshots showing different
> >> UI dictation triggered by either patch.
> >
> > Could you please spell out what that means for Emacs users?
>
> Not much really. This is more of a macOS implementation
> detail. Emacs users will get their dictation feature back,
> regressed in Emacs 30. Fixing the regression leads to using a
> newer API, which triggers a slightly different-looking UI. The way
> the feature is triggered (global keyboard shortcut) and
> transcription behaviour remain the same, so no significant change
> in expectation as to how the feature works.
>
> In a little more detail...
>
> Introducing NSTextInputClient in Emacs v30 broke/removed dictation
> as a side effect. This introduction seems to signal to macOS to
> rely more on NSTextInputClient (new class) and less on NSTextInput
> (deprecated class) to power separate internal dictation
> subsystems. The screenshots I shared show the slightly
> different-looking UI for each internal subsystem. One uses a large
> microphone icon vs the tiny blue microphone icon (newer). Enabling
> dictation (global keyboard shortcut) and transcription behaviour
> remain the same.
How about explaining some of this in NEWS? If the UI looks a bit
different, users could be confused, so maybe we should tell them it's
a bit different?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Wed, 23 Jul 2025 17:07:01 GMT)
Full text and
rfc822 format available.
Message #160 received at 79070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> Are you sure you sent the right patch? The text in PROBLEMS
> looks the
> same to me.
Yup, but there were separate PROBLEMS entries and worded
differently. I like your proposed format better. Changed in
0007-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch
> What I had in mind is something like this:
>
> ** Text dictation doesn't work on macOS
>
> The indication is that <describe here what users will see>.
>
> One reason for this is that the Emacs permissions for using the
> microphone were rejected in the past. To reset the
> permissions, run
> this command:
>
> etc.
Looks good to me. Adopted in attached patch.
> How about explaining some of this in NEWS? If the UI looks a
> bit
> different, users could be confused, so maybe we should tell them
> it's
> a bit different?
Sounds good. Mentioned in NEWS now.
[0007-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Sat, 26 Jul 2025 10:03:02 GMT)
Full text and
rfc822 format available.
Message #163 received at 79070 <at> debbugs.gnu.org (full text, mbox):
> From: Alvaro Ramirez <alvaro <at> xenodium.com>
> Cc: shipmints <at> gmail.com, gerd.moellmann <at> gmail.com, 79070 <at> debbugs.gnu.org,
> kickingvegas <at> gmail.com, stefankangas <at> gmail.com
> Date: Wed, 23 Jul 2025 18:06:46 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Are you sure you sent the right patch? The text in PROBLEMS
> > looks the
> > same to me.
>
> Yup, but there were separate PROBLEMS entries and worded
> differently. I like your proposed format better. Changed in
> 0007-Enabled-macOS-dictation-post-NSTextInputClient-migration.patch
>
> > What I had in mind is something like this:
> >
> > ** Text dictation doesn't work on macOS
> >
> > The indication is that <describe here what users will see>.
> >
> > One reason for this is that the Emacs permissions for using the
> > microphone were rejected in the past. To reset the
> > permissions, run
> > this command:
> >
> > etc.
>
> Looks good to me. Adopted in attached patch.
>
> > How about explaining some of this in NEWS? If the UI looks a
> > bit
> > different, users could be confused, so maybe we should tell them
> > it's
> > a bit different?
>
> Sounds good. Mentioned in NEWS now.
Thanks, LGTM. Gerd, could you please install on master?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Sat, 26 Jul 2025 10:14:02 GMT)
Full text and
rfc822 format available.
Message #166 received at 79070 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Thanks, LGTM. Gerd, could you please install on master?
It's in master now, and I'll close the bug in a minute.
bug marked as fixed in version 31.1, send any further explanations to
79070 <at> debbugs.gnu.org and Alvaro Ramirez <alvaro <at> xenodium.com>
Request was from
Gerd Möllmann <gerd.moellmann <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sat, 26 Jul 2025 10:14:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79070; Package
emacs.
(Sat, 26 Jul 2025 10:21:01 GMT)
Full text and
rfc822 format available.
Message #171 received at 79070 <at> debbugs.gnu.org (full text, mbox):
Thank you Eli and Gerd!
> On 26 Jul 2025, at 11:14, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> Thanks, LGTM. Gerd, could you please install on master?
>
> It's in master now, and I'll close the bug in a minute.
This bug report was last modified today.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.