From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tomas Hlavaty Newsgroups: gmane.emacs.devel Subject: Re: Internationalize Emacs's messages (swahili) Date: Mon, 28 Dec 2020 01:33:47 +0100 Message-ID: <87v9cmojkk.fsf@logand.com> References: <87o8ivumn5.fsf@telefonica.net> <83h7o8ncly.fsf@gnu.org> <87pn2wudab.fsf@db48x.net> <87mty0c3m1.fsf@gnus.org> <83czywnb86.fsf@gnu.org> <87im8ob707.fsf@gnus.org> <87eejcb6nx.fsf@gnus.org> <875z4ob5c9.fsf@gnus.org> <87a6u09nkq.fsf@gnus.org> <875z4o9jdg.fsf@gnus.org> <87r1nb8yoj.fsf@gnus.org> <83blefkte2.fsf@gnu.org> <87h7o69aa8.fsf@gnus.org> <87pn2uq3ty.fsf@logand.com> <87ft3qq2kz.fsf@logand.com> <874kk6pzod.fsf@logand.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13980"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org, eliz@gnu.org, monnier@iro.umontreal.ca To: "Alfred M. Szmidt" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 28 01:35:00 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ktgV2-0003UE-LQ for ged-emacs-devel@m.gmane-mx.org; Mon, 28 Dec 2020 01:35:00 +0100 Original-Received: from localhost ([::1]:42726 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ktgV1-0002TZ-Ns for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Dec 2020 19:34:59 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55654) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktgTx-00021i-Nt for emacs-devel@gnu.org; Sun, 27 Dec 2020 19:33:57 -0500 Original-Received: from logand.com ([37.48.87.44]:60550) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ktgTv-0001Ci-RX; Sun, 27 Dec 2020 19:33:53 -0500 Original-Received: by logand.com (Postfix, from userid 1001) id 5F22319F689; Mon, 28 Dec 2020 01:33:49 +0100 (CET) X-Mailer: emacs 26.3 (via feedmail 11-beta-1 I) In-Reply-To: Received-SPF: pass client-ip=37.48.87.44; envelope-from=tom@logand.com; helo=logand.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:261965 Archived-At: On Sun 27 Dec 2020 at 19:16, "Alfred M. Szmidt" wrote: > It is fascinating how many people with strong opinions do not > understand the problem with > > (> (length x) 2) > > You are assuming that X is always a list, I am not. > there are far more types than that in Emacs Lisp. Replacing every > instance of (PREDIATE (length ...)) with (lengthPREDICATE ...) doesn't > really do anything at all for the cases where we are not working with > a list -- which you cannot possibly know just from a grep of the code. I do not need to know. I know that after the change, the good cases will stay good and the bad cases will be improved. > And if they fail at that, someone can once in a while fix that > easily by search, replace and visual review without introducing > bugs. > > But nothing is fixed by such a change, thats the whole point, if you > are working with strings you are not fixing anything! You are > introducing a gratious change that does absolutely nothing. It is the first step towards improvement. > > The two functions are advertised as equal as well, so there is no > > possible way for the user to know which one to use when, and it > > might be suprising that the behaviour (in run time) is different. > > Which two functions are advertised as equal? > > Should have written forms, length> and (> (length ...), and the other > variants. They compute the same thing differently. Like these two forms compute the same thing differently: (progn 1) vs (progn (sleep 10) 1) > > And is it just me, but I'd expect that length>, etc takes two or > > more sequences and returns a boolean if one of sequence is > > larger/smaller/equal/... > > Would not that be better called sequence>? > > What does "sequence is larger/smaller/equal" mean exactly? > > (> 6 5 4 3 2 1) --> t > (length> '(1 2 3 4) '(1 2 3) '(1 2) '(1)) --> t or even (I already mentioned that earlier): (length> 5 '(1 2 3 4) '(1 2 3) 2.33 '(1 2) '(1) -42) --> t But this is not so important. A simple two arg function would help to fix most or all of the bad cases. Ultimately, the person who implements this will decide.