[ESS] Debian installation bug report with current package and Emacs 28.1

[Tony Rossini]

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 using 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 <maechler using 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 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]]