From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arash Esbati Newsgroups: gmane.emacs.devel Subject: Re: Why not include all ELPA packages in an Emacs release? Date: Thu, 30 May 2024 00:04:49 +0200 Message-ID: References: <87bk4ql3u5.fsf@jeremybryant.net> <864jagu9ji.fsf@gnu.org> <878qzspd9j.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14172"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , Stefan Kangas , jb@jeremybryant.net, emacs-devel@gnu.org, monnier@iro.umontreal.ca, philipk@posteo.net To: Tassilo Horn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 30 00:05: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 1sCRQZ-0003QR-GW for ged-emacs-devel@m.gmane-mx.org; Thu, 30 May 2024 00:05:47 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sCRPk-00073O-UM; Wed, 29 May 2024 18:04: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 1sCRPj-000738-CA for emacs-devel@gnu.org; Wed, 29 May 2024 18:04:55 -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 1sCRPh-0005YQ-Cz; Wed, 29 May 2024 18:04:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=jkPU9QKVr0i3PjKbXDPIrErO0avSpW/yVM6GhGfIMEw=; b=dPCF6Dc/3f40/jNMG8sp 1zih1U9lZdJvTqOd7ToPgUkHOxlYCqlS3EO3Z17zxn6obnfdaXhS+6epvQAE/HM0e9cLUnz9daLoZ SGQGCqC/xHN8+kbNP1BXCJy6ZpD/gIUP78gqbwZplXXbjhQsOfZbVbuYbAKkbkU35oQ1ln3iUoUfL Uv7PMY0K5N5OYRJtIR8rqx8TeeRyczqAbJc8fdKJxp1V+/+ySWZuehCo32G0mjqKxML/a8CFc3ZOF uDNwgpo5+eddiHRp5+D2F38We04zqx4dvYc0qMPa20+kXBsanfF8eHRlk0sPNomiAu0y5mgEwv040 JF0xHeAeaHvNEA==; In-Reply-To: <878qzspd9j.fsf@gnu.org> (Tassilo Horn's message of "Wed, 29 May 2024 22:35:36 +0200") 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:319712 Archived-At: Tassilo Horn writes: > Nice completion UIs are certainly a very important feature and I have > the same preferences as you. But I don't see a reason why some specific > one has to be in core. It has long been ivy and company, now it's > vertico and corfu, and in 2 years the hottest bets might be something > else. I'd agree in general for almost every other feature, but my vote is to make an exception for the completion UI since it's an important piece for the user. Using completion currently with Emacs built-in tools is not very appealing, IMHO. > I mean, it's easy to put things into core but hardly possible to remove > them again without annoying someone. Yes, and there is no easy answer, but keeping status quo indefinitely doesn't feel right either. > One practical question is what happens with stock tex-mode.el then. > Right now, when you install AUCTeX, it'll take over. That would annoy > tex-mode users, I guess. I'd say you know best that we can teach AUCTeX to be more defensive in this regard, so that shouldn't be a showstopper :-) I think my strongest argument for adding AUCTeX to core is that currently, GNU/Linux distros offer AUCTeX as an extra package for their users, at least I know from Debian and openSUSE. The issue is that their extra package is often outdated or offers auto-generated styles which don't work as expected. Bottom line is that we tell frustrated users to uninstall what the distro offers and install it from ELPA. Having AUCTeX in core would make those distro packages vanish (hopefully) and take the hassle from the users and us providing tarball releases (which I think we have decided to drop already). So a dual approach (core and ELPA) would be my favorite. > Also, I'm not sure if AUCTeX is not already past its prime time. > Preview-LaTeX is cool but IIRC doesn't work anymore with some popular > styles. And document parsing in order to highlight user-defined > commands and offer them for completion is probably better done in some > LaTeX language server like texlab and then used with eglot or > lsp-mode. Reg. preview-latex, maybe AUCTeX should have a look how Org creates previews, IIUC that process was revamped recently(?). Reg. LSP servers: I thought many times that LSP would be the savior, but my brief tests with LaTeX LSP servers were not really satisfying. Chances are high that the problem was sitting in front of the monitor. So yes, there is a good chance that AUCTeX is about to have its prime time, but I think not yet because it still offers a lot more than mere completion. Best, Arash