From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: problems on inline input on Mac Date: Sat, 29 Jul 2006 12:27:39 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <20060728.125820.34684979.kazu@iij.ad.jp> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: sea.gmane.org 1154143686 16616 80.91.229.2 (29 Jul 2006 03:28:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 29 Jul 2006 03:28:06 +0000 (UTC) Cc: "Kazu Yamamoto \(=?utf-8?B?5bGx5pys5ZKM5b2m?=\)" , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 29 05:28:01 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1G6fUe-0003tW-4O for ged-emacs-devel@m.gmane.org; Sat, 29 Jul 2006 05:28:00 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G6fUd-0002KG-H9 for ged-emacs-devel@m.gmane.org; Fri, 28 Jul 2006 23:27:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G6fUS-0002KB-MR for emacs-devel@gnu.org; Fri, 28 Jul 2006 23:27:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G6fUQ-0002Jq-2h for emacs-devel@gnu.org; Fri, 28 Jul 2006 23:27:47 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G6fUP-0002Jn-SJ for emacs-devel@gnu.org; Fri, 28 Jul 2006 23:27:45 -0400 Original-Received: from [133.82.132.2] (helo=mathmail.math.s.chiba-u.ac.jp) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G6fWX-0003ES-CO for emacs-devel@gnu.org; Fri, 28 Jul 2006 23:29:57 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 283032C87; Sat, 29 Jul 2006 12:27:40 +0900 (JST) Original-To: Stefan Monnier In-Reply-To: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/22.0.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) 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:57768 Archived-At: >>>>> On Fri, 28 Jul 2006 03:23:10 -0400, Stefan Monnier said: >> They are inherited from those just after the (empty) overlay. You >> cannot tell whether the user wants to inherit them from those >> before or after it. > Well, if you assume that the character will be (in the end) inserted > at point, then yes you can, using front-sticky and such kind of > information. Yes, unless further fontification is done after insertion. Because I think the inheritance of face for overlay strings is a task of face merging in the redisplay code, I'm not doing anything special about it in the TSM support code. The redisplay code just behaves like this (i.e., inherit the face just after one marker of the overlay). One idea would be to change the behavior by which property we use, before-string or after-string. If we regard an overlay as a modifier for an interval, it would be natural for before-string (after-string) to respect the face that is attached to the first (last, respectively) character of the interval. Of course, some consideration is needed for special cases such as empty intervals, and it might not be a good time to make such a change. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp