reddit / emacs

avoiding or stripping "^M" on yank

titaniumbones · 2022-02-09 14:37
Running gnome 41.3 on a recent arch linux, and recent emacs git with pgtk and native-comp. I'm lately getting `^M` characters before the line feed whenever I paste (that is, yank) from certain applications. I especially notice gnome-terminal, and pdf text content copied from evince. Google suggests it's a text encoding issue, but I created a new buffer, confirmed that `buffer-file-coding-system` is set to `utf-8-unix`, and also checked that gnome-terminal encoding is set to utf-8 (don't know how to check in evince).The problem still persists. Yank is of course written in C so I can't run edebug on it, and anyway I wouldn't really know what to look for. 1. Any suggestions for how to track this down? It is relatively new, but I am not sure \*exactly\* how long it's been going on. 2. If I can't fix it, shouldn't I be able to somehow filter the text in the kill-ring so that the "^M" characters are removed before being inserted? Thanks everyone!
bravosierrasierra · 2022-02-09 15:05
try (setq inhibit-eol-conversion nil)
titaniumbones · 2022-02-09 15:09
hmm, no change. looks like it was already set to nil in any case. Shoot.
bravosierrasierra · 2022-02-09 15:14
next try: (prefer-coding-system 'utf-8) (set-charset-priority 'unicode) (set-default-coding-systems 'utf-8) (set-file-name-coding-system 'utf-8) (set-keyboard-coding-system 'utf-8) (set-language-environment 'utf-8) (set-terminal-coding-system 'utf-8) (setq default-buffer-file-coding-system 'utf-8 default-process-coding-system '(utf-8-unix . utf-8-unix) file-name-coding-system 'utf-8 org-export-coding-system 'utf-8 )
titaniumbones · 2022-02-09 16:01
drat. still no difference before and after.
rguy84 · 2022-02-09 17:41
I use windows, and get `^M` when yanking stuff that was from a table, namely from Outlook - are you doing something like that too?
titaniumbones · 2022-02-09 18:54
I'm on linux, so honestly I don't think I ought to be seeing this issue, but if I e.g. try to copy some text from gnome-terminal, every line ends in \`\^M\`
eli-zaretskii · 2022-02-09 19:36
I'm guessing that those other applications, or some setup of your clipboard, are the culprit. That said, try this C-x RET x utf-8-dos RET
titaniumbones · 2022-02-09 19:46
>I'm guessing that those other applications, or some setup of your clipboard, are the culprit. I've just now confirmed that the problem does not occur with other terminal programs or pdf viewers, so my guess is that it's a gnome issue. Have reposted this question on r/gnome: [https://www.reddit.com/r/gnome/comments/solztb/carriage\_return\_when\_pasting\_from/](https://www.reddit.com/r/gnome/comments/solztb/carriage_return_when_pasting_from/) Thank you for the help diagnosing.
flyin1501 · 2022-02-09 20:02
(1) Does the Carriage Return (the `^M` character name) exist in your clipboard? Maybe it's not a problem in Emacs, and those applications are really sending the character to the clipboard for some reason. Is this on X11 or on Wayland? Edit: [found that you also asked in r/gnome](https://www.reddit.com/r/gnome/comments/solztb/carriage_return_when_pasting_from/). Maybe people there will know more. (2) > Yank is of course written in C [`yank` is defined in simple.el](https://github.com/emacs-mirror/emacs/blob/55463952f27da869cee860186dbddfe53443a619/lisp/simple.el#L5729), even in the master branch. If nothing works you could just add an advice around `current-kill` (as `yank`'s main logic is essentially (insert-for-yank (current-kill ... if you check its source code) to remove the `^M` at the end of its return value.
titaniumbones · 2022-02-09 20:21
ah, sorry. I think it is compiled via native-comp on my system -- my help showed it as a compiled function. I'll check it out. I tried this, but the characters still show up when pasting from external programs. If I then kill+yank the same text from within emacs, the advice does work: ``` (defun mwp-remove-carriage-return (&optional arg pred) (setq kill-ring (cons (replace-regexp-in-string " " "" (car kill-ring)) (cdr kill-ring))) ) (advice-add 'yank :before 'mwp-remove-carriage-return) ``` anyway, the workings of the wayland clipboard are mysterious to me. I also can't yet get the funny characters to show up anywhere else besides Emacs.
titaniumbones · 2022-02-09 20:42
argh. I found this old code of mine from early last year, when pgtk was a little less polished. commenting it out and restarting fixes the issue. I never really did understand it so glad to be rid of it. ``` ;; (setq wl-copy-process nil) ;; (defun wl-copy (text) ;; (setq wl-copy-process (make-process :name "wl-copy" ;; :buffer nil ;; :command '("wl-copy" "-f" "-n") ;; :connection-type 'pipe)) ;; (process-send-string wl-copy-process text) ;; (process-send-eof wl-copy-process)) ;; (defun wl-paste () ;; (if (and wl-copy-process (process-live-p wl-copy-process)) nil ;; (shell-command-to-string "wl-paste -t text -n 2 >/dev/null"))) ;; (setq interprogram-cut-function 'wl-copy) ;; (setq interprogram-paste-function 'wl-paste) ;; (setq confirm-kill-processes nil) ```
flyin1501 · 2022-02-09 20:48
Your advice doesn't work because Emacs only reads the system clipboard into `kill-ring` *during* yank. (I recommend using the Helpful package, which provides help pages with source code in it.) This should work, I think: (defun mwp-remove-carriage-return (func &rest args) (let ((result (apply func args))) (if (stringp result) (replace-regexp-in-string (string ?\C-m) "" result) result))) (advice-add 'current-kill :around 'mwp-remove-carriage-return)
titaniumbones · 2022-02-10 02:55
Ah cool thanks. I'll avoid using for now as it seems like thee problem was somehow related to some filtering that wl-paste was doing on the clipboard contents. But cool to look into something so fundamental.
flyin1501 · 2022-02-10 06:58
After you mentioned wl-paste, it became a lot easier to search. This seems to be a GTK bug. - Same issue reported to neovim: https://github.com/neovim/neovim/issues/10223 - To Alacritty: https://github.com/alacritty/alacritty/issues/2844 - To Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1547595 - And finally to GTK: https://gitlab.gnome.org/GNOME/gtk/-/issues/2307 (with activity from 2 days ago about someone hitting the same issue in gnome-terminal)