Re: [bug#42738] [Work in progress] gnu: emacs: update to 27.1

Re: [bug#42738] [Work in progress] gnu: emacs: update to 27.1

[Jack Hill]

I've added guix-devel to the cc: becasue the Emacs upgrade has come up a 
few times on IRC, and there are ways for you to help move this upgrade 
along. Any suggestions are welcome, but in particular, you can help with 
the following:

* Review the inputs and configure flags. Are there any additional changes 
needed for the new Emacs version? A good place to start with this would be 
the Emacs NEWS file. It's quite lengthy, so additional eyes would be quite 
helpful.

* Making sure packages build and work with Emacs 27.1. I expect this to 
involve elisp hacking and working with upstream.

I have the following updates, since I prepared at patch for the 27.1 
release candidate:

On Thu, 6 Aug 2020, Jack Hill wrote:

> Hi Guix,
>
> Now that there is a release candidate for Emacs 27.1, I started working on 
> updating our Emacs packages.

Now that Emacs 27.1 has been released, I've updated the patch for released 
version. Per Michael Rohleder's (mroh) suggestion on IRC, I have added gmp 
as an input.

Is the emacs-wide-int variant needed with the new multiprecision 
functionality?

> For the most part, it went smoothly, but there are some other packages 
> that broke after updating Emacs. Of the packages reported by `guix 
> refresh -l emacs`, the following had issues:

I have not had a chance to try rebuilding the dependents, but I have 
updated news for the following packages:

> emacs-haskell-mode - Tests newly fail with Emacs 27. Issue reported upstream 
> [2]
>
> [2] https://github.com/haskell/haskell-mode/issues/1714
>
> emacs-dante - depends on emacs-haskell-mode

John Soo (jsoo) volunterred to look at the haskell packages. Thanks!

> emacs-ample-regexps - This package builds from an arbitrary commit,
> and updating that fixed issues with Emacs 27 [4].
>
>[4] https://issues.guix.gnu.org/42737

This patch has been merged!

> emacs-doom-themes - This package builds from an arbitrary commit, and 
> updating that fixed issues with Emacs 27 [5].
>
> [5] https://issues.guix.gnu.org/42736

This patch has been merged!

> emacs-treemacs - Tests newly fail with Emacs 27. Issue reported upstream [6].
>
> [6] https://github.com/Alexander-Miller/treemacs/issues/707

Upstream has acknowledged the issue and is investigating.

> emacs-treepy - Byte compilation failure. There is an existing upstram issue
> [8].
>
> [8] https://github.com/volrath/treepy.el/issues/8

Upstream fixed the issue, and Michael Rohleder got the fix into Guix. 
Thanks!

> emacs-github-review - depends on emacs-treepy

With the fixed treepy, emacs-github-review now builds as well.

> notmuch - Tests time out.

Work is being done upstream to add support for 27.1 [9]

[9] https://nmbug.notmuchmail.org/nmweb/show/87bljg8nxr.fsf%40cassou.me

Re: [bug#42738] [Work in progress] gnu: emacs: update to 27.1

[Jack Hill]

Thank you all for these improvements.

On Tue, 18 Aug 2020, Alexey Abramov wrote:

> I just checked, and seems like harfbuzz switch is not required. News 
> file also says that it is on by default.

Great. This was copied bliendly from the emacs-next package. I've removed 
it.

On Tue, 18 Aug 2020, Michael Rohleder wrote:
>Jack Hill <jackhill@jackhill.us> writes:
>> Now that Emacs 27.1 has been released, I've updated the patch for
>> released version. Per Michael Rohleder's (mroh) suggestion on IRC, I
>> have added gmp as an input.
>
> emacs (26 and 27) configure and compiles with gmp anyway. I couldn't 
> find out where it's (implicit) coming from. I still like the input to 
> make it explicit, though.

Interesting, I didn't catch this. I like explicit better as well.

>> Is the emacs-wide-int variant needed with the new multiprecision
>> functionality?
>
> I don't think so.

Ok, I've deprecated that package.

On Tue, 18 Aug 2020, Zhu Zihao wrote:

> Can you add configuration options "--with-cairo"(Also add cairo as 
> input) the main advantage of cairo build is the power to display color 
> emoji in Emacs.

Sounds good to me. I've enabled cairo, and per [1] removed libxft from the 
inputs.

[1] https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-27.1#n53

Best,
Jack

Re: [bug#42738] [Work in progress] gnu: emacs: update to 27.1

[Diego Nicola Barbato]

Hey Guix,

Jack Hill <jackhill@jackhill.us> writes:

[...]

> On Tue, 18 Aug 2020, Michael Rohleder wrote:
>>Jack Hill <jackhill@jackhill.us> writes:

[...]

>>> Is the emacs-wide-int variant needed with the new multiprecision
>>> functionality?
>>
>> I don't think so.
>
> Ok, I've deprecated that package.

I added the emacs-wide-int variant because emacs-telega requires 62-bit
[sic] integers (https://debbugs.gnu.org/39412).  While Telega should
work with regular (non-wide-int) Emacs 27.1 (thanks to the new
multiprecision functionality), the test which checks if Emacs is suitable
for running Telega will fail, because it does not know about "bignums"
and looks at the value of most-positive-fixnum instead:

--8<---------------cut here---------------start------------->8---
  ;; 62bits for numbers is required
  ;; i.e. ./configure --with-wide-int
  (cl-assert (= most-positive-fixnum 2305843009213693951) nil
             "Emacs with wide ints (--with-wide-int) is required")
--8<---------------cut here---------------end--------------->8---

I suggest we keep the emacs-wide-int variant until this issue has been
resolved, so that the Emacs update does not break emacs-telega on 32-bit
systems.

[...]

Greetings,

Diego