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: An anonymous IRC user's opinion Date: Wed, 09 Oct 2024 16:13:58 +0300 Message-ID: <865xq14dwp.fsf@gnu.org> References: <87plodsjsd.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33472"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Johan =?utf-8?Q?Myr=C3=A9en?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 09 15:14:45 2024 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 1syWWa-0008SP-HL for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Oct 2024 15:14:44 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1syWVv-0004eg-5u; Wed, 09 Oct 2024 09:14:03 -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 1syWVt-0004df-C7 for emacs-devel@gnu.org; Wed, 09 Oct 2024 09:14:01 -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 1syWVt-0001aE-4C; Wed, 09 Oct 2024 09:14:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=T7/gxE5/Lmc2olAff5rpREUI56YNHhzYsmD2lc4IeMA=; b=rE47qftp/abMGr0yxxyL fFDj892aWzdMiN/QF/pYG/aZJKD/R7uMC0VfZLfr/ASLBLESnkGqmKLHvWIQo6qFEtqtzI8lKfBN5 UDKQt1HMnQAGVQw2EnHFS5ZLFoMO3RlsJmEzKckQ3D3/Z7VR3tDEJNxnOkM7hiv7wlHzF9jRCxTaY yZ+T3c9zk+3HhZhoxo01HRJ0YyAyGq1zC4kfJDlJ1aTCZVYctNAvlxtY0vFPJJKz1+6Xc+xXfaqNY KVOkL9y1ImZxV4/3vYXioKRo/au7i8cVZRUqT6KHQ4Ca7R9BGM2rF2fkaLZzfdjXVZ98CZpTK2Y0P p/kEePMYTIkqbA==; In-Reply-To: (message from Johan =?utf-8?Q?Myr=C3=A9en?= on Wed, 9 Oct 2024 14:09:13 +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:324439 Archived-At: > From: Johan Myréen > Date: Wed, 9 Oct 2024 14:09:13 +0300 > > I see this more as a documentation problem. Emacs lacks "official" documentation on how to configure an > environment to do certain things, which includes installing certain Elisp packages, and configuring them. My analysis is different. Emacs lacks volunteers who'd sit down and write documentation on how to configure Emacs for this or that job. Once that is written, and written well, admitting it into Emacs is usually a no-brainer. Mind you: the above is an extremely non-trivial job, because the sheer number of possible "jobs" which Emacs can support is mind-boggling. Even if someone describes in excruciating detail how to configure Emacs for Rust development, that only helps people who need to develop programs in Rust, but doesn't help at all to, say, someone who needs to write a thesis about some academic subject, or read email from Gmail or even develop C++ programs, or... > In the good old days software development meant editing a few C files in Emacs and then running make. > This no longer meets the expectations people have of a software development environment. For example, > creating a contemporary environment to write and build software using the Rust programming language and > Emacs, you need Rust mode, rust-ts-mode for Treesitter integration, Eglot to communicate with > rust-analyzer (a Language Server implementation for Rust) for completion and goto definition, Company > mode for code completion, Magit for version control, DAP mode for debugging, and so on. Many of these > packages have alternative implementations, for example rustic-mode instead of rust-mode. This is an exaggeration to some degree. rust-ts-mode is part of Emacs, and could be turned on automatically when a Rust file is visited; we didn't do that because we are unsure whether users of an unbundled Rust mode will protest. Eglot is part of Emacs, but it cannot be started automatically because the LSP server, which is a separate piece of software, needs to be installed and configured first; are we supposed to be held responsible for that as well? We do have TAGS support for Rust (goto definition etc., so alternative to LSP), and the new etags-regen-mode might just make the job of using TAGS much easier and seamless. Magit is nice, but not really necessary, since we have VC built in, which doesn't need to be configured. DAP is not necessary, since Emacs has a GDB front-end (which doesn't need to be configured, just invoked with a single command), and GDB supports debugging Rust programs. So things are not that bad, are they? I do agree that good tutorials which would mention all this stuff would make things better, at least for those who read documentation (how many do?), but that needs volunteers to sit down and write that up. Would you please consider doing something like that for some jobs with which you are familiar? > I'm not saying you can't edit Rust code without all these packages, but these packages combined provide > the minimum that the competition (e.g. Visual Studio Code) offers. I'm guessing VSCode comes with pre-configured LSP servers, a single Rust mode, and a single Git interface. Am I mistaken? If so, is that how we want to treat our users? will they agree to be treated like that?