[ESS] Debian installation bug report with current package and Emacs 28.1
Martin Maechler
m@ech|er @end|ng |rom @t@t@m@th@ethz@ch
Wed Sep 14 10:17:16 CEST 2022
>>>>> Tony Rossini
>>>>> on Tue, 13 Sep 2022 18:17:31 +0200 writes:
> does that affect eshell? i thought not and only shell?
In spite of having learned about eshell a long time ago, for
some reason I never got really happy with it and hence have *not*
used anymore.
So, indeed, I'm only talking about the (comint based) *shell*
buffers started by M-x shell
> On Tue, 13 Sept 2022, 17:56 Martin Maechler via ESS-help, <ess-help using r-project.org> wrote:
>> >>>>> Lionel Henry via ESS-help
>> >>>>> on Tue, 13 Sep 2022 17:33:22 +0200 writes:
>>
>> > Martin, did you have other concerns besides the freeze that we have
>> > determined is an interaction between polymode and large
>> `.libPaths()`,
>> > rather than a bug in ESS?
>>
>> > If not, I think we should think about a release.
>>
>> > Best,
>> > Lionel
>>
>> Thank you, Dirk and Lionel.
>>
>> I agree. I have been thinking about a release for some weeks
>> now, but never got much time.
>> We should push for it now.
>> I really don't want to lose the Debian package of ESS (*).
>>
>> Really, the polymode maintainer and the rest of ESS core agreed a long time
>> ago that a release should be for "ESS+" i.e. should be a __bundle__
>> of "correctly" inter-working ESS + polymode.
>>
>> One thing that in my view *MUST* change in ESS is the current default
>> behavior of ESS taking over *shell* (comint) buffers, by
>> "thinking" such *shell* buffers should relate to some R package
>> and its development, an R package where I have incidentally
>> opened one file such as <pkg>/R/<file>.R
>>
>> There are many reasons people use a *shell* inside Emacs, and
>> just because they also use ESS and open an R code file buffer of
>> an R package does not mean that the *shell* buffer should
>> somehow "become aware" of that package and its development.
>> ... at least *NOT* by default.
>> For me, this also makes *shell* buffer sometimes freeze (mostly just
>> a second or two, but rare times much worse.. ).
>>
>> Martin
>>
>> ---
>> *) even though at the moment only one oldish computer at my home uses
>> Ubuntu LTS and otherwise, I use Fedora everywhere else --
>> but *NOT* Emacs 28, btw!)
>>
>>
>> > On 9/13/22, Dirk Eddelbuettel via ESS-help <ess-help using r-project.org>
>> wrote:
>> >>
>> >> A follow-up to this bug report: Due to the breakage caused by the
>> (old) ess
>> >> package, I (as maintainer of the Debian package) now received the
>> note that
>> >> the ess / elpa-ess packages will be archived away from Debian
>> unstable as
>> >> they make Emacs 28.1 uninstallable.
>> >>
>> >> So future Debian releases will not have ess / elpa-ess package. Of
>> course
>> >> installation from other sources remains possible.
>> >>
>> >> We debated here for some time what to do about a new ESS release,
>> but with
>> >> nothing concrete to show, and this is now a consequence of
>> (in)action. We
>> >> are all between a rock and a hard place: the upstream is 'not quite
>> right'
>> >> for a release so none happens, yet Debian users want Emacs 28.1.
>> So there.
>> >>
>> >> Dirk
>> >>
>> >> --
>> >> dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org
>> >>
>> >> ______________________________________________
>> >> ESS-help using r-project.org mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/ess-help
>> >>
>>
>> > ______________________________________________
>> > ESS-help using r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/ess-help
>>
>> ______________________________________________
>> ESS-help using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/ess-help
>>
> [[alternative HTML version deleted]]
More information about the ESS-help
mailing list