Re: Debian installation bug report with current package and Emacs 28.1

Tony Rossini via ESS-help <[email protected]> Tue, 13 Sep 2022 18:17:31 +0200
Newsgroups gmane.emacs.ess.general
Message-ID <CAA1MS4r6WB03y3g-KHLo8+djLPPYP0Qg1qD4GJq+M27B4kWivg@mail.gmail.com>
does that affect eshell?  i thought not and only shell?

On Tue, 13 Sept 2022, 17:56 Martin Maechler via ESS-help, <
[email protected]> 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 <[email protected]>
> 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 | [email protected]
>     >>
>     >> ______________________________________________
>     >> [email protected] mailing list
>     >> https://stat.ethz.ch/mailman/listinfo/ess-help
>     >>
>
>     > ______________________________________________
>     > [email protected] mailing list
>     > https://stat.ethz.ch/mailman/listinfo/ess-help
>
> ______________________________________________
> [email protected] mailing list
> https://stat.ethz.ch/mailman/listinfo/ess-help
>

	[[alternative HTML version deleted]]

______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help