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

[Martin Maechler]

>>>>> Tony Rossini via ESS-help 
>>>>>     on Wed, 14 Sep 2022 12:02:26 +0200 writes:

    > 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 :)

I'm sorry Tony,  but this was only the bell it ringed with you;
I meant something very different that has only been introduced
with all the package-handling tools in ESS after the last formal
release (in 2018).


    > 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

I did not know, but now I searched (a little while) and found:
It's even an open one:

   https://github.com/emacs-ess/ESS/issues/508

{but I think it does not tell the whole story
 since the situation has become worse for me in the mean time}.

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

    > ______________________________________________
    > ESS-help using r-project.org mailing list
    > https://stat.ethz.ch/mailman/listinfo/ess-help