From: Ken Brown <kbrown@cornell.edu>
To: cygwin-announce <cygwin-announce@cygwin.com>
Subject: emacs 29.3-2 (TEST)
Date: Wed, 27 Mar 2024 17:58:00 -0400 [thread overview]
Message-ID: <43f6435e-7c21-48d6-8107-1fe355638897@cornell.edu> (raw)
The following packages have been uploaded to the Cygwin distribution as
test releases.
* emacs-29.3-2
* emacs-common-29.3-2
* emacs-basic-29.3-2
* emacs-w33-29.3-2
* emacs-gtk-29.3-2
* emacs-lucid-29.3-2
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 the same as emacs-29.3-1, but it is built with the native
compilation feature. See the announcement of emacs-29.3-1 for more
information about the release.
Here is a brief 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.
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.
The .eln files have been built with ASLR[1] enabled. The hope is that
this eliminates the fork failures (and the need to rebase) that were
present in some of the previous releases with native compilation.
If you experience a fork failure in spite of this, please make a bug
report to the mailing list. I'd also like to get feedback from people
who try the test release for a month or so and don't have any problems.
Ken
[1]
https://www.mandiant.com/resources/blog/six-facts-about-address-space-layout-randomization-on-windows
reply other threads:[~2024-03-27 21:58 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43f6435e-7c21-48d6-8107-1fe355638897@cornell.edu \
--to=kbrown@cornell.edu \
--cc=cygwin-announce@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).