From: Karl Chen <quarl@hkn.eecs.berkeley.edu>
Cc: emacs-devel@gnu.org
Subject: Re: [cvs] bug when using pc-selection-mode/transient-mark-mode
Date: Fri, 20 Sep 2002 19:38:12 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.44.0209201051170.24069-100000@hkn.eecs.berkeley.edu> (raw)
In-Reply-To: <E17sEjB-00085B-00@fencepost.gnu.org>
> In the C code there are just two places that deactivate the mark:
>
> editfns.c:802: current_buffer->mark_active = tem;
> keyboard.c:1755: current_buffer->mark_active = Qnil;
>
> Once you are at that point, could you try enabling breakpoints at
> those two places and see if they go off?
It wasn't easy because the part in keyboard.c:1755 gets called whenever
deactivate-mark is non-nil, which is set in multiple places.
The ultimate source of deactivate-mark getting set is insdel.c:1967
prepare_to_modify_buffer() {
...
Vdeactivate_mark = Qt; // line 1967
}
So the bug indeed has to do with x-own-selection and sit-for (non-nil
post-command-idle-hook). Emacs will get X selection events and in
sit_for (sec=0, ...) will call
swallow_events() which will call
x_handle_selection_request() which will call
x_get_local_selection()
which will go through selection-converter-alist and end up calling
(xselect-convert-to-string ...) which will call
(encode-coding-string ...)
code_convert_string1()
encode_coding_string()
run_pre_post_conversion_on_str() <---
(erase-buffer /* buffer = "*code-converting-work*" */ )
del_range()
del_range_1()
prepare_to_modify_buffer()
I'm giving you all this backtracing because I'm not sure where to fix the
bug. I can comment out insdel.c:1967 and it will go away but that was
probably there for a reason.
My best guess is that when run_pre_post_conversion_on_str() calls
buffer modification functions such as (erase-buffer) and
insert_from_string() on its temporary buffer, it doesn't mean to set the
global deactivate-mark.
This patch fixes the problem.
--- coding.c.~1.257.~ 2002-09-07 21:30:13.000000000 -0700
+++ coding.c 2002-09-20 19:19:31.000000000 -0700
@@ -5819,6 +5819,7 @@
int multibyte = STRING_MULTIBYTE (str);
Lisp_Object buffer;
struct buffer *buf;
+ Lisp_Object old_deactivate_mark = Vdeactivate_mark;
record_unwind_protect (Fset_buffer, Fcurrent_buffer ());
record_unwind_protect (code_convert_region_unwind, Qnil);
@@ -5854,6 +5855,9 @@
}
inhibit_pre_post_conversion = 0;
str = make_buffer_string (BEG, Z, 1);
+
+ Vdeactivate_mark = old_deactivate_mark;
+
return unbind_to (count, str);
}
---
I haven't looked yet in cvs what change was responsible for the behavior
manifesting.
HOWEVER, this is an ugly hack and I've noticed a lot of similar "save
deactivate_mark; do crap; restore deactivate_mark" code in Emacs. It just
smells of bad design when global variables have to be pushed and popped
all the time and someone calling a function needs to know which variables
to push/pop, especially when this is not documented. Some ideas for a
more elegant (i.e. a lot more troublesome to implement) solution:
- per-buffer `deactivate-mark' variable.
- maybe prepare_to_modify_buffer doesn't need to set deactivate-mark
(probably does need to).
- a "temporary buffer" status for buffers that are such. Could be either
passed to get-buffer-create or set as a buffer-local variable.
- notice whether the buffer being modified by in prepare_to_MB is the
"active" one (current buffer? or any visible buffer) that the user has
a selection in (and if not assume it's a temporary buffer)
In the meantime there should be a documented warning to emacs developers
that whenever they create and manipulate temporary buffers that they have
to save the deactivate-mark variable.
--
Karl Chen / quarl@quarl.org
next prev parent reply other threads:[~2002-09-21 2:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-16 5:55 [cvs] bug when using pc-selection-mode/transient-mark-mode Karl Chen
2002-09-16 19:27 ` Richard Stallman
2002-09-18 0:07 ` Karl Chen
2002-09-18 17:26 ` Richard Stallman
2002-09-19 7:11 ` Karl Chen
2002-09-19 8:00 ` Karl Chen
2002-09-19 8:48 ` Karl Chen
2002-09-20 3:45 ` Richard Stallman
2002-09-21 2:38 ` Karl Chen [this message]
2002-09-21 19:39 ` Richard Stallman
2002-09-22 22:48 ` Stefan Monnier
2002-09-23 1:05 ` Karl Chen
2002-09-23 1:18 ` Miles Bader
2002-09-23 1:25 ` Miles Bader
2002-09-23 18:31 ` Stefan Monnier
2002-09-23 20:34 ` Kim F. Storm
2002-09-24 3:24 ` Richard Stallman
2002-09-23 16:00 ` Richard Stallman
2002-09-23 20:38 ` Kim F. Storm
2002-09-19 19:52 ` Karl Chen
2002-09-20 18:42 ` Richard Stallman
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.44.0209201051170.24069-100000@hkn.eecs.berkeley.edu \
--to=quarl@hkn.eecs.berkeley.edu \
--cc=emacs-devel@gnu.org \
--cc=q.edg875310@quarl.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.