* Re: Re Re: Why not include all ELPA packages in an Emacs release? @ 2024-05-29 16:31 Pedro Andres Aranda Gutierrez 2024-05-29 20:36 ` Philip Kaludercic 0 siblings, 1 reply; 6+ messages in thread From: Pedro Andres Aranda Gutierrez @ 2024-05-29 16:31 UTC (permalink / raw) To: emacs-devel, Eli Zaretskii Cc: arash, Stefan Kangas, jb, Stefan Monnier, Philip Kaludercic [-- Attachment #1: Type: text/plain, Size: 1902 bytes --] Message-ID: <86r0dksk1x.fsf@gnu.org> >> Eli Zaretskii <eliz@gnu.org> writes: >> >> > If there are packages on ELPA which we consider to be a must for users >> > (I don't think there are, but maybe I'm forgetting something), lets >> > add them to core instead. >> >> If Emacs considers in-buffer completion an important feature, then I'd >> say corfu and cape are must. vertico and marginalia are also must in my >> book since they offer a better experience with vertical minibuffer >> completion. > If people want them, and their developers agree, we can add them. <irony>At this point, why not company, which BTW works nicely both on windows and -nw Emacs?</irony> <seriously>For every package you think of integrating, there will be a lot of people how use a different package for the functionality, so this spells exchanges without end here and a lot of users frustrated in the world outside the list </seriously> >> And while we're at it: There are sometimes requests for adding AUCTeX to >> core. Do you have an opinion about that? > >I don't mind. But let's hear what others think. Well, AUCTeX was so feature-bloated that made me start using vanilla Emacs and writing the things I really needed myself. So grateful it existed, because it made my elisp evolve :-) Now seriously, One of the nicest things in Emacs is the package repo(s). I have the Emacs I want because we have use-package (and that is not so long ago) to make our lives (relatively) easy. And I dread to think what would happen WTR to size of the distributable object (.app in macos, .rpm/.deb/.snap in Linux, etc.) if we start shipping everything in it. My .2 cents -- Fragen sind nicht da, um beantwortet zu werden, Fragen sind da um gestellt zu werden Georg Kreisler Headaches with a Juju log: unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run a leader-deposed hook here, but we can't yet [-- Attachment #2: Type: text/html, Size: 2531 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Re Re: Why not include all ELPA packages in an Emacs release? 2024-05-29 16:31 Re Re: Why not include all ELPA packages in an Emacs release? Pedro Andres Aranda Gutierrez @ 2024-05-29 20:36 ` Philip Kaludercic 2024-05-30 6:16 ` Pedro Andres Aranda Gutierrez 0 siblings, 1 reply; 6+ messages in thread From: Philip Kaludercic @ 2024-05-29 20:36 UTC (permalink / raw) To: Pedro Andres Aranda Gutierrez Cc: emacs-devel, Eli Zaretskii, arash, Stefan Kangas, jb, Stefan Monnier Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes: > Message-ID: <86r0dksk1x.fsf@gnu.org> > >>> Eli Zaretskii <eliz@gnu.org> writes: >>> >>> > If there are packages on ELPA which we consider to be a must for users >>> > (I don't think there are, but maybe I'm forgetting something), lets >>> > add them to core instead. >>> >>> If Emacs considers in-buffer completion an important feature, then I'd >>> say corfu and cape are must. vertico and marginalia are also must in my >>> book since they offer a better experience with vertical minibuffer >>> completion. > >> If people want them, and their developers agree, we can add them. > > <irony>At this point, why not company, which BTW works nicely both on > windows and -nw Emacs?</irony> I unironically think that this might be a better choice. > <seriously>For every package you think of integrating, there will be a lot > of people how use a different package for the functionality, so this spells > exchanges without end here and a lot of users frustrated in the world > outside the list </seriously> Bundling a package with Emacs is not the same as enabling it by default. I guess the exception are major modes, where it makes sense to have these added to auto-mode-alist, but otherwise something like Company shouldn't be enabled by default. >>> And while we're at it: There are sometimes requests for adding AUCTeX to >>> core. Do you have an opinion about that? >> >>I don't mind. But let's hear what others think. > > Well, AUCTeX was so feature-bloated that made me start using vanilla Emacs > and writing the things I really needed myself. So grateful it existed, > because it made my elisp evolve :-) This sounds like a LaTeX/AUCTeX-specific issue. IIUC, you prefer the built-in latex-mode that AUCTeX supersedes, right? Or what do you mean by bloated? > Now seriously, One of the nicest things in Emacs is the package repo(s). > I have the Emacs I want because we have use-package (and that is not so > long ago) > to make our lives (relatively) easy. And I dread to think what would happen > WTR to size of the distributable object (.app in macos, .rpm/.deb/.snap in > Linux, > etc.) if we start shipping everything in it. There are still plenty of cases where people cannot just install packages over the net and are stuck with whatever Emacs is bundled with. ELPA remains useful to upgrade packages that don't depend on new core features, but having "blessed" packages bundled without having to explain to new-comers "well yes, Emacs can do that but you have to install foo, bar and baaz first" (here "foo", "bar" and "baaz" are more often than not some weird names that they cannot remember in the first place) is helpful and underappreciated by many. WRT the package size, I wouldn't worry that much. Even a large package like AUCTeX is just under 10MB in my /elpa/ directory. The mean package side on ELPA is about 100-150KB. Packages like Debian that don't bundled .el sources (instead just using .elc) by default might be even better off. > My .2 cents -- Philip Kaludercic on peregrine ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Re Re: Why not include all ELPA packages in an Emacs release? 2024-05-29 20:36 ` Philip Kaludercic @ 2024-05-30 6:16 ` Pedro Andres Aranda Gutierrez 2024-05-30 6:31 ` Philip Kaludercic 2024-05-30 14:34 ` A small(er) Emacs (was: Why not include all ELPA packages in an Emacs release?) Stefan Monnier 0 siblings, 2 replies; 6+ messages in thread From: Pedro Andres Aranda Gutierrez @ 2024-05-30 6:16 UTC (permalink / raw) To: Philip Kaludercic Cc: emacs-devel, Eli Zaretskii, arash, Stefan Kangas, jb, Stefan Monnier [-- Attachment #1: Type: text/plain, Size: 4320 bytes --] Hi On Wed, 29 May 2024 at 22:36, Philip Kaludercic <philipk@posteo.net> wrote: > Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes: > > > Message-ID: <86r0dksk1x.fsf@gnu.org> > > > >>> Eli Zaretskii <eliz@gnu.org> writes: > >>> > >>> > If there are packages on ELPA which we consider to be a must for > users > >>> > (I don't think there are, but maybe I'm forgetting something), lets > >>> > add them to core instead. > >>> > >>> If Emacs considers in-buffer completion an important feature, then I'd > >>> say corfu and cape are must. vertico and marginalia are also must in > my > >>> book since they offer a better experience with vertical minibuffer > >>> completion. > > > >> If people want them, and their developers agree, we can add them. > > > > <irony>At this point, why not company, which BTW works nicely both on > > windows and -nw Emacs?</irony> > > I unironically think that this might be a better choice. > Hmm... nice to hear... thanks :-) > > <seriously>For every package you think of integrating, there will be a > lot > > of people how use a different package for the functionality, so this > spells > > exchanges without end here and a lot of users frustrated in the world > > outside the list </seriously> > > Bundling a package with Emacs is not the same as enabling it by default. > +1 > I guess the exception are major modes, where it makes sense to have > these added to auto-mode-alist, but otherwise something like Company > shouldn't be enabled by default. > Couldn't agree more... > > >>> And while we're at it: There are sometimes requests for adding AUCTeX > to > >>> core. Do you have an opinion about that? > >> > >>I don't mind. But let's hear what others think. > > > > Well, AUCTeX was so feature-bloated that made me start using vanilla > Emacs > > and writing the things I really needed myself. So grateful it existed, > > because it made my elisp evolve :-) > > This sounds like a LaTeX/AUCTeX-specific issue. IIUC, you prefer the > built-in latex-mode that AUCTeX supersedes, right? Or what do you mean > by bloated? > Jup, that was a purely LaTeX issue. And yes, I didn't have time to learn all the specifics of AUCTeX and did some customisation + yasnippets to get my phD thesis written. At that time, a switch from MSWord/OpenOffice to LaTeX was churning all my free CPU cycles, because I had work and real life in parallel. > > Now seriously, One of the nicest things in Emacs is the package repo(s). > > I have the Emacs I want because we have use-package (and that is not so > > long ago) > > to make our lives (relatively) easy. And I dread to think what would > happen > > WTR to size of the distributable object (.app in macos, .rpm/.deb/.snap > in > > Linux, > > etc.) if we start shipping everything in it. > > There are still plenty of cases where people cannot just install > packages over the net and are stuck with whatever Emacs is bundled with. > Good point... > ELPA remains useful to upgrade packages that don't depend on new core > features, but having "blessed" packages bundled without having to > explain to new-comers "well yes, Emacs can do that but you have to > install foo, bar and baaz first" (here "foo", "bar" and "baaz" are more > often than not some weird names that they cannot remember in the first > place) is helpful and underappreciated by many. > I get your point... and right, there are situations where you just can't get the packages from the Internet. WRT the package size, I wouldn't worry that much. Even a large package > like AUCTeX is just under 10MB in my /elpa/ directory. The mean package > side on ELPA is about 100-150KB. Packages like Debian that don't > bundled .el sources (instead just using .elc) by default might be even > better off. > But just keep in mind that there are situations, where the platform must deploy Emacs on, might not be as relaxed WRT disk space... And it's not about a specific package, it's about a trickle of packages becoming a flood... > My .2 cents > > -- > Philip Kaludercic on peregrine > Best, /PA -- Fragen sind nicht da, um beantwortet zu werden, Fragen sind da um gestellt zu werden Georg Kreisler Headaches with a Juju log: unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run a leader-deposed hook here, but we can't yet [-- Attachment #2: Type: text/html, Size: 6745 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Re Re: Why not include all ELPA packages in an Emacs release? 2024-05-30 6:16 ` Pedro Andres Aranda Gutierrez @ 2024-05-30 6:31 ` Philip Kaludercic 2024-05-30 10:36 ` Pedro Andres Aranda Gutierrez 2024-05-30 14:34 ` A small(er) Emacs (was: Why not include all ELPA packages in an Emacs release?) Stefan Monnier 1 sibling, 1 reply; 6+ messages in thread From: Philip Kaludercic @ 2024-05-30 6:31 UTC (permalink / raw) To: Pedro Andres Aranda Gutierrez Cc: emacs-devel, Eli Zaretskii, arash, Stefan Kangas, jb, Stefan Monnier Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes: >> >>> And while we're at it: There are sometimes requests for adding AUCTeX >> to >> >>> core. Do you have an opinion about that? >> >> >> >>I don't mind. But let's hear what others think. >> > >> > Well, AUCTeX was so feature-bloated that made me start using vanilla >> Emacs >> > and writing the things I really needed myself. So grateful it existed, >> > because it made my elisp evolve :-) >> >> This sounds like a LaTeX/AUCTeX-specific issue. IIUC, you prefer the >> built-in latex-mode that AUCTeX supersedes, right? Or what do you mean >> by bloated? >> > > Jup, that was a purely LaTeX issue. And yes, I didn't have time to learn > all the specifics > of AUCTeX and did some customisation + yasnippets to get my phD thesis > written. > At that time, a switch from MSWord/OpenOffice to LaTeX was churning all my > free CPU cycles, > because I had work and real life in parallel. [...] > WRT the package size, I wouldn't worry that much. Even a large package >> like AUCTeX is just under 10MB in my /elpa/ directory. The mean package >> side on ELPA is about 100-150KB. Packages like Debian that don't >> bundled .el sources (instead just using .elc) by default might be even >> better off. >> > > But just keep in mind that there are situations, where the platform must > deploy > Emacs on, might not be as relaxed WRT disk space... And it's not about a > specific > package, it's about a trickle of packages becoming a flood... I can imagine that a distribution like Debian can choose to distribute two package. The regular Emacs, that would bundle the selected ELPA packages and "emacs-minimal" that wouldn't (and perhaps even remove some more, like games or some stuff like that). >> My .2 cents >> >> -- >> Philip Kaludercic on peregrine >> > > Best, /PA -- Philip Kaludercic on peregrine ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Re Re: Why not include all ELPA packages in an Emacs release? 2024-05-30 6:31 ` Philip Kaludercic @ 2024-05-30 10:36 ` Pedro Andres Aranda Gutierrez 0 siblings, 0 replies; 6+ messages in thread From: Pedro Andres Aranda Gutierrez @ 2024-05-30 10:36 UTC (permalink / raw) To: Philip Kaludercic Cc: emacs-devel, Eli Zaretskii, arash, Stefan Kangas, jb, Stefan Monnier [-- Attachment #1: Type: text/plain, Size: 1137 bytes --] Hi Philip, On Thu, 30 May 2024 at 08:31, Philip Kaludercic <philipk@posteo.net> wrote: > Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes: > > > But just keep in mind that there are situations, where the platform must > > deploy > > Emacs on, might not be as relaxed WRT disk space... And it's not about a > > specific > > package, it's about a trickle of packages becoming a flood... > > I can imagine that a distribution like Debian can choose to distribute > two package. The regular Emacs, that would bundle the selected ELPA > packages and "emacs-minimal" that wouldn't (and perhaps even remove some > more, like games or some stuff like that). > ... > -- > Philip Kaludercic on peregrine > And maybe, one should start thinking into including this option in the emacs Makefile. Something like a make install-mininal For those who self-compile ;-) Best, /PA -- Fragen sind nicht da, um beantwortet zu werden, Fragen sind da um gestellt zu werden Georg Kreisler Headaches with a Juju log: unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run a leader-deposed hook here, but we can't yet [-- Attachment #2: Type: text/html, Size: 1902 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* A small(er) Emacs (was: Why not include all ELPA packages in an Emacs release?) 2024-05-30 6:16 ` Pedro Andres Aranda Gutierrez 2024-05-30 6:31 ` Philip Kaludercic @ 2024-05-30 14:34 ` Stefan Monnier 1 sibling, 0 replies; 6+ messages in thread From: Stefan Monnier @ 2024-05-30 14:34 UTC (permalink / raw) To: Pedro Andres Aranda Gutierrez Cc: Philip Kaludercic, emacs-devel, Eli Zaretskii, arash, Stefan Kangas, jb > But just keep in mind that there are situations, where the platform > must deploy Emacs on, might not be as relaxed WRT disk space... And > it's not about a specific package, it's about a trickle of packages > becoming a flood... Emacs tarballs have grown over the years, some versions growing very significantly. Is it a concern? Yes, to some extent. Is it worth the effort of making a "slim Emacs" option? Apparently not because I don't know of anyone who has gone through the effort of actually making it a reality. IME if your target has enough disk constraints that installing the full Emacs is a concern, you're probably better served by one of: - Another editor (e.g. Zile). - Tramp. - just installing the full Emacs anyway. If you think you have a good use case where a "slim Emacs" is better than the above options, then by all means, get working on a patch. If it's simple&clean enough we may even accept it. I'm not holding my breath. Stefan ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-05-30 14:34 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-05-29 16:31 Re Re: Why not include all ELPA packages in an Emacs release? Pedro Andres Aranda Gutierrez 2024-05-29 20:36 ` Philip Kaludercic 2024-05-30 6:16 ` Pedro Andres Aranda Gutierrez 2024-05-30 6:31 ` Philip Kaludercic 2024-05-30 10:36 ` Pedro Andres Aranda Gutierrez 2024-05-30 14:34 ` A small(er) Emacs (was: Why not include all ELPA packages in an Emacs release?) Stefan Monnier
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).