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

[Martin Maechler]

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