[ANNOUNCEMENT] emacs 28.0.60-1.f7e6c199bf (TEST)

[ANNOUNCEMENT] emacs 28.0.60-1.f7e6c199bf (TEST)

[Ken Brown via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution
as test releases:

* emacs-28.0.60-1.f7e6c199bf
* emacs-common-28.0.60-1.f7e6c199bf
* emacs-X11-28.0.60-1.f7e6c199bf
* emacs-w32-28.0.60-1.f7e6c199bf
* emacs-lucid-28.0.60-1.f7e6c199bf

Emacs is a powerful, customizable, self-documenting, modeless text
editor.  Emacs contains special code editing features, a scripting
language (elisp), and the capability to read mail, news, and more
without leaving the editor.

This is a *very* preliminary pretest for emacs-28.1.  The latter will
include a major new feature, native compilation (explained below).
The purpose of this test release is to help us figure out what changes
will be needed (on both the Cygwin side and the Emacs side) to make
native compilation work well on Cygwin.

This test release includes an attempted workaround for the problem
reported here with the previous test release:

   https://cygwin.com/pipermail/cygwin/2021-October/249575.html

The test release is not recommended for 32-bit Cygwin.  If you try it,
you will almost certainly see fork errors while running emacs.  Once
we get native compilation working well on 64-bit Cygwin, we'll see
what can be done for the 32-bit case.

If you want to try this test release, please do the following:

1. Install the test release of the _autorebase package.

2. Create a file /var/lib/rebase/userpath.d/<username> with one line,
which is the absolute path to ~/.emacs.d/eln-cache.  For example, on
my system I have:

$ cat /var/lib/rebase/userpath.d/kbrown
/home/kbrown/.emacs.d/eln-cache

If more than one user will be using Emacs on your system, create a
file like this for each user.

Here is the promised explanation of native compilation:

Many of the editing commands used in Emacs are defined in elisp
libraries (*.el files).  To make Emacs run faster, these libraries are
usually compiled to architecture-independent *.elc files, containing
"byte-code" representations of the functions in the original files.
These byte-code functions are interpreted by the Emacs "byte-code
interpreter" when they are called.

Native compilation takes this one step further by using gcc to compile
the elisp libraries to native shared libraries (like DLLs, but with an
extension .eln instead of .dll).  This results in a substantial
speed-up of Emacs.

Some of the .eln files are created at build time.  These are installed
in a subdirectory of /usr/lib/emacs/<version>/native-lisp.  Others are
created as needed and are stored by default in a subdirectory of
~/.emacs.d/eln-cache.  (You can change this default, but then you also
have to make the corresponding change to
/var/lib/rebase/userpath.d/<username>.)

Final remarks:

1. The first few times you run Emacs, it might seem slow to start.
This is because it is compiling the elisp libraries that are needed
for your init file (usually .emacs).  For the same reason, you might
see occasional pauses the first time you use a command.  But otherwise
you should see a noticeable speed-up of Emacs.

2. To prevent fork failures, the .eln files need to be rebased
occasionally, for the reasons explained here:

   https://cygwin.com/cygwin-ug-net/highlights.html#ov-hi-process-problems

This is handled by the test release of _autorebase mentioned above
every time you run setup (which you should do with no cygwin processes
running).  But it is not currently done when new .eln files are
created.  This is mostly a problem on 32-bit Cygwin and is not yet
solved.  The main purpose of this test release of Emacs is to find out
if it is likely to be a problem in the 64-bit case.

Ken Brown
Cygwin's Emacs maintainer

Re: emacs 28.0.60-1.f7e6c199bf (TEST)

[Jim Reisert AD1C]

I have noticed one slight performance issue, which may not be related
to Cygwin at all.

After creating a keyboard macro, the first time the macro is
used/called (^x^e), it does not start right away.  Subsequent uses are
as fast as expected.  Could some sort of run-time compilation going on
in the background before the keyboard macro executes the first time?

As I said, this may not be related to Cygwin at all.

-- 
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, https://www.ad1c.us

Re: emacs 28.0.60-1.f7e6c199bf (TEST)

[David Billinghurst]

On 14/10/2021 07:22, Jim Reisert AD1C wrote:
> I have noticed one slight performance issue, which may not be related
> to Cygwin at all.
>
> After creating a keyboard macro, the first time the macro is
> used/called (^x^e), it does not start right away.  Subsequent uses are
> as fast as expected.  Could some sort of run-time compilation going on
> in the background before the keyboard macro executes the first time?
>
> As I said, this may not be related to Cygwin at all.

This is mentioned in the announcement for emacs 28.0.60-1.f7e6c199bf (TEST)

    The first few times you run Emacs, it might seem slow to start. This
    is because it is compiling the elisp libraries that are needed for
    your init file (usually .emacs).  For the same reason, you might see
    occasional pauses the first time you use a command.  But otherwise
    you should see a noticeable speed-up of Emacs.

Re: emacs 28.0.60-1.f7e6c199bf (TEST)

[Jim Reisert AD1C]

> > I have noticed one slight performance issue, which may not be related
> > to Cygwin at all.
> >
> > After creating a keyboard macro, the first time the macro is
> > used/called (^x^e), it does not start right away.  Subsequent uses are
> > as fast as expected.  Could some sort of run-time compilation going on
> > in the background before the keyboard macro executes the first time?
> >
> > As I said, this may not be related to Cygwin at all.
>
> This is mentioned in the announcement for emacs 28.0.60-1.f7e6c199bf (TEST)
>
>     The first few times you run Emacs, it might seem slow to start. This
>     is because it is compiling the elisp libraries that are needed for
>     your init file (usually .emacs).  For the same reason, you might see
>     occasional pauses the first time you use a command.  But otherwise
>     you should see a noticeable speed-up of Emacs.

I'm not talking about startup or commands.  I'm talking about keyboard
macros which are not mentioned in the paragraph above.  I've already
experienced those symptoms described.

-- 
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, https://www.ad1c.us

Re: emacs 28.0.60-1.f7e6c199bf (TEST)

[Ken Brown]

On 10/14/2021 10:38 AM, Jim Reisert AD1C wrote:
>>> I have noticed one slight performance issue, which may not be related
>>> to Cygwin at all.
>>>
>>> After creating a keyboard macro, the first time the macro is
>>> used/called (^x^e), it does not start right away.  Subsequent uses are
>>> as fast as expected.  Could some sort of run-time compilation going on
>>> in the background before the keyboard macro executes the first time?
>>>
>>> As I said, this may not be related to Cygwin at all.
>>
>> This is mentioned in the announcement for emacs 28.0.60-1.f7e6c199bf (TEST)
>>
>>      The first few times you run Emacs, it might seem slow to start. This
>>      is because it is compiling the elisp libraries that are needed for
>>      your init file (usually .emacs).  For the same reason, you might see
>>      occasional pauses the first time you use a command.  But otherwise
>>      you should see a noticeable speed-up of Emacs.
> 
> I'm not talking about startup or commands.  I'm talking about keyboard
> macros which are not mentioned in the paragraph above.  I've already
> experienced those symptoms described.

I've defined a few keyboard macros and haven't noticed any delay, but they were 
very short.  Do you have a reproducible recipe?

Ken

Re: emacs 28.0.60-1.f7e6c199bf (TEST)

[Jim Reisert AD1C]

Here is a macro I use quite frequently, with a line like this:

# New Exception Call:       PD0TEST/J

The macro consists of:

- CTRL-A
- set mark
- CTRL-F until you get to the start of the field after Call:
- CTRL-W to delete the selected text
- CTRL-N to go to the start of the next line

After the macro is defined, there is a pause the next (first) time it's
used (C-x C-e).  It's speedy after that.

-- 
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, https://www.ad1c.us
<http://www.ad1c.us>

Re: emacs 28.0.60-1.f7e6c199bf (TEST)

[Ken Brown]

On 10/18/2021 3:15 PM, Jim Reisert AD1C wrote:
> Here is a macro I use quite frequently, with a line like this:
> 
> # New Exception Call:       PD0TEST/J
> 
> The macro consists of:
> 
> - CTRL-A
> - set mark
> - CTRL-F until you get to the start of the field after Call:
> - CTRL-W to delete the selected text
> - CTRL-N to go to the start of the next line
> 
> After the macro is defined, there is a pause the next (first) time it's
> used (C-x C-e).  It's speedy after that.

You mean 'C-x e', not 'C-x C-e', right?

I just inserted several lines like

# New Exception Call:       PD0TEST/J

into the *scratch* buffer and defined your keyboard macro.  I didn't notice any 
delay the first time I ran it.  Might there be some other conditions necessary 
to reproduce the problem?  Is the mode of the buffer relevant?  Can you 
reproduce the problem starting from 'emacs -Q'?

Ken

Re: emacs 28.0.60-1.f7e6c199bf (TEST)

[Jim Reisert AD1C]

On Sun, Oct 24, 2021 at 2:14 PM Ken Brown wrote:

> On 10/18/2021 3:15 PM, Jim Reisert AD1C wrote:
> > Here is a macro I use quite frequently, with a line like this:
> >
> > # New Exception Call:       PD0TEST/J
> >
> > The macro consists of:
> >
> > - CTRL-A
> > - set mark
> > - CTRL-F until you get to the start of the field after Call:
> > - CTRL-W to delete the selected text
> > - CTRL-N to go to the start of the next line
> >
> > After the macro is defined, there is a pause the next (first) time it's
> > used (C-x C-e).  It's speedy after that.
>
> You mean 'C-x e', not 'C-x C-e', right?
>
> I just inserted several lines like
>
> # New Exception Call:       PD0TEST/J
>
> into the *scratch* buffer and defined your keyboard macro.  I didn't notice any
> delay the first time I ran it.  Might there be some other conditions necessary
> to reproduce the problem?  Is the mode of the buffer relevant?  Can you
> reproduce the problem starting from 'emacs -Q'?

Sorry, Ken. I should have mentioned that I have this version of
csv-mode installed.  It *is* compiling, so I don't know why subsequent
uses pause when using a newly-defined macro:

    https://elpa.gnu.org/packages/csv-mode.html

Having said all this, today I'm not seeing the problem.  So maybe
something was going awry with the macro compile.

-- 
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, https://www.ad1c.us