From: "Chong Yidong" <cyd@stupidchicken.com>
Subject: Re: copying to clipboard silently discards lines
Date: Fri, 25 Feb 2005 10:09:14 -0500 (EST) [thread overview]
Message-ID: <1156.220.255.172.231.1109344154.squirrel@www.stupidchicken.com> (raw)
In-Reply-To: <1515.220.255.172.231.1109259901.squirrel@220.255.172.231>
I sent an email to emacs-pretest-bug earlier about NTEmacs silently
discarding lines copied onto the clipboard. I've identified the problem,
but I don't know enough about coding systems to come up with a fix. Maybe
someone can help me out here.
The bug is in the Lisp_Object QUNICODE, which specifies the "utf-16le-dos"
coding system used by `selection-coding-system'. When a coding_system is
extracted from QUNICODE, the parameter
coding->spec.ccl.encoder.buf_magnification is 1. This causes a call to
encoding_buffer_size (in convert_to_handle_as_coded, w32select.c:247) to
return a buffer size that is too small for the encoded string.
I'm guessing the magnification has to be set to 2, because `abc...' gets
encoded to `a\0b\0c\0...' (encoding_buffer_size multiplies this again by
2, because of the CRLF issue.)
This bug did not exist prior to the unicode support patch, because Emacs
used the iso2022 coding system for selections.
Trouble is, I can't find where the `spec.ccl...', or indeed any of the
other parameters of QUNICODE are initialized. The only place I can see
that sets anything in QUNICODE is w32select.c:1074, which is just
QUNICODE = intern ("utf-16le-dos");
Could someone with knowledge of coding systems and/or w32select.c help?
next parent reply other threads:[~2005-02-25 15:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2150.220.255.172.231.1109220271.squirrel@220.255.172.231>
[not found] ` <1515.220.255.172.231.1109259901.squirrel@220.255.172.231>
2005-02-25 15:09 ` Chong Yidong [this message]
2005-02-25 17:24 ` copying to clipboard silently discards lines Benjamin Riefenstahl
2005-02-26 2:53 ` Chong Yidong
2005-02-28 7:20 ` Kenichi Handa
2005-02-28 19:13 ` Benjamin Riefenstahl
2005-03-08 9:10 ` Kenichi Handa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1156.220.255.172.231.1109344154.squirrel@www.stupidchicken.com \
--to=cyd@stupidchicken.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).