it was related to the ability to start a shell, run R (or another stat language) in the shell, and convert it to an interactive R process known by ESS. handy for ssh'ing into a remote machine.
at least that was the idea, back in 1996 :) On Wed, 14 Sept 2022, 11:27 Lionel Henry via ESS-help, < ess-help@r-project.org> wrote: > I'm not sure what you mean by "taking over". > Do we have an issue tracking this on github? > > Lionel > > On 9/13/22, Martin Maechler <maech...@stat.math.ethz.ch> 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@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 | e...@debian.org > > >> > > >> ______________________________________________ > > >> ESS-help@r-project.org mailing list > > >> https://stat.ethz.ch/mailman/listinfo/ess-help > > >> > > > > > ______________________________________________ > > > ESS-help@r-project.org mailing list > > > https://stat.ethz.ch/mailman/listinfo/ess-help > > > > ______________________________________________ > ESS-help@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/ess-help > [[alternative HTML version deleted]] ______________________________________________ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help