From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: M-w, then C-y. C-y inserts text properties that aren't on original. Date: Mon, 22 Feb 2010 12:56:35 +0000 Message-ID: <20100222125635.GA2631@muc.de> References: <20100218202902.GE2671@muc.de> <838wapy3yo.fsf@gnu.org> <20100219122419.GA918@muc.de> <20100219143513.GC918@muc.de> <83r5ogwa8g.fsf@gnu.org> <83pr40w96f.fsf@gnu.org> <20100221215951.GD4407@muc.de> <838walx61v.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1266845439 2411 80.91.229.12 (22 Feb 2010 13:30:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 22 Feb 2010 13:30:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 22 14:30:35 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NjXj4-0003SV-Eq for ged-emacs-devel@m.gmane.org; Mon, 22 Feb 2010 13:49:26 +0100 Original-Received: from localhost ([127.0.0.1]:41153 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NjXj4-0003uF-2I for ged-emacs-devel@m.gmane.org; Mon, 22 Feb 2010 07:49:26 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NjXiy-0003u9-G4 for emacs-devel@gnu.org; Mon, 22 Feb 2010 07:49:20 -0500 Original-Received: from [140.186.70.92] (port=43937 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NjXix-0003tz-F8 for emacs-devel@gnu.org; Mon, 22 Feb 2010 07:49:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NjXis-0002r1-7n for emacs-devel@gnu.org; Mon, 22 Feb 2010 07:49:19 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:4603 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NjXir-0002qr-SN for emacs-devel@gnu.org; Mon, 22 Feb 2010 07:49:14 -0500 Original-Received: (qmail 84204 invoked by uid 3782); 22 Feb 2010 12:49:12 -0000 Original-Received: from acm.muc.de (pD9E23E30.dip.t-dialin.net [217.226.62.48]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Mon, 22 Feb 2010 13:49:11 +0100 Original-Received: (qmail 3294 invoked by uid 1000); 22 Feb 2010 12:56:35 -0000 Content-Disposition: inline In-Reply-To: <838walx61v.fsf@gnu.org> User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 4.6-4.9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:121280 Archived-At: Hi, Eli, On Mon, Feb 22, 2010 at 06:12:12AM +0200, Eli Zaretskii wrote: > > Date: Sun, 21 Feb 2010 21:59:51 +0000 > > Cc: emacs-devel@gnu.org > > From: Alan Mackenzie > > > Here's one idea: make a deep search through the properties of the > > > value of the `category' property, looking for any of the properties > > > in `yank-excluded-properties'. If found, do the replacement we do > > > now. > > I'm not in favour of anything like this. > > The way the current replacement works, it replaces category > > properties with "hard" properties. These "hard" properties then foul > > up future category properties, should you apply a different category, > > or change the properties on the category symbol. > > As Richard said back in 2002, it's a difficult problem to fix, > > because there's no general or canonical case. I think a better way > > would have been simply to drop category properties. But we've got > > what we've got, so why not just stick with it? > I thought you wanted to fix the original problem, didn't you? So I > suggested one way of having it fixed. If we leave things as they are, > the problem you are having will stay as well, no? I was wanting both to fix "my" problem and fix the ostensible bug which was messing up the text properties. I've decided to fix the CC Mode problem by ad hoc means, rather than try to push through a quite big change to TP handling. It means that certain characters in a C++ Mode buffer will get text properties of (risky-local-variable t), but that won't harm anything and will serve as a reminder of the ridiculousness of life, the universe, and everything. Do you think that the idea you suggest (above) would be better than the current way? I dislike it because it looks more complicated, and I think it would be as least as difficult to code round as the current way. -- Alan Mackenzie (Nuremberg, Germany).