Starting the Emacs 27 release cycle

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Starting the Emacs 27 release cycle

Eli Zaretskii
I'm planning on cutting the emacs-27 release branch in a week or so.
If someone has plans for changes that must be done before that, so
that they end up in Emacs 27.1, please make it happen till then, or
ask here for an extension.  After the branch is cut, only bugfixes
will be allowed on the release branch, per our usual practices (see
CONTRIBUTE).

Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: Starting the Emacs 27 release cycle

Robert Pluim
>>>>> On Sat, 23 Nov 2019 18:59:39 +0200, Eli Zaretskii <[hidden email]> said:

    Eli> I'm planning on cutting the emacs-27 release branch in a week or so.
    Eli> If someone has plans for changes that must be done before that, so
    Eli> that they end up in Emacs 27.1, please make it happen till then, or
    Eli> ask here for an extension.  After the branch is cut, only bugfixes
    Eli> will be allowed on the release branch, per our usual practices (see
    Eli> CONTRIBUTE).

Iʼll push the change for the default value of
network-stream-use-client-certificates this weekend.

Iʼd like to get the network-interface-list change in as well, but that
might be too risky. It works for me on various GNU/Linux
distributions, and in my Windows VM, but I haven't seen any feedback
on it.

Robert

Reply | Threaded
Open this post in threaded view
|

Re: Starting the Emacs 27 release cycle

Eli Zaretskii
> From: Robert Pluim <[hidden email]>
> Cc: [hidden email]
> Date: Sat, 23 Nov 2019 18:25:28 +0100
>
> Iʼd like to get the network-interface-list change in as well, but that
> might be too risky. It works for me on various GNU/Linux
> distributions, and in my Windows VM, but I haven't seen any feedback
> on it.

I'd say merge it, and let's take it from there.  We can always revert
if push comes to shove, but since it worked for you, I think that's
unlikely.

Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: Starting the Emacs 27 release cycle

Philipp Stephani
In reply to this post by Eli Zaretskii
Am Sa., 23. Nov. 2019 um 18:01 Uhr schrieb Eli Zaretskii <[hidden email]>:
>
> I'm planning on cutting the emacs-27 release branch in a week or so.
> If someone has plans for changes that must be done before that, so
> that they end up in Emacs 27.1, please make it happen till then, or
> ask here for an extension.  After the branch is cut, only bugfixes
> will be allowed on the release branch, per our usual practices (see
> CONTRIBUTE).


As detailed in https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg00444.html,
I'd request to wait until the module interface for big integers is
sorted out.

Thanks!

Reply | Threaded
Open this post in threaded view
|

Re: Starting the Emacs 27 release cycle

Eric Abrahamsen-2
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> writes:

> I'm planning on cutting the emacs-27 release branch in a week or so.
> If someone has plans for changes that must be done before that, so
> that they end up in Emacs 27.1, please make it happen till then, or
> ask here for an extension.  After the branch is cut, only bugfixes
> will be allowed on the release branch, per our usual practices (see
> CONTRIBUTE).

A few months ago I made changes to Gnus so that non-ascii group names
(which used to mostly stay encoded) were mostly decoded. But I preserved
the original odd encoding in Gnus' persistence files, so that developers
could move back and forth between Emacs versions.

For the 27.1 release I'd like to use Gnus' upgrade mechanism to switch
to properly-encoded persistence files. The mechanism includes a prompt
to the user, so they'll be aware of what happened, and it will only
affect Gnus users with non-ascii group names. But it would mean that
those users couldn't switch back to Emacs 26 without seeing encoding
weirdness.

Hope that's okay...

Eric


Reply | Threaded
Open this post in threaded view
|

Re: Starting the Emacs 27 release cycle

Juri Linkov-2
In reply to this post by Eli Zaretskii
> I'm planning on cutting the emacs-27 release branch in a week or so.
> If someone has plans for changes that must be done before that, so
> that they end up in Emacs 27.1, please make it happen till then, or
> ask here for an extension.  After the branch is cut, only bugfixes
> will be allowed on the release branch, per our usual practices (see
> CONTRIBUTE).

The remaining tabs feature is to add support for a new display action
display-buffer-in-tab for display-buffer-alist to be implemented in
bug#38354 that takes about a week.

PS: I also have an unfinished implementation of more fancy looking tabs
with rounded corners that would take more than 2 weeks to complete
but this is of lesser importance and thus has lower priority.

Reply | Threaded
Open this post in threaded view
|

Re: Starting the Emacs 27 release cycle

Stefan Kangas
Juri Linkov <[hidden email]> writes:

> PS: I also have an unfinished implementation of more fancy looking tabs
> with rounded corners that would take more than 2 weeks to complete
> but this is of lesser importance and thus has lower priority.

That sounds very nice, and will help Emacs look more modern and user
friendly.  Is there any way to make an exception to include this on
the Emacs 27.1 branch?  It's hard to imagine that it would drastically
affect the stability of that branch, in my opinion.  OTOH, of course,
this is a slippery slope.  Please shoot my idea down if it's not
wanted.

Best regards,
Stefan Kangas

Reply | Threaded
Open this post in threaded view
|

Re: Starting the Emacs 27 release cycle

Eli Zaretskii
In reply to this post by Philipp Stephani
> From: Philipp Stephani <[hidden email]>
> Date: Sat, 23 Nov 2019 21:02:30 +0100
> Cc: Emacs developers <[hidden email]>
>
> As detailed in https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg00444.html,
> I'd request to wait until the module interface for big integers is
> sorted out.

Do you have an ETA for that?  Any chance for sorting this out this
week?

Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: Starting the Emacs 27 release cycle

Eli Zaretskii
In reply to this post by Eric Abrahamsen-2
> From: Eric Abrahamsen <[hidden email]>
> Date: Sat, 23 Nov 2019 13:30:35 -0800
> Cc: Lars Ingebrigtsen <[hidden email]>
>
> A few months ago I made changes to Gnus so that non-ascii group names
> (which used to mostly stay encoded) were mostly decoded. But I preserved
> the original odd encoding in Gnus' persistence files, so that developers
> could move back and forth between Emacs versions.
>
> For the 27.1 release I'd like to use Gnus' upgrade mechanism to switch
> to properly-encoded persistence files. The mechanism includes a prompt
> to the user, so they'll be aware of what happened, and it will only
> affect Gnus users with non-ascii group names. But it would mean that
> those users couldn't switch back to Emacs 26 without seeing encoding
> weirdness.
>
> Hope that's okay...

I don't know enough about Gnus to have an opinion about the potential
risks in this change.  So I'll leave it to you, Lars, and the rest of
the Gnus team to make the decision whether this should be in Emacs 27
or not.

Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: Starting the Emacs 27 release cycle

Eli Zaretskii
In reply to this post by Juri Linkov-2
> From: Juri Linkov <[hidden email]>
> Cc: [hidden email]
> Date: Sun, 24 Nov 2019 01:16:00 +0200
>
> The remaining tabs feature is to add support for a new display action
> display-buffer-in-tab for display-buffer-alist to be implemented in
> bug#38354 that takes about a week.
>
> PS: I also have an unfinished implementation of more fancy looking tabs
> with rounded corners that would take more than 2 weeks to complete
> but this is of lesser importance and thus has lower priority.

Thanks, so it sounds like we will be good to go in about a week.

Reply | Threaded
Open this post in threaded view
|

Re: Starting the Emacs 27 release cycle

Robert Pluim
In reply to this post by Eli Zaretskii
>>>>> On Sat, 23 Nov 2019 19:41:48 +0200, Eli Zaretskii <[hidden email]> said:

    >> From: Robert Pluim <[hidden email]>
    >> Cc: [hidden email]
    >> Date: Sat, 23 Nov 2019 18:25:28 +0100
    >>
    >> Iʼd like to get the network-interface-list change in as well, but that
    >> might be too risky. It works for me on various GNU/Linux
    >> distributions, and in my Windows VM, but I haven't seen any feedback
    >> on it.

    Eli> I'd say merge it, and let's take it from there.  We can always revert
    Eli> if push comes to shove, but since it worked for you, I think that's
    Eli> unlikely.

OK, Iʼll do that once savannah is back up.

Robert

Reply | Threaded
Open this post in threaded view
|

Re: Starting the Emacs 27 release cycle

Philipp Stephani
In reply to this post by Eli Zaretskii
Am So., 24. Nov. 2019 um 04:30 Uhr schrieb Eli Zaretskii <[hidden email]>:

>
> > From: Philipp Stephani <[hidden email]>
> > Date: Sat, 23 Nov 2019 21:02:30 +0100
> > Cc: Emacs developers <[hidden email]>
> >
> > As detailed in https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg00444.html,
> > I'd request to wait until the module interface for big integers is
> > sorted out.
>
> Do you have an ETA for that?  Any chance for sorting this out this
> week?

It depends on whether you want to get Paul's approval.

Reply | Threaded
Open this post in threaded view
|

Re: Starting the Emacs 27 release cycle

Phil Sainty
In reply to this post by Stefan Kangas
On 2019-11-24 12:49, Stefan Kangas wrote:

> Juri Linkov <[hidden email]> writes:
>
>> PS: I also have an unfinished implementation of more fancy looking
>> tabs with rounded corners that would take more than 2 weeks to
>> complete but this is of lesser importance and thus has lower
>> priority.
>
> That sounds very nice, and will help Emacs look more modern and user
> friendly.  Is there any way to make an exception to include this on
> the Emacs 27.1 branch?

I've just tried the tab modes for the first time, and would describe
the current default look as "functional", so if the proposed fancier
look is a substantial improvement, then I'd be in favour of either
allowing the extra time to develop them, or else allowing them to be
merged later as bug-fixes.

Perhaps it would be useful to see a screenshot showing the difference?


-Phil


Reply | Threaded
Open this post in threaded view
|

Re: Starting the Emacs 27 release cycle

Eli Zaretskii
In reply to this post by Philipp Stephani
> From: Philipp Stephani <[hidden email]>
> Date: Mon, 25 Nov 2019 22:48:27 +0100
> Cc: Emacs developers <[hidden email]>
>
> Am So., 24. Nov. 2019 um 04:30 Uhr schrieb Eli Zaretskii <[hidden email]>:
> >
> > > From: Philipp Stephani <[hidden email]>
> > > Date: Sat, 23 Nov 2019 21:02:30 +0100
> > > Cc: Emacs developers <[hidden email]>
> > >
> > > As detailed in https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg00444.html,
> > > I'd request to wait until the module interface for big integers is
> > > sorted out.
> >
> > Do you have an ETA for that?  Any chance for sorting this out this
> > week?
>
> It depends on whether you want to get Paul's approval.

AFAIU, you and Paul are discussing some aspects of this, and it's up
to you two when and how to finish the discussion.  I'm not waiting for
approval for anything I asked in this matter.

Reply | Threaded
Open this post in threaded view
|

Re: Starting the Emacs 27 release cycle

Juri Linkov-2
In reply to this post by Stefan Kangas
>> PS: I also have an unfinished implementation of more fancy looking tabs
>> with rounded corners that would take more than 2 weeks to complete
>> but this is of lesser importance and thus has lower priority.
>
> That sounds very nice, and will help Emacs look more modern and user
> friendly.  Is there any way to make an exception to include this on
> the Emacs 27.1 branch?  It's hard to imagine that it would drastically
> affect the stability of that branch, in my opinion.  OTOH, of course,
> this is a slippery slope.  Please shoot my idea down if it's not
> wanted.

These fancy looks with rounded corners should not be overrated.  They
have their disadvantages: fancy curves take screen space on both sides
on every tab, thus less tabs fit into the tab bar than now.  I guess
this is the reason why web browsers and other editors abandoned curves
for square shapes.  Chromium uses rounded corners only for the current tab,
and no shapes at all for other tabs, just separates them by a vertical bar.
Firefox uses a square shape for the current tab, and no special styles
for other tabs, only a vertical separator.  So currently tabs in Emacs
are already fancier than even in Chromium and Firefox.

Reply | Threaded
Open this post in threaded view
|

Re: Starting the Emacs 27 release cycle

Juri Linkov-2
In reply to this post by Phil Sainty
>>> PS: I also have an unfinished implementation of more fancy looking

>>> tabs with rounded corners that would take more than 2 weeks to
>>> complete but this is of lesser importance and thus has lower
>>> priority.
>> That sounds very nice, and will help Emacs look more modern and user
>> friendly.  Is there any way to make an exception to include this on
>> the Emacs 27.1 branch?
>
> I've just tried the tab modes for the first time, and would describe
> the current default look as "functional", so if the proposed fancier
> look is a substantial improvement, then I'd be in favour of either
> allowing the extra time to develop them, or else allowing them to be
> merged later as bug-fixes.
>
> Perhaps it would be useful to see a screenshot showing the difference?
I'm still not sure if a fancier look is worth the trouble,
especially since in some sense it's a change for the worse:
it takes too much screen space, so less tabs can fit into the tab bar.

Please see the difference: the first image is the current tab shapes,
on the second image you can see that less tabs can be displayed
on the tab bar:


tabs_current.png (7K) Download Attachment
tabs_rounded.png (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Starting the Emacs 27 release cycle

Stefan Kangas
Juri Linkov <[hidden email]> writes:

> I'm still not sure if a fancier look is worth the trouble,
> especially since in some sense it's a change for the worse:
> it takes too much screen space, so less tabs can fit into the tab bar.
>
> Please see the difference: the first image is the current tab shapes,
> on the second image you can see that less tabs can be displayed
> on the tab bar:

FWIW, and this is of course highly subjective, but I think the rounded
style looks much better, more professional and more modern.  The
trade-off with regards to screen real estate will be well worth it for
the default case, I think.  If we decide to go that way, we could
always keep the other look around as an option for those working on
smaller screens.

Best regards,
Stefan Kangas

Reply | Threaded
Open this post in threaded view
|

Re: Starting the Emacs 27 release cycle

Robert Pluim
>>>>> On Thu, 28 Nov 2019 06:55:28 +0100, Stefan Kangas <[hidden email]> said:

    Stefan> Juri Linkov <[hidden email]> writes:
    >> I'm still not sure if a fancier look is worth the trouble,
    >> especially since in some sense it's a change for the worse:
    >> it takes too much screen space, so less tabs can fit into the tab bar.
    >>
    >> Please see the difference: the first image is the current tab shapes,
    >> on the second image you can see that less tabs can be displayed
    >> on the tab bar:

    Stefan> FWIW, and this is of course highly subjective, but I think the rounded
    Stefan> style looks much better, more professional and more modern.  The
    Stefan> trade-off with regards to screen real estate will be well worth it for
    Stefan> the default case, I think.  If we decide to go that way, we could
    Stefan> always keep the other look around as an option for those working on
    Stefan> smaller screens.

Is it possible to emulate the chrome/chromium method, where the curve
of the active tab covers the inactive tabs to the right/left? That
solves the spacing issue.


chrome-tab.png (910 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Starting the Emacs 27 release cycle

VanL
Robert Pluim <[hidden email]> writes:

>     Stefan> FWIW, and this is of course highly subjective, but I think the rounded
>     Stefan> style looks much better, more professional and more modern.  The
>
> Is it possible to emulate the chrome/chromium method, where the curve
> of the active tab covers the inactive tabs to the right/left? That
> solves the spacing issue.

The fashion for the moment is the Tesla Cybertruck low polygon count laser
look.  Browsers discontinued the stretched bell curve tab-look some time
ago.

--
© 2019 VanL
gpg using EEF2 37E9 3840 0D5D 9183  251E 9830 384E 9683 B835
          'If the bug bites,don't fight it.' -Nancy S. Steinhardt


Reply | Threaded
Open this post in threaded view
|

Re: Starting the Emacs 27 release cycle

Juri Linkov-2
>>     Stefan> FWIW, and this is of course highly subjective, but I think the rounded
>>     Stefan> style looks much better, more professional and more modern.  The
>>
>> Is it possible to emulate the chrome/chromium method, where the curve
>> of the active tab covers the inactive tabs to the right/left? That
>> solves the spacing issue.
>
> The fashion for the moment is the Tesla Cybertruck low polygon count laser
> look.  Browsers discontinued the stretched bell curve tab-look some time
> ago.

Exactly my thoughts - functional design is trending.

12