bug#34969: 26.2; `emacs -Q` unable to copy \200's eight-bit detail buffer

bug#34969: 26.2; `emacs -Q` unable to copy \200's eight-bit detail buffer

[Van L]

-- A
1. started `emacs -Q` in XQuartz/Darwin
2. C-x b *scratch*
3. C-x 5 2 ;; new frame
4. C-h b ;; bindings for keys in new window of new frame
5. C-x s self ;; find \200
6. able to copy unicode \200 detail buffer to *scratch*
7. unable to copy eight-bit \200 detail buffer to *scratch*

-- misc: before beginning to bisect .emacs

: 1-6 are single instance runs of emacs
: 7 is single instance run of `emacs -Q` where problem was reproduced

: 1
: [no problem the first time]
: GNU Emacs 26.2 (build 1, x86_64-apple-darwin15.6.0, X toolkit)
: of 2019-03-21

: 2
: [has doom-modeline, doom-theme]
: [no problem the first time]
: GNU Emacs 26.1.92 (build 2, x86_64-apple-darwin15.6.0, Carbon Version 157 AppKit 1404.47)
: of 2019-03-22

: 3
: ssh -Xf XXX emacs
: [has problem the first time]
: [has doom-modeline]
: GNU Emacs 26.1 (build 1, x86_64--netbsd, X toolkit, Xaw3d scroll bars)
: of 2019-03-17

: 4
: [has problem the second time]
: GNU Emacs 26.2 (build 1, x86_64-apple-darwin15.6.0, X toolkit)
: of 2019-03-21

: 5
: [has doom-modeline, doom-theme]
: [has no problem the second time]
: GNU Emacs 26.1.92 (build 2, x86_64-apple-darwin15.6.0, Carbon Version 157 AppKit 1404.47)
: of 2019-03-22

: 6
: [has problem the third time]
: [on XQuartz]
: [~/bin/emacs26.2r1 links to €nfs€/build/emacs26.2-rc1/bin/emacs-26.2]
: GNU Emacs 26.2 (build 1, x86_64-apple-darwin15.6.0, X toolkit)
: of 2019-03-21

: 7 `emacs -Q`
: [this is the first time for `emacs -Q]
: [has problem the forth time run for thise version]
: [on XQuartz]
: [~/bin/emacs26.2r1 links to €nfs€/build/emacs26.2-rc1/bin/emacs-26.2]
: GNU Emacs 26.2 (build 1, x86_64-apple-darwin15.6.0, X toolkit)
: of 2019-03-21



In GNU Emacs 26.2 (build 1, x86_64-apple-darwin15.6.0, X toolkit)
 of 2019-03-21 built on XXX.XXX
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
Recent messages:
Mark saved where search started

Char:   (128, #o200, #x80, file ...) point=1166 of 27318 (4%) column=0
Mark set [3 times]

Mark saved where search started

Char:   (4194176, #o17777600, #x3fff80, raw-byte) point=10875 of 37045 (29%) column=0
Mark set [9 times]
Making completion list... [2 times]

Configured using:
 'configure --target x86_64-apple-darwin15.6.0
 --prefix=/Users/XXX/opt/share/build/emacs26.2-rc1
 --with-mailutils --without-imagemagick --with-sound=no --with-dbus
 --disable-ns-self-contained --without-ns --without-toolkit-scroll-bars
 --with-x --with-x-toolkit=lucid --with-modules --with-jpeg=no
 --with-gif=no --with-tiff=no'

Configured features:
XAW3D XPM PNG RSVG DBUS GSETTINGS GLIB NOTIFY ACL GNUTLS LIBXML2
FREETYPE XFT ZLIB LUCID X11 XDBE XIM MODULES THREADS

Important settings:
  value of $LANG: en_AU.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv dired dired-loaddefs format-spec rfc822 mml
mml-sec password-cache epa derived epg epg-config gnus-util rmail
rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils wid-edit descr-text misearch multi-isearch
kmacro two-column iso-transl help-mode easymenu cl-loaddefs cl-lib
elec-pair time-date mule-util tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type 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 elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame cl-generic
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 charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind kqueue
dynamic-setting system-font-setting font-render-setting x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 118210 20908)
 (symbols 48 32912 1)
 (miscs 40 1896 216)
 (strings 32 90246 2940)
 (string-bytes 1 2096897)
 (vectors 16 24424)
 (vector-slots 8 1703098 157156)
 (floats 8 63 259)
 (intervals 56 562 80)
 (buffers 992 13))

bug#34969: 26.2; `emacs -Q` unable to copy \200's eight-bit detail buffer

[Eli Zaretskii]

> From: Van L <van@scratch.space>
> Date: Sun, 24 Mar 2019 14:39:56 +1100
> 
> : 6
> : [has problem the third time]
> : [on XQuartz]
> : [~/bin/emacs26.2r1 links to \200nfs\200/build/emacs26.2-rc1/bin/emacs-26.2]
> : GNU Emacs 26.2 (build 1, x86_64-apple-darwin15.6.0, X toolkit)
> : of 2019-03-21
> 
> : 7 `emacs -Q`
> : [this is the first time for `emacs -Q]
> : [has problem the forth time run for thise version]
> : [on XQuartz]
> : [~/bin/emacs26.2r1 links to \200nfs\200/build/emacs26.2-rc1/bin/emacs-26.2]
> : GNU Emacs 26.2 (build 1, x86_64-apple-darwin15.6.0, X toolkit)
> : of 2019-03-21

Does "the forth time" mean do all the steps 4 times before the problem
happens?  Or does it mean repeat only some of the steps 4 times?

IOW, can you please show the transcript of repeated steps in these
situations?

What happens if you set interprogram-cut-function and
interprogram-paste-function to nil?

(And why do your symlink targets include \200 characters?)

bug#34969: 26.2; `emacs -Q` unable to copy \200's eight-bit detail buffer

[Van L]

> Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Van L <van@scratch.space>
>> Date: Sun, 24 Mar 2019 14:39:56 +1100
>> 
>> : 6
>> : [has problem the third time]
>> : [on XQuartz]
>> : [~/bin/emacs26.2r1 links to \200nfs\200/build/emacs26.2-rc1/bin/emacs-26.2]
>> : GNU Emacs 26.2 (build 1, x86_64-apple-darwin15.6.0, X toolkit)
>> : of 2019-03-21
>> 
>> : 7 `emacs -Q`
>> : [this is the first time for `emacs -Q]
>> : [has problem the forth time run for thise version]
>> : [on XQuartz]
>> : [~/bin/emacs26.2r1 links to \200nfs\200/build/emacs26.2-rc1/bin/emacs-26.2]
>> : GNU Emacs 26.2 (build 1, x86_64-apple-darwin15.6.0, X toolkit)
>> : of 2019-03-21
> 
> Does "the forth time" mean do all the steps 4 times before the problem
> happens?  Or does it mean repeat only some of the steps 4 times?

4th time means the forth time starting from the initial condition before Emacs is started for the same Emacs version to run in isolation without other instances running.

> IOW, can you please show the transcript of repeated steps in these
> situations?

That is under the section `-- A` in the bug-report. 
I had hoped the trace was caught in the bug-report.

> What happens if you set interprogram-cut-function and
> interprogram-paste-function to nil?

Will do the next time I get a chance.

> (And why do your symlink targets include \200 characters?)

I used `C-x 8 RET horizontal ellipsis` the email program was unable to process.
The \200 was what the email program used as substitute.

bug#34969: 26.2; `emacs -Q` unable to copy \200's eight-bit detail buffer

[Eli Zaretskii]

> From: Van L <van@scratch.space>
> Date: Mon, 25 Mar 2019 14:14:47 +1100
> Cc: 34969@debbugs.gnu.org
> 
> >> : 7 `emacs -Q`
> >> : [this is the first time for `emacs -Q]
> >> : [has problem the forth time run for thise version]
> >> : [on XQuartz]
> >> : [~/bin/emacs26.2r1 links to \200nfs\200/build/emacs26.2-rc1/bin/emacs-26.2]
> >> : GNU Emacs 26.2 (build 1, x86_64-apple-darwin15.6.0, X toolkit)
> >> : of 2019-03-21
> > 
> > Does "the forth time" mean do all the steps 4 times before the problem
> > happens?  Or does it mean repeat only some of the steps 4 times?
> 
> 4th time means the forth time starting from the initial condition before Emacs is started for the same Emacs version to run in isolation without other instances running.

So you actually started Emacs 4 times, and only on the 4th restart it
exhibited the problem?  If so, I'm quite sure this is caused by some
external software, perhaps something that takes ownership of the
clipboard contents, e.g. because it wants to let you have several
different clipboard buffers.  Do you have something like that
installed and active?

> > IOW, can you please show the transcript of repeated steps in these
> > situations?
> 
> That is under the section `-- A` in the bug-report. 
> I had hoped the trace was caught in the bug-report.

Section A just gives a single sequence, but it doesn't tell how to do
that several times, i.e. what exactly is repeated N times.

> > What happens if you set interprogram-cut-function and
> > interprogram-paste-function to nil?
> 
> Will do the next time I get a chance.

If I'm right, the problem will disappear.

> > (And why do your symlink targets include \200 characters?)
> 
> I used `C-x 8 RET horizontal ellipsis` the email program was unable to process.
> The \200 was what the email program used as substitute.

Strange email program: \200 is an unassigned codepoint.

bug#34969: 26.2; `emacs -Q` unable to copy \200's eight-bit detail buffer

[Van L]

> On 26 Mar 2019, at 04:46, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Van L <van@scratch.space>
>> Date: Mon, 25 Mar 2019 14:14:47 +1100
>> Cc: 34969@debbugs.gnu.org
>> 
>>>> : 7 `emacs -Q`
>>>> : [this is the first time for `emacs -Q]
>>>> : [has problem the forth time run for thise version]
>>>> : [on XQuartz]
>>>> : [~/bin/emacs26.2r1 links to \200nfs\200/build/emacs26.2-rc1/bin/emacs-26.2]
>>>> : GNU Emacs 26.2 (build 1, x86_64-apple-darwin15.6.0, X toolkit)
>>>> : of 2019-03-21
>>> 
>>> Does "the forth time" mean do all the steps 4 times before the problem
>>> happens?  Or does it mean repeat only some of the steps 4 times?
>> 
>> 4th time means the forth time starting from the initial condition before Emacs is started for the same Emacs version to run in isolation without other instances running.
> 
> So you actually started Emacs 4 times, and only on the 4th restart it
> exhibited the problem?

Of the 7 times listed in the bug-report, I started four times 26.2, three of those operated the .emacs file.

1. did *not* show the problem
2. did show the problem
3. did
4. did; when called as `emacs -Q` 

>  If so, I'm quite sure this is caused by some
> external software, perhaps something that takes ownership of the
> clipboard contents, e.g. because it wants to let you have several
> different clipboard buffers.  Do you have something like that
> installed and active?

Provided there are no nasty contaminations from the 'net, I have the plain old platformOS, MacPort, XQuartz installed.
Copy and paste within the one Emacs is being interfered with if what you suggest is true.

> 
>>> IOW, can you please show the transcript of repeated steps in these
>>> situations?
>> 
>> That is under the section `-- A` in the bug-report. 
>> I had hoped the trace was caught in the bug-report.
> 
> Section A just gives a single sequence, but it doesn't tell how to do
> that several times, i.e. what exactly is repeated N times.

a. run Emacs
b. goto *scratch* buffer
c. create new frame
d. lookup keybindings for *scratch* buffer
e. find `self`
f. for the two variants of \200 copy and paste details buffer to *scratch*

Repeat the above a-f steps 7 times as listed in the bug-report for those platforms detailed.

> 
> 
>>> What happens if you set interprogram-cut-function and
>>> interprogram-paste-function to nil?
>> 
>> Will do the next time I get a chance.
> 
> If I'm right, the problem will disappear.

I am inside the one Emacs's copy and paste, and not going out of the Emacs.

>>> (And why do your symlink targets include \200 characters?)
>> 
>> I used `C-x 8 RET horizontal ellipsis` the email program was unable to process.
>> The \200 was what the email program used as substitute.
> 
> Strange email program: \200 is an unassigned codepoint.

That was the emacs-bug-report mechanism in Emacs that did that.

bug#34969: 26.2; `emacs -Q` unable to copy \200's eight-bit detail buffer

[Eli Zaretskii]

> From: Van L <van@scratch.space>
> Date: Tue, 26 Mar 2019 10:46:12 +1100
> Cc: 34969@debbugs.gnu.org
> 
> Copy and paste within the one Emacs is being interfered with if what you suggest is true.

When you paste, and there's stuff in the clipboard, Emacs checks
whether Emacs itself is the owner of that stuff.  If it is, we yank
from the kill ring instead of accessing the clipboard, because yanking
is both faster and doesn't need any decoding.

So I'm guessing that some software on your system takes ownership of
the text in the clipboard, and Emacs then accesses that via the
window-system selections, and fails to decode raw bytes due to
character encoding issues.

> > Section A just gives a single sequence, but it doesn't tell how to do
> > that several times, i.e. what exactly is repeated N times.
> 
> a. run Emacs
> b. goto *scratch* buffer
> c. create new frame
> d. lookup keybindings for *scratch* buffer
> e. find `self`
> f. for the two variants of \200 copy and paste details buffer to *scratch*
> 
> Repeat the above a-f steps 7 times as listed in the bug-report for those platforms detailed.

We are miscommunicating, I think.  Each one of the 7 instances in your
report says something like this, for example:

> : 4
> : [has problem the second time]
> : GNU Emacs 26.2 (build 1, x86_64-apple-darwin15.6.0, X toolkit)
> : of 2019-03-21

I'm asking what exactly does "second time" mean here.  Did you start
this version of Emacs twice, or did you start it only once and
performed the steps b-f above twice one after the other in the same
Emacs session?

> >>> What happens if you set interprogram-cut-function and
> >>> interprogram-paste-function to nil?
> >> 
> >> Will do the next time I get a chance.
> > 
> > If I'm right, the problem will disappear.
> 
> I am inside the one Emacs's copy and paste, and not going out of the Emacs.

I don't think I understand what this alludes to.  Is it a response to
my sentence that starts with "If I'm right"?

> >>> (And why do your symlink targets include \200 characters?)
> >> 
> >> I used `C-x 8 RET horizontal ellipsis` the email program was unable to process.
> >> The \200 was what the email program used as substitute.
> > 
> > Strange email program: \200 is an unassigned codepoint.
> 
> That was the emacs-bug-report mechanism in Emacs that did that.

If you sent the report via mailclient, then this is probably the same
problem which causes the issue with pasting that we are discussing.

bug#34969: 26.2; `emacs -Q` unable to copy \200's eight-bit detail buffer

[Van L]

> Eli Zaretskii writes:
> 
>> From: Van L <van@scratch.space>
>> Date: Tue, 26 Mar 2019 10:46:12 +1100
>> Cc: 34969@debbugs.gnu.org
>> 
>> Copy and paste within the one Emacs is being interfered with if what you suggest is true.
> 
> When you paste, and there's stuff in the clipboard, Emacs checks
> whether Emacs itself is the owner of that stuff.  If it is, we yank
> from the kill ring instead of accessing the clipboard, because yanking
> is both faster and doesn't need any decoding.
> 
> So I'm guessing that some software on your system takes ownership of
> the text in the clipboard, and Emacs then accesses that via the
> window-system selections, and fails to decode raw bytes due to
> character encoding issues.

Could be.

>>> Section A just gives a single sequence, but it doesn't tell how to do
>>> that several times, i.e. what exactly is repeated N times.
>> 
>> a. run Emacs
>> b. goto *scratch* buffer
>> c. create new frame
>> d. lookup keybindings for *scratch* buffer
>> e. find `self`
>> f. for the two variants of \200 copy and paste details buffer to *scratch*
>> 
>> Repeat the above a-f steps 7 times as listed in the bug-report for those platforms detailed.
> 
> We are miscommunicating, I think.  Each one of the 7 instances in your
> report says something like this, for example:
> 
>> : 4
>> : [has problem the second time]
>> : GNU Emacs 26.2 (build 1, x86_64-apple-darwin15.6.0, X toolkit)
>> : of 2019-03-21
> 
> I'm asking what exactly does "second time" mean here.  Did you start
> this version of Emacs twice, or did you start it only once and
> performed the steps b-f above twice one after the other in the same
> Emacs session?

Emacs was started 7-times and a-f steps performed in each once.


>>>>> What happens if you set interprogram-cut-function and
>>>>> interprogram-paste-function to nil?
>>>> 
>>>> Will do the next time I get a chance.
>>> 
>>> If I'm right, the problem will disappear.
>> 
>> I am inside the one Emacs's copy and paste, and not going out of the Emacs.
> 
> I don't think I understand what this alludes to.  Is it a response to
> my sentence that starts with "If I'm right"?

I was focusing on `interprogram-cut/paste` and drawing from that Emacs and other programs-inter-cutting-and-pasting with the clipboard. I wanted to make certain to you that no other cut/paste operation happened outside of Emacs for the duration of a-f steps.

The response to "If I'm right" can't be confirmed until I clean slate test with the same conditions observed.

>>>>> (And why do your symlink targets include \200 characters?)
>>>> 
>>>> I used `C-x 8 RET horizontal ellipsis` the email program was unable to process.
>>>> The \200 was what the email program used as substitute.
>>> 
>>> Strange email program: \200 is an unassigned codepoint.
>> 
>> That was the emacs-bug-report mechanism in Emacs that did that.
> 
> If you sent the report via mailclient, then this is probably the same
> problem which causes the issue with pasting that we are discussing.

The mailclient was Emacs's. It offered a menu for processing the problematic characters.

The pasting problem we are discussing is failure to paste what was selected and insertion of an ealier copy from Emacs to the clipboard.

Hope that helps.

bug#34969: 26.2; `emacs -Q` unable to copy \200's eight-bit detail buffer

[Eli Zaretskii]

> From: Van L <van@scratch.space>
> Date: Wed, 27 Mar 2019 09:08:40 +1100
> Cc: 34969@debbugs.gnu.org
> 
> >>> Section A just gives a single sequence, but it doesn't tell how to do
> >>> that several times, i.e. what exactly is repeated N times.
> >> 
> >> a. run Emacs
> >> b. goto *scratch* buffer
> >> c. create new frame
> >> d. lookup keybindings for *scratch* buffer
> >> e. find `self`
> >> f. for the two variants of \200 copy and paste details buffer to *scratch*
> >> 
> >> Repeat the above a-f steps 7 times as listed in the bug-report for those platforms detailed.
> > 
> > We are miscommunicating, I think.  Each one of the 7 instances in your
> > report says something like this, for example:
> > 
> >> : 4
> >> : [has problem the second time]
> >> : GNU Emacs 26.2 (build 1, x86_64-apple-darwin15.6.0, X toolkit)
> >> : of 2019-03-21
> > 
> > I'm asking what exactly does "second time" mean here.  Did you start
> > this version of Emacs twice, or did you start it only once and
> > performed the steps b-f above twice one after the other in the same
> > Emacs session?
> 
> Emacs was started 7-times and a-f steps performed in each once.

Then what does "the second time above" mean?

bug#34969: 26.2; `emacs -Q` unable to copy \200's eight-bit detail buffer

[Van L]

> Eli Zaretskii wrote:
> 
>> Emacs was started 7-times and a-f steps performed in each once.
> 
> Then what does "the second time above" mean?

The meaning is the `2nd run of v26.2: emacs` performing 
a-f steps within the new single instance isolated session.

: 1 -- 1st run of v26.2: emacs
: [has *no* problem the 1st run]
: GNU Emacs 26.2 (build 1, x86_64-apple-darwin15.6.0, X toolkit)
: of 2019-03-21

: 4 -- 2nd run of v26.2: emacs <<-- SEE HERE <<--
: [has problem the 2nd run]
: GNU Emacs 26.2 (build 1, x86_64-apple-darwin15.6.0, X toolkit)
: of 2019-03-21

: 6 -- 3rd run of v26.2: emacs
: [has problem the 3rd run]
: GNU Emacs 26.2 (build 1, x86_64-apple-darwin15.6.0, X toolkit)
: of 2019-03-21

: 7 -- 4th run of v26.2; but this is 1st run as: `emacs -Q`
: [has problem the 4th run]
: GNU Emacs 26.2 (build 1, x86_64-apple-darwin15.6.0, X toolkit)
: of 2019-03-21

bug#34969: 26.2; `emacs -Q` unable to copy \200's eight-bit detail buffer

[Eli Zaretskii]

> From: Van L <van@scratch.space>
> Date: Wed, 27 Mar 2019 16:23:08 +1100
> Cc: 34969@debbugs.gnu.org
> 
> 
> > Eli Zaretskii wrote:
> > 
> >> Emacs was started 7-times and a-f steps performed in each once.
> > 
> > Then what does "the second time above" mean?
> 
> The meaning is the `2nd run of v26.2: emacs` performing 
> a-f steps within the new single instance isolated session.
> 
> : 1 -- 1st run of v26.2: emacs
> : [has *no* problem the 1st run]
> : GNU Emacs 26.2 (build 1, x86_64-apple-darwin15.6.0, X toolkit)
> : of 2019-03-21
> 
> : 4 -- 2nd run of v26.2: emacs <<-- SEE HERE <<--
> : [has problem the 2nd run]
> : GNU Emacs 26.2 (build 1, x86_64-apple-darwin15.6.0, X toolkit)
> : of 2019-03-21

OK, so my initial understanding was correct: you restarted Emacs for
each run.  Then my first suspect would indeed be some software
installed on your system that does something to clipboard contents.

bug#34969: 26.2; `emacs -Q` unable to copy \200's eight-bit detail buffer

[Van L]

> Eli Zaretskii writes:
> 
> Then my first suspect would indeed be some software
> installed on your system that does something to clipboard contents.

I wouldn't make such a fuss of it if copy-and-paste is fundamentally unreliable. Not a bug? but a suspected opabinia.

bug#34969: 26.2; `emacs -Q` unable to copy \200's eight-bit detail buffer

[Van L]

[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]


> Eli Zaretskii writes:
> 
> What happens if you set interprogram-cut-function and
> interprogram-paste-function to nil?

-- running with .emacs at remote X11
GNU Emacs 26.1 (build 1, x86_64--netbsd, X toolkit, Xaw3d scroll bars)
 of 2019-03-27

: (setq interprogram-cut-function nil)
: (setq interprogram-paste-function nil)

Setting the above allows the 2nd copy of \200 to paste correctly after it misfires and pastes the 1st copy, unexpectedly.

Once the misfire occurs the XQuartz app fails to seamlessly copy/paste from X11 environment to this Mail app, for example. 

Calling copy from the app's toolbar menu will allow copy/paste correctly.

[before the above, I had run 26.2 with[&]without .emacs on local X11, and the same to the Mac Port; but the bug never surfaced in those 6 runs ]

-- no problem
run 1 - 26.2 with .emacs
run 2 - 26.2 without .emacs
run 3 - 26.2 with .emacs
run 4 - 26.2 without .emacs
run 5 - 26.1.92 Mac Port tagged 26.2 with .emacs
run 6 - 26.1.92 Mac Port tagged 26.2 without .emacs

-- has problem corrected by interprogram-cut/paste-function set to nil
run 7 - 26.1 with .emacs at remote X11
run 8 - 26.1 without .emacs at remote X11


[-- Attachment #2: example--scratch-buffer--raw-text --]
[-- Type: application/octet-stream, Size: 2268 bytes --]

bug#34969: 26.2; `emacs -Q` unable to copy \200's eight-bit detail buffer

[Eli Zaretskii]

> From: Van L <van@scratch.space>
> Date: Sun, 31 Mar 2019 12:02:25 +1100
> Cc: 34969@debbugs.gnu.org
> 
> > What happens if you set interprogram-cut-function and
> > interprogram-paste-function to nil?
> 
> -- running with .emacs at remote X11
> GNU Emacs 26.1 (build 1, x86_64--netbsd, X toolkit, Xaw3d scroll bars)
>  of 2019-03-27
> 
> : (setq interprogram-cut-function nil)
> : (setq interprogram-paste-function nil)
> 
> Setting the above allows the 2nd copy of \200 to paste correctly after it misfires and pastes the 1st copy, unexpectedly.

This confirms my theory that the problem is somehow related to
clipboard operations.  Someone more knowledgeable in Mac and *BSD
systems will have to chime in to investigate further, if you cannot
find which part of your system is responsible for this, and what
exactly is the problem.

> Once the misfire occurs the XQuartz app fails to seamlessly copy/paste from X11 environment to this Mail app, for example. 
> 
> Calling copy from the app's toolbar menu will allow copy/paste correctly.

I think this just further confirms my theory.

Thanks.

bug#34969: 26.2; `emacs -Q` unable to copy \200's eight-bit detail buffer

[Van L]

> Eli Zaretskii writes:
> 
> if you cannot
> find which part of your system is responsible for this, and what
> exactly is the problem.

If it is fairly certain the bug is outside Emacs then it is irrelevant and the bug can close.

bug#34969: 26.2; `emacs -Q` unable to copy \200's eight-bit detail buffer

[Eli Zaretskii]

> From: Van L <van@scratch.space>
> Date: Mon, 1 Apr 2019 12:01:14 +1100
> Cc: 34969@debbugs.gnu.org
> 
> > Eli Zaretskii writes:
> > 
> > if you cannot
> > find which part of your system is responsible for this, and what
> > exactly is the problem.
> 
> If it is fairly certain the bug is outside Emacs then it is irrelevant and the bug can close.

That's true, but I still have hope someone will chime in and tell more
about this, because even if some external software triggers this bug,
we might still be able to do something in Emacs to prevent or
alleviate that.

bug#34969: 26.2; `emacs -Q` unable to copy \200's eight-bit detail buffer

[Van L]

> Eli Zaretskii writes:
> 
> [ ...] I still have hope someone will chime in and tell more
> about this, because even if some external software triggers this bug,
> we might still be able to do something in Emacs to prevent or
> alleviate that.

Japan is in a frenzy testing the next gengo Reiwa period this month.
The opportunity is there to include this test case, as part of that.

bug#34969: [macOS, external clipboard manager?] can't copy \200's eight-bit detail buffer

[Lars Ingebrigtsen]

Van L <van@scratch.space> writes:

>> if you cannot
>> find which part of your system is responsible for this, and what
>> exactly is the problem.
>
> If it is fairly certain the bug is outside Emacs then it is irrelevant
> and the bug can close.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Skimming this bug report, Van's conclusion here seems to be the most
likely one, so I'm therefore closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no