From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: evaluating numbers Date: Sat, 09 Nov 2019 09:22:08 +0200 Message-ID: <83o8xla50f.fsf@gnu.org> References: <875zjw2emg.fsf@gmx.net> <618B38D9-CD34-4200-8CA1-1A6B0922A83A@traduction-libre.org> <871ruk2d3f.fsf@gmx.net> <3C929D7B-1C10-4713-9EDA-55C80FC36AD8@traduction-libre.org> <835zjvg385.fsf@gnu.org> <83sgmyd6rw.fsf@gnu.org> <835zjucwbz.fsf@gnu.org> <628A3663-BDD3-47C5-B4F4-E260FD900691@traduction-libre.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="215212"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Jean-Christophe Helary Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 09 08:22:26 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iTL4k-000trK-EJ for ged-emacs-devel@m.gmane.org; Sat, 09 Nov 2019 08:22:26 +0100 Original-Received: from localhost ([::1]:35184 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iTL4i-0001gp-Ee for ged-emacs-devel@m.gmane.org; Sat, 09 Nov 2019 02:22:24 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34439) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iTL4b-0001fS-PS for emacs-devel@gnu.org; Sat, 09 Nov 2019 02:22:18 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36316) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iTL4a-0007ol-VG; Sat, 09 Nov 2019 02:22:17 -0500 Original-Received: from [176.228.60.248] (port=4354 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iTL4a-0005kE-81; Sat, 09 Nov 2019 02:22:16 -0500 In-reply-to: <628A3663-BDD3-47C5-B4F4-E260FD900691@traduction-libre.org> (message from Jean-Christophe Helary on Sat, 9 Nov 2019 09:15:30 +0900) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.org gmane.emacs.devel:242029 Archived-At: > From: Jean-Christophe Helary > Date: Sat, 9 Nov 2019 09:15:30 +0900 > > > M-: (char-after) RET > > But that doesn't work for non-ascii characters. Hence my previous question about the relative importance of "e" vs "é" for ex. Yes, and we have just made a full circle. Users who want this to work for any character should customize eval-expression-print-maximum-character to a suitable value. The current default is a compromise, which is still tremendously useful because at least IME examining ASCII characters is a very frequent use case. AFAIR we had a long discussion back when this option was introduced and its default set to 127, and this is the compromise we have reached. If you don't like the default, you can have a different value that satisfies you. But I see no reason to continue questioning the default any further. > If we have a function like (char-after) that is defined as "Return(ing) character in current buffer at position POS." then it should do that for all the characters defined in the emacs supported character set, shouldn't it? Characters are just integers in Emacs. > I'm fine with integers evaluation displaying only number values by the way. But maybe (char-after) and similar functions should use a different value for eval-expression-print-maximum-character. Feel free to file a feature-request bug report about this. > Is there a general policy to just mention/define variables and not give default values in the manual ? No.