GNU bug report logs -
#59793
29.0.60; subr.elc is not compiled correctly
Previous Next
Reported by: Feng Shu <tumashu <at> 163.com>
Date: Sat, 3 Dec 2022 07:26:02 UTC
Severity: normal
Tags: notabug
Found in version 29.0.60
Done: Stefan Kangas <stefankangas <at> gmail.com>
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 59793 in the body.
You can then email your comments to 59793 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#59793; Package
emacs.
(Sat, 03 Dec 2022 07:26:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Feng Shu <tumashu <at> 163.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sat, 03 Dec 2022 07:26: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)]
This week, I faced an issue about emacs-eat:
eat-yank not work well: https://codeberg.org/akib/emacs-eat/issues/9
-------------
(defun eat-yank (&optional arg)
"Same as `yank', but for Eat.
ARG is passed to `yank', which see."
(interactive "*P")
(when eat--terminal
(funcall eat--synchronize-scroll-function)
(cl-letf* ((inhibit-read-only t)
(insert-for-yank (symbol-function #'insert-for-yank))
((symbol-function #'insert-for-yank)
(lambda (&rest args)
(cl-letf (((symbol-function #'insert)
(lambda (&rest args)
(eat-send-string-as-yank
eat--terminal
(mapconcat (lambda (arg)
(if (stringp arg)
arg
(string arg)))
args "")))))
(apply insert-for-yank args)))))
(yank arg))))
---------
After some test with author of emacs-eat, we find that config
(require 'eat)
(load "subr.el")
work, while the below config do not work.
(require 'eat)
(load "subr.elc")
we find that C-x C-e insert-for-yank and insert-for-yank-1 works too.
so we think subr.elc is not compiled correctly, I use the below
script to compile emacs, do not install and run ~/emacs/emacs29/src/emacs directly
------------------------------------------------
#!/bin/bash
cd ${HOME}/emacs/emacs29
make clean
git reset --hard
git clean -xdf
git pull
./autogen.sh
./configure \
--with-x-toolkit=lucid \
--with-json \
make bootstrap &&
make
--------------------------------------------------------
(fn STRING)
(defalias 'insert-for-yank #[257 "\211C\300\301\302\303\"\"\210\304\305\306\307\242#\211\262\203*\0\310\242\306O!\210\211\242\304O\240\210\202 \0\210\310\242!\207" [run-hook-wrapped yank-transform-functions make-closure #[257 "\300\300\242!\240\210\301\207" [V0 nil] 4 "\n\n(fn F)"] nil next-single-property-change 0 yank-handler insert-for-yank-1] 7 (#$ . 136200)])#@55 Helper for `insert-for-yank', which see.
(fn STRING)
(defalias 'insert-for-yank-1 #[257 "\211;\205\n\0\303\304\305#\211A@\206\0`\306\307@\203$\0@!\210\202'\0c\210`\262\307\3108\2047\0\311\"\210\211V\203L\0\312S!\203L\0\313S\314\307$\210 \307=\203V\0\3158\3168\205a\0\3168\211)\207" [inhibit-read-only yank-undo-function this-command get-text-property 0 yank-handler nil t 2 remove-yank-excluded-properties text-properties-at put-text-property rear-nonsticky 3 4] 10 (#$ . 136889)])#@286 Insert before point a substring of BUFFER, without text properties.
BUFFER may be a buffer or a buffer name.
Arguments START and END are character positions specifying the substring.
They default to the values of (point-min) and (point-max) in BUFFER.
-------------------------------------------------------
[subr.elc (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
In GNU Emacs 29.0.60 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.16.0, Xaw3d scroll bars) of 2022-12-03 built on Tumashu
Repository revision: 1e36ad9458e8deacfc85da573bb0ca0f270d4802
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)
Configured using:
'configure --with-x-toolkit=lucid --with-json'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB
Important settings:
value of $LANG: zh_CN.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Eat
Minor modes in effect:
eat--semi-char-mode: t
global-git-commit-mode: t
magit-auto-revert-mode: t
shell-dirtrack-mode: t
emms-playing-time-display-mode: t
emms-playing-time-mode: t
cnfonts-mode: t
projectile-mode: t
company-posframe-mode: t
global-company-mode: t
company-mode: t
org-super-agenda-mode: t
pyim-isearch-mode: t
vertico-mode: t
savehist-mode: t
global-tab-line-mode: t
tab-line-mode: t
global-so-long-mode: t
electric-pair-mode: t
pixel-scroll-precision-mode: t
recentf-mode: t
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
context-menu-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
line-number-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
/home/feng/.emacs.d/elpa-29/transient-0.3.7/transient hides /home/feng/emacs/emacs29/lisp/transient
Features:
(shadow mail-extr emacsbug cursor-sensor eat emacs-helper eh-guix
skeleton guix geiser-guile info-look geiser-debug geiser-repl
geiser-image geiser-capf geiser-doc geiser-menu geiser-autodoc
geiser-edit geiser-completion geiser-eval geiser-connection
geiser-syntax scheme geiser-impl help-fns radix-tree geiser-log
geiser-popup view geiser-custom geiser-base geiser eh-misc vundo
magit-bookmark magit-submodule magit-obsolete magit-popup magit-blame
magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch
magit-clone magit-remote magit-commit magit-sequence magit-notes
magit-worktree magit-tag magit-merge magit-branch magit-reset
magit-files magit-refs magit-status magit magit-repos magit-apply
magit-wip magit-log which-func imenu edebug debug backtrace magit-diff
smerge-mode diff diff-mode git-commit log-edit pcvs-util add-log
magit-core magit-autorevert magit-margin magit-transient magit-process
with-editor shell server magit-mode transient magit-git magit-section
magit-utils aggressive-indent eh-emms emms-player-vlc emms-player-mpv
emms-player-mplayer emms-setup emms-librefm-stream
emms-librefm-scrobbler emms-playlist-limit emms-i18n emms-history
emms-score emms-stream-info emms-metaplaylist-mode emms-bookmarks
emms-cue emms-mode-line-icon emms-browser emms-volume
emms-volume-sndioctl emms-volume-mixerctl emms-volume-pulse
emms-volume-amixer emms-playlist-sort emms-last-played emms-player-xine
emms-player-mpd tq emms-playing-time emms-lyrics emms-url
emms-player-simple emms-streams emms-show-all emms-tag-editor
emms-tag-tracktag emms-mark emms-mode-line easy-mmode emms-cache
emms-info-native bindat emms-info-exiftool emms-info-tinytag
emms-info-metaflac emms-info-opusinfo emms-info-ogginfo
emms-info-mp3info emms-info emms-later-do emms-playlist-mode
emms-source-playlist emms-source-file locate emms emms-compat el2org
cnfonts tempel citre-config citre-lang-fileref citre-tags citre-ctags
citre-readtags citre-readtags-tables citre-backend-interface
citre-ui-peek color citre-ui-jump citre-common-tag citre-common-util
projectile lisp-mnt grep compile ibuf-ext ibuffer ibuffer-loaddefs
eh-gnus-common ebdb-message ebdb-gnus nnselect ebdb-mua ebdb-complete
ebdb-com crm ebdb-format ebdb-i18n-chn ebdb-i18n ebdb-i18n-basic ebdb
inline eieio-base timezone eww url-queue thingatpt mm-url gnus-demon
gnus-search eieio-opt cl-extra speedbar ezimage dframe gnus-agent
gnus-srvr gnus-score score-mode nnvirtual gnus-msg nntp gnus-cite
gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig gnus-cache
gnus-sum shr pixel-fill kinsoku url-file svg dom gnus-group gnus-undo
gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7
nnoo parse-time iso8601 gnus-spec gnus-int gnus-range message sendmail
yank-media puny rfc822 mml mml-sec epa derived epg rfc6068 epg-config
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus nnheader
gnus-util mail-utils range mm-util mail-prsvr eh-complete
company-posframe company-keywords company-etags etags fileloop xref
company-gtags company-template company-dabbrev-code company-dabbrev
company-files company-capf company edmacro eh-org org-ql peg
org-super-agenda ts ht s dash org-habit org-capture ob-python python
project treesit ob-org ox-md ox-org ox-odt rng-loc rng-uri rng-parse
rng-match rng-dt rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok
nxml-util ox-latex ox-icalendar org-agenda ox-html table ox-ascii
ox-publish ox org-element org-persist xdg avl-tree generator autorevert
filenotify org-attach org-id org-refile org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-src ob-comint org-pcomplete pcomplete
comint ansi-osc ansi-color org-list org-footnote org-faces org-entities
time-date noutline outline icons ob-emacs-lisp ob-core ob-eval org-cycle
org-table ol org-fold org-fold-core org-keys oc org-loaddefs find-func
org-version org-compat org-macs format-spec eh-functions eh-theme
modus-vivendi-theme modus-themes eh-basic cal-china-x cal-china lunar
solar cal-dst holidays holiday-loaddefs cal-menu calendar cal-loaddefs
pyim-basedict pyim-cregexp-utils pyim pyim-cloudim pyim-probe
pyim-preview pyim-page posframe pyim-indicator pyim-dregcache
pyim-dhashcache sort pyim-dict async pcase pyim-autoselector
pyim-process pyim-punctuation pyim-outcome pyim-candidates pyim-cstring
pyim-cregexp xr rx pyim-codes pyim-imobjs pyim-pinyin pyim-entered
pyim-dcache pyim-pymap pyim-scheme pyim-common wdired dired
dired-loaddefs vc vc-dispatcher consult-vertico consult compat-28 compat
compat-macs kmacro orderless vertico-directory vertico savehist tab-line
switch-window switch-window-mvborder switch-window-asciiart quail
help-mode so-long elec-pair bookmark text-property-search pp
pixel-scroll cua-base ring recentf tree-widget wid-edit elpa-mirror
finder-inf company-posframe-autoloads org-ql-autoloads f-autoloads
ov-autoloads vertico-posframe-autoloads standard-themes-autoloads
corfu-terminal-autoloads aggressive-indent-autoloads posframe-autoloads
company-autoloads paredit-autoloads citre-autoloads
dired-ranger-autoloads dired-hacks-utils-autoloads kotlin-mode-autoloads
geiser-guile-autoloads org-download-autoloads org-super-agenda-autoloads
ht-autoloads pos-tip-autoloads switch-window-autoloads vertico-autoloads
ts-autoloads s-autoloads orderless-autoloads liberime-autoloads
modus-themes-autoloads xmlgen-autoloads wrap-region-autoloads
wgrep-autoloads vundo-autoloads consult-autoloads cape-autoloads
recentf-ext-autoloads rainbow-mode-autoloads
rainbow-delimiters-autoloads pyim-basedict-autoloads flycheck-autoloads
tempel-autoloads popon-autoloads projectile-autoloads emms-autoloads
org-contrib-autoloads ox-gfm-autoloads magit-autoloads
git-commit-autoloads compat-autoloads guix-autoloads bui-autoloads
edit-indirect-autoloads transient-autoloads marginalia-autoloads
geiser-autoloads pkg-info-autoloads epl-autoloads elpa-mirror-autoloads
el2org-autoloads ebdb-i18n-chn-autoloads ebdb-autoloads pyim-autoloads
async-autoloads markdown-mode-autoloads xr-autoloads
magit-section-autoloads dash-autoloads with-editor-autoloads
ef-themes-autoloads peg-autoloads cnfonts-autoloads
cal-china-x-autoloads autopair-autoloads corfu-autoloads
adaptive-wrap-autoloads info package browse-url url url-proxy
url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x
map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib
china-util rmc iso-transl tooltip cconv eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo x-toolkit xinput2 x multi-tty
make-network-process emacs)
Memory information:
((conses 16 1037039 194901)
(symbols 48 53037 10)
(strings 32 552314 5779)
(string-bytes 1 9927388)
(vectors 16 96033)
(vector-slots 8 13241192 54062)
(floats 8 1205 139)
(intervals 56 1667 0)
(buffers 984 16))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sat, 03 Dec 2022 09:57:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 59793 <at> debbugs.gnu.org (full text, mbox):
> From: Feng Shu <tumashu <at> 163.com>
> Date: Sat, 03 Dec 2022 15:24:55 +0800
>
> This week, I faced an issue about emacs-eat:
>
>
> eat-yank not work well: https://codeberg.org/akib/emacs-eat/issues/9
>
>
> -------------
> (defun eat-yank (&optional arg)
> "Same as `yank', but for Eat.
>
> ARG is passed to `yank', which see."
> (interactive "*P")
> (when eat--terminal
> (funcall eat--synchronize-scroll-function)
> (cl-letf* ((inhibit-read-only t)
> (insert-for-yank (symbol-function #'insert-for-yank))
> ((symbol-function #'insert-for-yank)
> (lambda (&rest args)
> (cl-letf (((symbol-function #'insert)
> (lambda (&rest args)
> (eat-send-string-as-yank
> eat--terminal
> (mapconcat (lambda (arg)
> (if (stringp arg)
> arg
> (string arg)))
> args "")))))
> (apply insert-for-yank args)))))
> (yank arg))))
> ---------
>
>
> After some test with author of emacs-eat, we find that config
>
> (require 'eat)
> (load "subr.el")
>
> work, while the below config do not work.
>
> (require 'eat)
> (load "subr.elc")
>
>
> we find that C-x C-e insert-for-yank and insert-for-yank-1 works too.
>
>
> so we think subr.elc is not compiled correctly, I use the below
> script to compile emacs, do not install and run ~/emacs/emacs29/src/emacs directly
Thanks, but what exactly "does not work" in the byte-compiled version of
subr.el? Do you have a recipe to reproduce the problem you see without
using emacs-eat? If so, please post such a recipe. Because from your
report, I don't see how to reproduce the problem and how to investigate it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sat, 03 Dec 2022 15:18:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 59793 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Feng Shu <tumashu <at> 163.com>
>> Date: Sat, 03 Dec 2022 15:24:55 +0800
>>
>> This week, I faced an issue about emacs-eat:
>>
>>
>> eat-yank not work well: https://codeberg.org/akib/emacs-eat/issues/9
>>
>>
>> -------------
>> (defun eat-yank (&optional arg)
>> "Same as `yank', but for Eat.
>>
>> ARG is passed to `yank', which see."
>> (interactive "*P")
>> (when eat--terminal
>> (funcall eat--synchronize-scroll-function)
>> (cl-letf* ((inhibit-read-only t)
>> (insert-for-yank (symbol-function #'insert-for-yank))
>> ((symbol-function #'insert-for-yank)
>> (lambda (&rest args)
>> (cl-letf (((symbol-function #'insert)
>> (lambda (&rest args)
>> (eat-send-string-as-yank
>> eat--terminal
>> (mapconcat (lambda (arg)
>> (if (stringp arg)
>> arg
>> (string arg)))
>> args "")))))
>> (apply insert-for-yank args)))))
>> (yank arg))))
>> ---------
>>
>>
>> After some test with author of emacs-eat, we find that config
>>
>> (require 'eat)
>> (load "subr.el")
>>
>> work, while the below config do not work.
>>
>> (require 'eat)
>> (load "subr.elc")
>>
>>
>> we find that C-x C-e insert-for-yank and insert-for-yank-1 works too.
>>
>>
>> so we think subr.elc is not compiled correctly, I use the below
>> script to compile emacs, do not install and run ~/emacs/emacs29/src/emacs directly
>
> Thanks, but what exactly "does not work" in the byte-compiled version of
> subr.el? Do you have a recipe to reproduce the problem you see without
> using emacs-eat? If so, please post such a recipe. Because from your
> report, I don't see how to reproduce the problem and how to investigate it.
>
>
>
I have figured out a simpler reproduction method, but since I don't have
the much information other than the subr.elc file, Feng should verify
it.
1. Save the following in a file.
--8<---------------cut here---------------start------------->8---
(require 'cl-lib)
(defun bug59593-yank (&optional arg)
(interactive "*P")
(cl-letf* ((inhibit-read-only t)
(insert-for-yank (symbol-function #'insert-for-yank))
((symbol-function #'insert-for-yank)
(lambda (&rest args)
(cl-letf (((symbol-function #'insert)
(lambda (&rest args)
(message
"%S"
(mapconcat (lambda (arg)
(if (stringp arg)
arg
(string arg)))
args "")))))
(apply insert-for-yank args)))))
(yank arg)))
--8<---------------cut here---------------end--------------->8---
2. emacs -nw -Q -l FILE-FROM-STEP-1 -l PATH/TO/YOUR/SUBR.EL.GZ
3. Kill something.
4. M-x bug59593-yank. Now you should see the yank text in echo area.
5. emacs -nw -Q -l FILE-FROM-STEP-1 -l PATH/TO/ATTACHED/SUBR.ELC
6. Kill something.
7. M-x bug59593-yank. The yank text got unexpectedly inserted.
Feng, can you precisely specify the commit you're building from? It'll
allow to reproducing your problem more easily and precisely.
--
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib <at> hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sat, 03 Dec 2022 15:38:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 59793 <at> debbugs.gnu.org (full text, mbox):
On December 3, 2022 5:10:52 PM GMT+02:00, Akib Azmain Turja <akib <at> disroot.org> wrote:
>
> 1. Save the following in a file.
>
> --8<---------------cut here---------------start------------->8---
> (require 'cl-lib)
> (defun bug59593-yank (&optional arg)
> (interactive "*P")
> (cl-letf* ((inhibit-read-only t)
> (insert-for-yank (symbol-function #'insert-for-yank))
> ((symbol-function #'insert-for-yank)
> (lambda (&rest args)
> (cl-letf (((symbol-function #'insert)
> (lambda (&rest args)
> (message
> "%S"
> (mapconcat (lambda (arg)
> (if (stringp arg)
> arg
> (string arg)))
> args "")))))
> (apply insert-for-yank args)))))
> (yank arg)))
> --8<---------------cut here---------------end--------------->8---
>
> 2. emacs -nw -Q -l FILE-FROM-STEP-1 -l PATH/TO/YOUR/SUBR.EL.GZ
> 3. Kill something.
> 4. M-x bug59593-yank. Now you should see the yank text in echo area.
> 5. emacs -nw -Q -l FILE-FROM-STEP-1 -l PATH/TO/ATTACHED/SUBR.ELC
> 6. Kill something.
> 7. M-x bug59593-yank. The yank text got unexpectedly inserted.
Am I missing something, or do you redefine a function and then expect it to work like you never redefined it?
And what do you mean by ATTACHED/SUBR.ELC? I don't see any attachments to your message.
So I'm still confused...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sat, 03 Dec 2022 17:46:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 59793 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> On December 3, 2022 5:10:52 PM GMT+02:00, Akib Azmain Turja <akib <at> disroot.org> wrote:
>>
>> 1. Save the following in a file.
>>
>> --8<---------------cut here---------------start------------->8---
>> (require 'cl-lib)
>> (defun bug59593-yank (&optional arg)
>> (interactive "*P")
>> (cl-letf* ((inhibit-read-only t)
>> (insert-for-yank (symbol-function #'insert-for-yank))
>> ((symbol-function #'insert-for-yank)
>> (lambda (&rest args)
>> (cl-letf (((symbol-function #'insert)
>> (lambda (&rest args)
>> (message
>> "%S"
>> (mapconcat (lambda (arg)
>> (if (stringp arg)
>> arg
>> (string arg)))
>> args "")))))
>> (apply insert-for-yank args)))))
>> (yank arg)))
>> --8<---------------cut here---------------end--------------->8---
>>
>> 2. emacs -nw -Q -l FILE-FROM-STEP-1 -l PATH/TO/YOUR/SUBR.EL.GZ
>> 3. Kill something.
>> 4. M-x bug59593-yank. Now you should see the yank text in echo area.
>> 5. emacs -nw -Q -l FILE-FROM-STEP-1 -l PATH/TO/ATTACHED/SUBR.ELC
>> 6. Kill something.
>> 7. M-x bug59593-yank. The yank text got unexpectedly inserted.
>
> Am I missing something, or do you redefine a function and then expect it to work like you never redefined it?
Unexpected: bug59593-yank just inserts the killed text.
Expected: bug59593-yank intercepts and shows the killed text in echo
area.
>
> And what do you mean by ATTACHED/SUBR.ELC? I don't see any attachments to your message.
>
I mean, the subr.elc attached in the original file. I'm also attaching
the subr.elc I got from Feng Shu on Codeberg.
> So I'm still confused...
Is it clear now? (Somehow, I think, no.)
--
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib <at> hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sat, 03 Dec 2022 17:52:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 59793 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> On December 3, 2022 5:10:52 PM GMT+02:00, Akib Azmain Turja <akib <at> disroot.org> wrote:
>>
>> 1. Save the following in a file.
>>
>> --8<---------------cut here---------------start------------->8---
>> (require 'cl-lib)
>> (defun bug59593-yank (&optional arg)
>> (interactive "*P")
>> (cl-letf* ((inhibit-read-only t)
>> (insert-for-yank (symbol-function #'insert-for-yank))
>> ((symbol-function #'insert-for-yank)
>> (lambda (&rest args)
>> (cl-letf (((symbol-function #'insert)
>> (lambda (&rest args)
>> (message
>> "%S"
>> (mapconcat (lambda (arg)
>> (if (stringp arg)
>> arg
>> (string arg)))
>> args "")))))
>> (apply insert-for-yank args)))))
>> (yank arg)))
>> --8<---------------cut here---------------end--------------->8---
>>
>> 2. emacs -nw -Q -l FILE-FROM-STEP-1 -l PATH/TO/YOUR/SUBR.EL.GZ
>> 3. Kill something.
>> 4. M-x bug59593-yank. Now you should see the yank text in echo area.
>> 5. emacs -nw -Q -l FILE-FROM-STEP-1 -l PATH/TO/ATTACHED/SUBR.ELC
>> 6. Kill something.
>> 7. M-x bug59593-yank. The yank text got unexpectedly inserted.
>
> Am I missing something, or do you redefine a function and then expect it to work like you never redefined it?
Unexpected: bug59593-yank just inserts the killed text.
Expected: bug59593-yank intercepts and shows the killed text in echo
area.
>
> And what do you mean by ATTACHED/SUBR.ELC? I don't see any attachments to your message.
>
I mean, the subr.elc attached in the original file. I'm also attaching
the subr.elc I got from Feng Shu on Codeberg.
> So I'm still confused...
Is it clear now? (Somehow, I think, no.)
--
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib <at> hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sat, 03 Dec 2022 17:52:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 59793 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Akib Azmain Turja <akib <at> disroot.org> writes:
[...]
> I mean, the subr.elc attached in the original file. I'm also attaching
> the subr.elc I got from Feng Shu on Codeberg.
[...]
Ah, I forgot. Now attaching.
[#9-subr.elc (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
--
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib <at> hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sat, 03 Dec 2022 18:11:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 59793 <at> debbugs.gnu.org (full text, mbox):
> From: Akib Azmain Turja <akib <at> disroot.org>
> Cc: Feng Shu <tumashu <at> 163.com>, 59793 <at> debbugs.gnu.org
> Date: Sat, 03 Dec 2022 23:16:47 +0600
>
> > Am I missing something, or do you redefine a function and then expect it to work like you never redefined it?
>
> Unexpected: bug59593-yank just inserts the killed text.
> Expected: bug59593-yank intercepts and shows the killed text in echo
> area.
You have redefined a subr.el function with cl-letf*, so how is what happens
as result a bug in Emacs? Does the original subr.el function not do what
it's supposed to do, before you replace it?
I understand you didn't expect the result of cl-letf*, and were surprised by
what you saw, but I don't understand why you expect the Emacs development to
do something about your surprise.
> > So I'm still confused...
>
> Is it clear now? (Somehow, I think, no.)
See above: I understand what you are saying, but not why this is submitted
as a bug to the Emacs development team.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sat, 03 Dec 2022 21:50:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 59793 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Akib Azmain Turja <akib <at> disroot.org>
>> Cc: Feng Shu <tumashu <at> 163.com>, 59793 <at> debbugs.gnu.org
>> Date: Sat, 03 Dec 2022 23:16:47 +0600
>>
>> > Am I missing something, or do you redefine a function and then expect it to work like you never redefined it?
>>
>> Unexpected: bug59593-yank just inserts the killed text.
>> Expected: bug59593-yank intercepts and shows the killed text in echo
>> area.
>
> You have redefined a subr.el function with cl-letf*, so how is what happens
> as result a bug in Emacs? Does the original subr.el function not do what
> it's supposed to do, before you replace it?
>
> I understand you didn't expect the result of cl-letf*, and were surprised by
> what you saw, but I don't understand why you expect the Emacs development to
> do something about your surprise.
I think the issue is that:
when I run emacs-29 first, I can not temp override `insert' function
in `insert-for-yank-1' with the help of cl-letf in bug59593-yank
(require 'cl-lib)
(defun bug59593-yank (&optional arg)
(interactive "*P")
(cl-letf* ((inhibit-read-only t)
(insert-for-yank (symbol-function #'insert-for-yank))
((symbol-function #'insert-for-yank)
(lambda (&rest args)
(cl-letf (((symbol-function #'insert)
(lambda (&rest args)
(message
"%S"
(mapconcat (lambda (arg)
(if (stringp arg)
arg
(string arg)))
args "")))))
(apply insert-for-yank args)))))
(yank arg)))
but after I run (load "subr.el"), overriding `insert' success.
if I run (load "subr.elc"), overriding do not success.
so I think subr.elc maybe has some problem.
by the way, I use f6e2f30f394a270c2eca9a9a14be46876d2a86e5 to test
>
>> > So I'm still confused...
>>
>> Is it clear now? (Somehow, I think, no.)
>
> See above: I understand what you are saying, but not why this is submitted
> as a bug to the Emacs development team.
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sat, 03 Dec 2022 21:51:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 59793 <at> debbugs.gnu.org (full text, mbox):
Akib Azmain Turja <akib <at> disroot.org> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Feng Shu <tumashu <at> 163.com>
>>> Date: Sat, 03 Dec 2022 15:24:55 +0800
>>>
>>> This week, I faced an issue about emacs-eat:
>>>
>>>
>>> eat-yank not work well: https://codeberg.org/akib/emacs-eat/issues/9
>>>
>>>
>>> -------------
>>> (defun eat-yank (&optional arg)
>>> "Same as `yank', but for Eat.
>>>
>>> ARG is passed to `yank', which see."
>>> (interactive "*P")
>>> (when eat--terminal
>>> (funcall eat--synchronize-scroll-function)
>>> (cl-letf* ((inhibit-read-only t)
>>> (insert-for-yank (symbol-function #'insert-for-yank))
>>> ((symbol-function #'insert-for-yank)
>>> (lambda (&rest args)
>>> (cl-letf (((symbol-function #'insert)
>>> (lambda (&rest args)
>>> (eat-send-string-as-yank
>>> eat--terminal
>>> (mapconcat (lambda (arg)
>>> (if (stringp arg)
>>> arg
>>> (string arg)))
>>> args "")))))
>>> (apply insert-for-yank args)))))
>>> (yank arg))))
>>> ---------
>>>
>>>
>>> After some test with author of emacs-eat, we find that config
>>>
>>> (require 'eat)
>>> (load "subr.el")
>>>
>>> work, while the below config do not work.
>>>
>>> (require 'eat)
>>> (load "subr.elc")
>>>
>>>
>>> we find that C-x C-e insert-for-yank and insert-for-yank-1 works too.
>>>
>>>
>>> so we think subr.elc is not compiled correctly, I use the below
>>> script to compile emacs, do not install and run ~/emacs/emacs29/src/emacs directly
>>
>> Thanks, but what exactly "does not work" in the byte-compiled version of
>> subr.el? Do you have a recipe to reproduce the problem you see without
>> using emacs-eat? If so, please post such a recipe. Because from your
>> report, I don't see how to reproduce the problem and how to investigate it.
>>
>>
>>
>
> I have figured out a simpler reproduction method, but since I don't have
> the much information other than the subr.elc file, Feng should verify
> it.
>
> 1. Save the following in a file.
>
> (require 'cl-lib)
> (defun bug59593-yank (&optional arg)
> (interactive "*P")
> (cl-letf* ((inhibit-read-only t)
> (insert-for-yank (symbol-function #'insert-for-yank))
> ((symbol-function #'insert-for-yank)
> (lambda (&rest args)
> (cl-letf (((symbol-function #'insert)
> (lambda (&rest args)
> (message
> "%S"
> (mapconcat (lambda (arg)
> (if (stringp arg)
> arg
> (string arg)))
> args "")))))
> (apply insert-for-yank args)))))
> (yank arg)))
>
> 2. emacs -nw -Q -l FILE-FROM-STEP-1 -l PATH/TO/YOUR/SUBR.EL.GZ
> 3. Kill something.
> 4. M-x bug59593-yank. Now you should see the yank text in echo area.
> 5. emacs -nw -Q -l FILE-FROM-STEP-1 -l PATH/TO/ATTACHED/SUBR.ELC
> 6. Kill something.
> 7. M-x bug59593-yank. The yank text got unexpectedly inserted.
>
> Feng, can you precisely specify the commit you're building from? It'll
> allow to reproducing your problem more easily and precisely.
The step is work to show this issue, and I use the below commit to test.
commit f6e2f30f394a270c2eca9a9a14be46876d2a86e5 (HEAD -> emacs-29, origin/emacs-29)
Author: Stefan Kangas <stefankangas <at> gmail.com>
Date: Sat Dec 3 15:31:07 2022 +0100
; Fix typos
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sun, 04 Dec 2022 07:09:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 59793 <at> debbugs.gnu.org (full text, mbox):
> From: Feng Shu <tumashu <at> 163.com>
> Cc: Akib Azmain Turja <akib <at> disroot.org>, 59793 <at> debbugs.gnu.org
> Date: Sun, 04 Dec 2022 05:49:06 +0800
>
> > You have redefined a subr.el function with cl-letf*, so how is what happens
> > as result a bug in Emacs? Does the original subr.el function not do what
> > it's supposed to do, before you replace it?
> >
> > I understand you didn't expect the result of cl-letf*, and were surprised by
> > what you saw, but I don't understand why you expect the Emacs development to
> > do something about your surprise.
>
> I think the issue is that:
> when I run emacs-29 first, I can not temp override `insert' function
> in `insert-for-yank-1' with the help of cl-letf in bug59593-yank
>
> (require 'cl-lib)
> (defun bug59593-yank (&optional arg)
> (interactive "*P")
> (cl-letf* ((inhibit-read-only t)
> (insert-for-yank (symbol-function #'insert-for-yank))
> ((symbol-function #'insert-for-yank)
> (lambda (&rest args)
> (cl-letf (((symbol-function #'insert)
> (lambda (&rest args)
> (message
> "%S"
> (mapconcat (lambda (arg)
> (if (stringp arg)
> arg
> (string arg)))
> args "")))))
> (apply insert-for-yank args)))))
> (yank arg)))
>
>
> but after I run (load "subr.el"), overriding `insert' success.
> if I run (load "subr.elc"), overriding do not success.
>
> so I think subr.elc maybe has some problem.
No, I see no problem in subr.elc here.
You need to find a different way of overriding what insert-for-yank does.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sun, 04 Dec 2022 16:17:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 59793 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Akib Azmain Turja <akib <at> disroot.org>
>> Cc: Feng Shu <tumashu <at> 163.com>, 59793 <at> debbugs.gnu.org
>> Date: Sat, 03 Dec 2022 23:16:47 +0600
>>
>> > Am I missing something, or do you redefine a function and then expect it to work like you never redefined it?
>>
>> Unexpected: bug59593-yank just inserts the killed text.
>> Expected: bug59593-yank intercepts and shows the killed text in echo
>> area.
>
> You have redefined a subr.el function with cl-letf*, so how is what happens
> as result a bug in Emacs? Does the original subr.el function not do what
> it's supposed to do, before you replace it?
>
> I understand you didn't expect the result of cl-letf*, and were surprised by
> what you saw, but I don't understand why you expect the Emacs development to
> do something about your surprise.
>
With subr.el (source), the bug59793-yank function overrides
'insert-for-yank' successfully.
With subr.elc (compiled byte-code), the function can't override
'insert-for-yank'. Just try to replace the 'cl-letf' (not 'cl-letf*')
form with an 'error' call, bug59793-yank still just inserts text, which
is, obviously, unexpected.
>> > So I'm still confused...
>>
>> Is it clear now? (Somehow, I think, no.)
>
> See above: I understand what you are saying, but not why this is submitted
> as a bug to the Emacs development team.
Both source and compiled Emacs Lisp code should show the same behavior,
except performance. But 'subr.el' and 'subr.elc' show different
behaviors. Isn't this a byte-compiler bug?
--
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib <at> hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sun, 04 Dec 2022 16:17:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 59793 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Feng Shu <tumashu <at> 163.com>
>> Cc: Akib Azmain Turja <akib <at> disroot.org>, 59793 <at> debbugs.gnu.org
>> Date: Sun, 04 Dec 2022 05:49:06 +0800
>>
>> > You have redefined a subr.el function with cl-letf*, so how is what happens
>> > as result a bug in Emacs? Does the original subr.el function not do what
>> > it's supposed to do, before you replace it?
>> >
>> > I understand you didn't expect the result of cl-letf*, and were surprised by
>> > what you saw, but I don't understand why you expect the Emacs development to
>> > do something about your surprise.
>>
>> I think the issue is that:
>> when I run emacs-29 first, I can not temp override `insert' function
>> in `insert-for-yank-1' with the help of cl-letf in bug59593-yank
>>
>> (require 'cl-lib)
>> (defun bug59593-yank (&optional arg)
>> (interactive "*P")
>> (cl-letf* ((inhibit-read-only t)
>> (insert-for-yank (symbol-function #'insert-for-yank))
>> ((symbol-function #'insert-for-yank)
>> (lambda (&rest args)
>> (cl-letf (((symbol-function #'insert)
>> (lambda (&rest args)
>> (message
>> "%S"
>> (mapconcat (lambda (arg)
>> (if (stringp arg)
>> arg
>> (string arg)))
>> args "")))))
>> (apply insert-for-yank args)))))
>> (yank arg)))
>>
>>
>> but after I run (load "subr.el"), overriding `insert' success.
>> if I run (load "subr.elc"), overriding do not success.
>>
>> so I think subr.elc maybe has some problem.
>
> No, I see no problem in subr.elc here.
Did you the subr.elc attached in the first message? Note that my
subr.elc works good, but using the subr.elc attached in the first
message shows the problem.
>
> You need to find a different way of overriding what insert-for-yank does.
Why? And any suggestion how?
--
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib <at> hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sun, 04 Dec 2022 17:01:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 59793 <at> debbugs.gnu.org (full text, mbox):
> From: Akib Azmain Turja <akib <at> disroot.org>
> Cc: tumashu <at> 163.com, 59793 <at> debbugs.gnu.org
> Date: Sun, 04 Dec 2022 17:18:24 +0600
>
> > I understand you didn't expect the result of cl-letf*, and were surprised by
> > what you saw, but I don't understand why you expect the Emacs development to
> > do something about your surprise.
> >
>
> With subr.el (source), the bug59793-yank function overrides
> 'insert-for-yank' successfully.
>
> With subr.elc (compiled byte-code), the function can't override
> 'insert-for-yank'. Just try to replace the 'cl-letf' (not 'cl-letf*')
> form with an 'error' call, bug59793-yank still just inserts text, which
> is, obviously, unexpected.
Yes, I understand.
> > See above: I understand what you are saying, but not why this is submitted
> > as a bug to the Emacs development team.
>
> Both source and compiled Emacs Lisp code should show the same behavior,
> except performance.
No, not when you replace the function's definition with the likes of
cl-letf.
> But 'subr.el' and 'subr.elc' show different behaviors. Isn't this a
> byte-compiler bug?
No.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sun, 04 Dec 2022 17:03:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 59793 <at> debbugs.gnu.org (full text, mbox):
> From: Akib Azmain Turja <akib <at> disroot.org>
> Cc: Feng Shu <tumashu <at> 163.com>, 59793 <at> debbugs.gnu.org
> Date: Sun, 04 Dec 2022 17:21:28 +0600
>
> > You need to find a different way of overriding what insert-for-yank does.
>
> Why? And any suggestion how?
The why is "because what you tried doesn't work." As to how, I'd need to
know more about the problem you are trying to solve, and why you've selected
such a strange way of solving it. Surely programming for Emacs doesn't
require replacing the definitions of standard functions.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sun, 04 Dec 2022 17:26:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 59793 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Akib Azmain Turja via "Bug reports for GNU Emacs, the Swiss army knife
of text editors" <bug-gnu-emacs <at> gnu.org> writes:
> Both source and compiled Emacs Lisp code should show the same behavior,
> except performance. But 'subr.el' and 'subr.elc' show different
> behaviors. Isn't this a byte-compiler bug?
In Emacs 29.0.50, I checked M-x disassemble RET insert-for-yank-1 RET
and it looks like it uses an 'insert' bytcode operation instead of
funcalling the 'insert' function. I think this is what prevents
overriding of 'insert' from working on byte-compiled code, as explained
in '(elisp) Advice and Byte Code'.
> --
> Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
> Fediverse: akib <at> hostux.social
> Codeberg: akib
> emailselfdefense.fsf.org | "Nothing can be secure without encryption."
Best regards.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sun, 04 Dec 2022 17:36:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 59793 <at> debbugs.gnu.org (full text, mbox):
> From: miha <at> kamnitnik.top
> Cc: tumashu <at> 163.com, 59793 <at> debbugs.gnu.org
> Date: Sun, 04 Dec 2022 18:27:07 +0100
>
> In Emacs 29.0.50, I checked M-x disassemble RET insert-for-yank-1 RET
> and it looks like it uses an 'insert' bytcode operation instead of
> funcalling the 'insert' function. I think this is what prevents
> overriding of 'insert' from working on byte-compiled code, as explained
> in '(elisp) Advice and Byte Code'.
Of course! And the same can happen with other function calls that the byte
compiler converts into bytecode operations.
That is why this technique is unreliable and shouldn't be used.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sun, 04 Dec 2022 19:02:02 GMT)
Full text and
rfc822 format available.
Message #56 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
miha--- via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:
> Akib Azmain Turja via "Bug reports for GNU Emacs, the Swiss army knife
> of text editors" <bug-gnu-emacs <at> gnu.org> writes:
>
>> Both source and compiled Emacs Lisp code should show the same behavior,
>> except performance. But 'subr.el' and 'subr.elc' show different
>> behaviors. Isn't this a byte-compiler bug?
>
> In Emacs 29.0.50, I checked M-x disassemble RET insert-for-yank-1 RET
> and it looks like it uses an 'insert' bytcode operation instead of
> funcalling the 'insert' function. I think this is what prevents
> overriding of 'insert' from working on byte-compiled code, as explained
> in '(elisp) Advice and Byte Code'.
That might be the reason on some Emacs. But I have observed that
'insert-for-yank' isn't overridden at all with Feng's 'subr.elc' on my
Emacs. 'insert-for-yank' doesn't have any opcode, does it?
--
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib <at> hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sun, 04 Dec 2022 19:02:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sun, 04 Dec 2022 19:02:03 GMT)
Full text and
rfc822 format available.
Message #62 received at 59793 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Akib Azmain Turja <akib <at> disroot.org>
>> Cc: Feng Shu <tumashu <at> 163.com>, 59793 <at> debbugs.gnu.org
>> Date: Sun, 04 Dec 2022 17:21:28 +0600
>>
>> > You need to find a different way of overriding what insert-for-yank does.
>>
>> Why? And any suggestion how?
>
> The why is "because what you tried doesn't work." As to how, I'd need to
> know more about the problem you are trying to solve, and why you've selected
> such a strange way of solving it. Surely programming for Emacs doesn't
> require replacing the definitions of standard functions.
I'm trying a make 'eat-yank' (a command in Eat package) to be as much
identical as to 'yank' as possible. That hack allows to avoid
overriding the whole 'yank' logic.
--
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib <at> hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sun, 04 Dec 2022 19:19:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 59793 <at> debbugs.gnu.org (full text, mbox):
> From: Akib Azmain Turja <akib <at> disroot.org>
> Cc: tumashu <at> 163.com, 59793 <at> debbugs.gnu.org
> Date: Mon, 05 Dec 2022 00:56:16 +0600
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Akib Azmain Turja <akib <at> disroot.org>
> >> Cc: Feng Shu <tumashu <at> 163.com>, 59793 <at> debbugs.gnu.org
> >> Date: Sun, 04 Dec 2022 17:21:28 +0600
> >>
> >> > You need to find a different way of overriding what insert-for-yank does.
> >>
> >> Why? And any suggestion how?
> >
> > The why is "because what you tried doesn't work." As to how, I'd need to
> > know more about the problem you are trying to solve, and why you've selected
> > such a strange way of solving it. Surely programming for Emacs doesn't
> > require replacing the definitions of standard functions.
>
> I'm trying a make 'eat-yank' (a command in Eat package) to be as much
> identical as to 'yank' as possible. That hack allows to avoid
> overriding the whole 'yank' logic.
You cannot rely on such kludges. The Emacs feature provided for doing stuff
like this is add-function.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Fri, 09 Dec 2022 10:46:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 59793 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
[...]
>> >> > You need to find a different way of overriding what insert-for-yank does.
>> >>
>> >> Why? And any suggestion how?
>> >
>> > The why is "because what you tried doesn't work." As to how, I'd need to
>> > know more about the problem you are trying to solve, and why you've selected
>> > such a strange way of solving it. Surely programming for Emacs doesn't
>> > require replacing the definitions of standard functions.
>>
>> I'm trying a make 'eat-yank' (a command in Eat package) to be as much
>> identical as to 'yank' as possible. That hack allows to avoid
>> overriding the whole 'yank' logic.
>
> You cannot rely on such kludges. The Emacs feature provided for doing stuff
> like this is add-function.
How about this:
(with-temp-buffer
(yank ARG)
(buffer-string))
I guess this is OK, right?
Or, A better idea would be:
(with-temp-buffer
(insert-for-yank (current-kill (cond
((listp ARG) 0)
((eq ARG '-) -2)
(t (1- ARG)))))
(buffer-string))
Right?
But how can I copy 'yank-transform-functions' hook to the temporary
buffer?
--
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib <at> hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Fri, 09 Dec 2022 19:19:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 59793 <at> debbugs.gnu.org (full text, mbox):
> From: Akib Azmain Turja <akib <at> disroot.org>
> Cc: tumashu <at> 163.com, 59793 <at> debbugs.gnu.org
> Date: Fri, 09 Dec 2022 16:44:36 +0600
>
> But how can I copy 'yank-transform-functions' hook to the temporary
> buffer?
By using add-hook, of course.
But I feel that I don't understand the question, or am missing
something, because you basically are asking how to assign to a
variable the value of another variable, and what is the difficulty
with that that needs such a question to be answered?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sat, 10 Dec 2022 06:17:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 59793 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Akib Azmain Turja <akib <at> disroot.org>
>> Cc: tumashu <at> 163.com, 59793 <at> debbugs.gnu.org
>> Date: Fri, 09 Dec 2022 16:44:36 +0600
>>
>> But how can I copy 'yank-transform-functions' hook to the temporary
>> buffer?
>
> By using add-hook, of course.
>
> But I feel that I don't understand the question, or am missing
> something, because you basically are asking how to assign to a
> variable the value of another variable, and what is the difficulty
> with that that needs such a question to be answered?
Yes, you didn't understand.
Hooks can have global and local function. I'm asking how to copy the
local functions in 'yank-transform-functions' hook to the temporary
buffer? (So that 'run-hook-wrapped' calls the same functions on both
(original and temporary) buffers.)
--
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib <at> hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sat, 10 Dec 2022 07:33:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 59793 <at> debbugs.gnu.org (full text, mbox):
[வெள்ளி டிசம்பர் 09, 2022] Akib Azmain Turja via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
> But how can I copy 'yank-transform-functions' hook to the temporary
> buffer?
I think you can do,
(setq-local yank-transform-functions
(buffer-local-value 'yank-transform-functions ORIG-BUFFER))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sat, 10 Dec 2022 08:27:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 59793 <at> debbugs.gnu.org (full text, mbox):
> From: Akib Azmain Turja <akib <at> disroot.org>
> Cc: tumashu <at> 163.com, 59793 <at> debbugs.gnu.org
> Date: Sat, 10 Dec 2022 12:09:58 +0600
>
> Hooks can have global and local function. I'm asking how to copy the
> local functions in 'yank-transform-functions' hook to the temporary
> buffer? (So that 'run-hook-wrapped' calls the same functions on both
> (original and temporary) buffers.)
Isn't the local value of the hook accessible via buffer-local-value?
And setting that to be the local hook in the temporary buffer should
be achievable by calling add-hook with the 4th argument non-nil.
Or what else am I missing?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sat, 10 Dec 2022 08:43:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 59793 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Visuwesh <visuweshm <at> gmail.com> writes:
> [வெள்ளி டிசம்பர் 09, 2022] Akib Azmain Turja via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
>
>> But how can I copy 'yank-transform-functions' hook to the temporary
>> buffer?
>
> I think you can do,
>
> (setq-local yank-transform-functions
> (buffer-local-value 'yank-transform-functions ORIG-BUFFER))
Thanks, I know that. But is there any else to do? I don't know the
internals of 'run-hook-wrapped', so I'm not sure whether that function
treats the global and the local value of hook as the sole source of
truth.
--
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib <at> hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#59793; Package
emacs.
(Sun, 10 Sep 2023 19:27:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 59793 <at> debbugs.gnu.org (full text, mbox):
tags 59793 + notabug
close 59793
thanks
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: miha <at> kamnitnik.top
>> Cc: tumashu <at> 163.com, 59793 <at> debbugs.gnu.org
>> Date: Sun, 04 Dec 2022 18:27:07 +0100
>>
>> In Emacs 29.0.50, I checked M-x disassemble RET insert-for-yank-1 RET
>> and it looks like it uses an 'insert' bytcode operation instead of
>> funcalling the 'insert' function. I think this is what prevents
>> overriding of 'insert' from working on byte-compiled code, as explained
>> in '(elisp) Advice and Byte Code'.
>
> Of course! And the same can happen with other function calls that the byte
> compiler converts into bytecode operations.
>
> That is why this technique is unreliable and shouldn't be used.
This bug report was about redefining built-in functions that have
opcodes and then wondering why the bytecode behavior differs from the
interpreted.
The answer is: don't do that, use add-advice instead.
So I'm closing this bug report.
Added tag(s) notabug.
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sun, 10 Sep 2023 19:27:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
59793 <at> debbugs.gnu.org and Feng Shu <tumashu <at> 163.com>
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sun, 10 Sep 2023 19:27: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.
(Mon, 09 Oct 2023 11:24:11 GMT)
Full text and
rfc822 format available.
This bug report was last modified 189 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.