From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: Feature freeze on October 1 Date: Tue, 25 Sep 2012 21:12:41 +0900 Message-ID: <87ehlq9u86.fsf@gnu.org> References: <837griinsy.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1348575193 7928 80.91.229.3 (25 Sep 2012 12:13:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Sep 2012 12:13:13 +0000 (UTC) Cc: cyd@gnu.org, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 25 14:13:16 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TGU0n-0006M3-AT for ged-emacs-devel@m.gmane.org; Tue, 25 Sep 2012 14:13:13 +0200 Original-Received: from localhost ([::1]:47482 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGU0h-00016u-T7 for ged-emacs-devel@m.gmane.org; Tue, 25 Sep 2012 08:13:07 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55482) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGU0f-00016P-65 for emacs-devel@gnu.org; Tue, 25 Sep 2012 08:13:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGU0e-0000sV-75 for emacs-devel@gnu.org; Tue, 25 Sep 2012 08:13:05 -0400 Original-Received: from fencepost.gnu.org ([208.118.235.10]:47597) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGU0e-0000sR-43 for emacs-devel@gnu.org; Tue, 25 Sep 2012 08:13:04 -0400 Original-Received: from 253.240.accsnet.ne.jp ([202.220.240.253]:64470 helo=mongkok) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1TGU0d-0004HV-0Q; Tue, 25 Sep 2012 08:13:03 -0400 In-Reply-To: <837griinsy.fsf@gnu.org> (message from Eli Zaretskii on Tue, 25 Sep 2012 09:06:37 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:153530 Archived-At: In article <837griinsy.fsf@gnu.org>, Eli Zaretskii writes: > Should we also remove MAYBE_UNIFY_CHAR and maybe_unify_char as well? No, they are still used in decode_char. > And what about CHAR_STRING_ADVANCE_NO_UNIFY and > STRING_CHAR_ADVANCE_NO_UNIFY? Should we remove them and use, > respectively, CHAR_STRING_ADVANCE and STRING_CHAR_ADVANCE instead? > Or do we want to leave all these in place for now, to keep > the option of going back to using the unification in some > cases? Ummm, how about doing this in coding.c and don't change the callers. #define CHAR_STRING_ADVANCE_NO_UNIFY CHAR_STRING_ADVANCE #define STRING_CHAR_ADVANCE_NO_UNIFY STRING_CHAR_ADVANCE Then we won't forget that callers expect non-unify versions. --- Kenichi Handa handa@gnu.org