From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ship Mints Newsgroups: gmane.emacs.devel Subject: Re: An anonymous IRC user's opinion Date: Wed, 9 Oct 2024 12:12:50 -0400 Message-ID: References: <87plodsjsd.fsf@web.de> <865xq14dwp.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000040d59606240d87d8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6747"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?UTF-8?Q?Johan_Myr=C3=A9en?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 09 18:13:48 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 1syZJq-0001aD-Rd for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Oct 2024 18:13:47 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1syZJJ-0004z0-Hv; Wed, 09 Oct 2024 12:13:13 -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 1syZJH-0004ts-NL for emacs-devel@gnu.org; Wed, 09 Oct 2024 12:13:11 -0400 Original-Received: from mail-oo1-xc33.google.com ([2607:f8b0:4864:20::c33]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1syZJA-0007TV-CQ for emacs-devel@gnu.org; Wed, 09 Oct 2024 12:13:07 -0400 Original-Received: by mail-oo1-xc33.google.com with SMTP id 006d021491bc7-5e9876999a9so553506eaf.3 for ; Wed, 09 Oct 2024 09:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728490382; x=1729095182; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=sYg8bvFeTsdq1CCaFfrQ+6pkl5rkS+L+HiyNwyof7rs=; b=K55L7WpaPlAc9AZ5lZLjv+xE/mZAQTcVSyRDf5+64TjSKr4g9gGLiRYUE/bcl+JCq/ n4sSQiXh5SzC220kwvOtM5EPGeUJkcrxhWkk8H+jMRSfGXORa9azoryG8BHp+/5NBD7Z P2FxquOOmN6FyxR+n8hQ+8QcvmlVZfHBqgO5II3CsCE7RLpybbSj+ecV7AdMwMK8Sxpt ed/eTrnIma42XbY/2zGZNug8ae5LvdotwUU7sUABzdIm01kEDUz1KBAb3TtDfGZrfbR+ EBIlC7HJYkw8/HU/AwNwHM66vRApA43SybJTMaoTdxAYjvScNZ2FaJRPkxKhbMcSx3Ej b8Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728490382; x=1729095182; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=sYg8bvFeTsdq1CCaFfrQ+6pkl5rkS+L+HiyNwyof7rs=; b=hINpls5fDdMQw8LNWgn6hz3KiiyuwLKO5wBJEuP9/5AFAcxeDWQYy8d+Hrt0QWEZ98 hUw7xpTLdU5Wfrw2LTifCTpiR0KjznT60UK6tTl+IWHpv5qJOgA7JRi+ryrewjNF6c/2 gKlIieq8qQJik20LpSI6pawF3SnLLNazz9iGs6LujFgn+IEJuPWguThjNGRDBYBDSXe+ IJJsRGijZRfVbxzo0mHVcnZ6/6ozRIStZbgjMxA/B4mpk8ugoWXyiWyKssu+nrDDwUcN Y1mwDWqMtYhGLVqiDdYX0Bs/DlshW/5xFj/2tO9bI2t/Qqk3Wk/S/UZryE65s/fRJfWi 25FA== X-Gm-Message-State: AOJu0YxllaWlcOddHmVGdupzFhwHztZyOgsD1gugLwsBYDZme11bAqgh q4D9kZ0BMKjkg7GLBKXSDEoocxlpK3Itr5oq6zTbnfBCnw8oKiLfeviMN+Td5IBiDao8zel/nuj 2nMTMZGhSasKr72tKS2B8/dQSoeyVJA== X-Google-Smtp-Source: AGHT+IH4rtuEDlWTn8pJJdOxZZ+XhnOUv+O3KrYR8qq4ch7HgfIOEWGEqzcBI4l42cpbnTmSoLYaov5x2lzsOm9adSY= X-Received: by 2002:a05:6358:5f02:b0:1bc:57ce:9992 with SMTP id e5c5f4694b2df-1c308121110mr77289555d.15.1728490382609; Wed, 09 Oct 2024 09:13:02 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::c33; envelope-from=shipmints@gmail.com; helo=mail-oo1-xc33.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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.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:324446 Archived-At: --00000000000040d59606240d87d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Speaking of cookbooks, some people prefer packaged food, some prefer cooking. I see Emacs as a platform for those who prefer cooking. Public support via reddit or stackoverflow or the Emacs mailing lists, tends to be friendly and helpful but can't substitute users' own desires to cook for themselves. When VSCode goes wrong, they have to figure stuff out for themselves anyway (it's a fairly buggy ecosystem, in my experience). If they can handle the complexity of the Rust compiler, they can handle the complexity of Emacs. They just have to cook a little. On Wed, Oct 9, 2024 at 12:07=E2=80=AFPM Johan Myr=C3=A9en wrote: > I understand Emacs is a volunteer project and finding good documentation > writers is difficult. I was just suggesting what direction I would like t= o > see Emacs documentation going. Emacs has a good and extensive manual that > provides mostly a great reference to how to use Emacs as an editor. What = I > am proposing is a higher level view, a kind of cookbook on how to do > different things with Emacs. > > I just started my Emacs (from the main branch) with -q and opened a Rust > source file. Emacs out of the box does not even recognize the .rs file > extension: the file is opened in Fundamental mode. A novice Emacs user > might guess that he or she needs to install a Rust mode for Emacs to > recognize we are editing Rust source code. But by only doing this the use= r > is missing out on so much useful functionality Emacs has to offer. How is > the user supposed to know that =C2=A8Eglot" is the way to connect to a la= nguage > server, or that a package named =C2=A8Company" provides completion? The o= nly way > right now is to search for this on the internet, which is associated with > the quality problems I described in my previous message. > > Software has grown more complex during the years Emacs has been in > existence, and so have the expectations of the public using it. Emacs has > fantastic collections of packages, each focusing on different things. Thi= s > is a good modular design. Some of these packages can be used to form, for > example, a working Rust development environment. The problem is finding > these packages. How does a new Emacs user know what to look for? > > So I am proposing a "task-oriented" category in the Emacs documentation. = I > don=C2=B4t think there is such a category. > > Eglot is part of Emacs, but it cannot be started automatically because th= e >> 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 > > > No, all I am talking about is documentation. In fact I really dislike som= e > things that happen by magic, but are undocumented. They typically break > over time, which is a bigger headache to fix than configuring things by > hand using good documentation. > > I'm guessing VSCode comes with pre-configured LSP servers, a single >> Rust mode, and a single Git interface. Am I mistaken? >> > > No, VSCode does not come pre-configured for Rust development. But, there > is a good, task-oriented web page that describes in simple terms what nee= ds > to be installed and configured to start writing Rust code using VSCode. > Similar pages exist for Java, Javascript, C++, C#, Python, Go, etc. More > importantly, this documentation can be found on code.visualstudio.com ( > https://code.visualstudio.com/docs/languages/rust), not on YouTube.com or > robert.kra.hn or some other random website. > > Johan Myr=C3=A9en > > > > > On Wed, 9 Oct 2024 at 16:14, Eli Zaretskii wrote: > >> > From: Johan Myr=C3=A9en >> > 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, bu= t >> 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? >> > --00000000000040d59606240d87d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Speaking of cookbooks, some people prefer packaged food, some prefer coo= king. I see Emacs as a platform for those who prefer cooking. Public suppor= t via reddit or stackoverflow or the Emacs mailing lists, tends to be frien= dly and helpful but can't substitute users' own desires to cook for= themselves. When VSCode goes wrong, they have to figure stuff out for them= selves anyway (it's a fairly buggy ecosystem,=C2=A0in my experience). I= f they can handle the complexity of the Rust compiler, they can handle the = complexity of Emacs. They just have to cook a little.

On Wed, Oct 9, 2= 024 at 12:07=E2=80=AFPM Johan Myr=C3=A9en <johan.myreen@gmail.com> wrote:
I understand Emacs is a= volunteer project and finding good documentation writers is difficult. I w= as just suggesting what direction I would like to see Emacs documentation g= oing. Emacs has a good and extensive manual that provides mostly a great re= ference to how to use Emacs as an editor. What I am proposing is a higher l= evel view, a kind of cookbook on how to do different things with Emacs.
=
I just started my Emacs (from the main branch) with -q and opened a Rus= t source file. Emacs out of the box does not even recognize the .rs file ex= tension: the file is opened in Fundamental mode. A novice Emacs user might = guess that he or she needs to install a Rust mode for Emacs to recognize we= are editing Rust source code. But by only doing this the user is missing o= ut on so much useful functionality Emacs has to offer. How is the user supp= osed to know that =C2=A8Eglot" is the way to connect to a language ser= ver, or that a package named =C2=A8Company" provides completion? The o= nly way right now is to search for this on the internet, which is associate= d with the quality problems I described in my previous message.

Soft= ware has grown more complex during the years Emacs has been in existence, a= nd so have the expectations of the public using it. Emacs has fantastic col= lections of packages, each focusing on different things. This is a good mod= ular design. Some of these packages can be used to form, for example, a wor= king Rust development environment. The problem is finding these packages. H= ow does a new Emacs user know what to look for?

So I am proposi= ng a "task-oriented" category in the Emacs documentation. I don= =C2=B4t think there is such a category.

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 t= o be held
responsible for that as well
=C2=A0
No, all I am talking about is documentation. In fact I really dislike some= things that happen by magic, but are undocumented. They typically break ov= er time, which is a bigger headache to fix than configuring things by hand = using good documentation.

I'm guessing VSCode comes with pre-configured = LSP servers, a single
Rust mode, and a single Git interface.=C2=A0 Am I mistaken?

No, VSCode does not come pre-configured for Rust devel= opment. But, there is a good, task-oriented web page that describes in simp= le terms what needs to be installed and configured to start writing Rust co= de using VSCode. Similar pages exist for Java, Javascript, C++, C#, Python,= Go, etc. More importantly, this documentation can be found on code.visualstudio.com (<= a href=3D"https://code.visualstudio.com/docs/languages/rust" target=3D"_bla= nk">https://code.visualstudio.com/docs/languages/rust), not on YouTube.= com or robert.kra.hn= or some other random website.

Johan Myr=C3=A9en




On Wed, 9 Oct 2024 at 16:14, Eli Zaretskii <<= a href=3D"mailto:eliz@gnu.org" target=3D"_blank">eliz@gnu.org> wrote= :
> From: Joh= an Myr=C3=A9en <johan.myreen@gmail.com>
> 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 El= isp packages, and configuring them.

My analysis is different.=C2=A0 Emacs lacks volunteers who'd sit down a= nd
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-bogglin= g.
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 develo= pment 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, Eg= lot to communicate with
> rust-analyzer (a Language Server implementation for Rust) for completi= on and goto definition, Company
> mode for code completion, Magit for version control, DAP mode for debu= gging, and so on. Many of these
> packages have alternative implementations, for example rustic-mode ins= tead of rust-mode.

This is an exaggeration to some degree.=C2=A0 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.=C2=A0 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?=C2=A0 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.=C2=A0 Magit is nice, but not really
necessary, since we have VC built in, which doesn't need to be
configured.=C2=A0 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.=C2=A0 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 pack= ages, 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.=C2=A0 Am I mistaken?=C2=A0 If so, is= that
how we want to treat our users? will they agree to be treated like
that?
--00000000000040d59606240d87d8--