From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: New Package for NonGNU-ELPA: clojure-ts-mode Date: Mon, 28 Aug 2023 15:17:20 +0300 Message-ID: <83jztficof.fsf@gnu.org> References: <87il9kksqz.fsf@dfreeman.email> <87wmy080kn.fsf@posteo.net> <83v8djcydl.fsf@gnu.org> <87350ndquw.fsf@dfreeman.email> <83350ncbns.fsf@gnu.org> <87cyzrjbd8.fsf@dfreeman.email> <83zg2vav46.fsf@gnu.org> <87o7j99304.fsf@dfreeman.email> <87wmxj27fn.fsf@dfreeman.email> <831qfrptiq.fsf@gnu.org> <57429221-d9be-5791-e975-b3539905e2f6@gutov.dev> <83a5udlj47.fsf@gnu.org> <87a5udk1co.fsf@posteo.net> <835y51kslv.fsf@gnu.org> <7a82c524-1aa1-e755-e377-673ebb107a44@gutov.dev> <83r0nok8s4.fsf@gnu.org> <83ledwk4xi.fsf@gnu.org> <76ecf629-a41a-f6e4-f661-2ef926326d6c@gutov.dev> <65b81809-9c18-6bd4-4944-7d1085c9db17@gutov.dev> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10467"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com, emacs-devel@gnu.org, manuel.uberti@inventati.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 28 14:18:34 2023 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 1qabCU-0002Xk-Fi for ged-emacs-devel@m.gmane-mx.org; Mon, 28 Aug 2023 14:18:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qabBr-0006xv-VA; Mon, 28 Aug 2023 08:17:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qabBl-0006xh-Bw for emacs-devel@gnu.org; Mon, 28 Aug 2023 08:17:50 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qabBi-0005DR-JP; Mon, 28 Aug 2023 08:17:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=zu/HRlTbfTJP/QT3zfuMl7+J4hOvCGQvksUogQv/iXs=; b=CDt5uOARLE/T Hs0XgGcHFUDAsFxgJENAFK4w3chvkcQZD0Jf9q4eH+0lwNaHrllm8WYRNWFoMsaTCR5yivMA5RApm oBN4qIdq4zoeONJCg4oKUroeB0ABOTiw1vtytXstKIG/PcglqgtFQ7TXSKwbV+f+1ZdQA2HsHyMHq ZqO6M4QTKDuSbZH23ZDijLSu++qOc3Nb2l3G543EE5WY55WNYnH9O2xj7Y1oA9jVN5D0zmN4K5Z2F UgqXgSmuJlrG/rgV64c53ycbuX4GccOnjBtHRvaSf5rupBDD1USjeVtpejoNEEkvF4XAmg7NLRyry 5DqCv10nZEk05yRBN/6Y4g==; In-Reply-To: <65b81809-9c18-6bd4-4944-7d1085c9db17@gutov.dev> (message from Dmitry Gutov on Mon, 28 Aug 2023 03:38:45 +0300) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:309429 Archived-At: > Date: Mon, 28 Aug 2023 03:38:45 +0300 > Cc: Eli Zaretskii , philipk@posteo.net, danny@dfreeman.email, > stefankangas@gmail.com, emacs-devel@gnu.org, manuel.uberti@inventati.org > From: Dmitry Gutov > > On 28/08/2023 03:21, Po Lu wrote: > > Dmitry Gutov writes: > > > >> Yeah, a program written in C/C++/Rust which contains an interpreter > >> (and multiple jit's) for a dynamic programming language and has most > >> of its interface written in it, supports user extensions in the same > >> language, support display of arbitrary files and has several related > >> but different mechanisms for guiding the visuals and the layout of > >> said display. It also supports bidi. > > > > Using Bidi implementations which already exist, implementing standards > > already specified, and applying foreknowledge acquired through the > > development of other implementations of those standards, correct? > > Something that we'd happily do as well, wouldn't we? We do that always when the library fits the bill. But in many cases it doesn't (or a library doesn't yet exist), because Emacs has some unique requirements. > > The scale and rapid development that is mandatory for a functioning web > > browser sounds impressive, but is ultimately narrow in scope. Emacs's > > requirements are less imposing but greater in number, > > ... > > > which compounded > > by a group of active developers whose number pales in comparison to that > > of Firefox, means that reducing the strain on any one of them is an > > overriding objective. > > Even if that were the case, the plan breaks as soon as we run out of > existing active developers, if we fail to recruit enough new ones. That's true, but the single most important lesson we learn from the history of GNU Emacs is that this danger never actually materialized. Which doesn't mean we should not try to recruit more, of course, it just means that we shouldn't be too pessimist about this.