emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs-23 release branch


From: joakim
Subject: Re: Emacs-23 release branch
Date: Wed, 10 Mar 2010 06:58:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (gnu/linux)

Chong Yidong <address@hidden> writes:

> Stefan Monnier <address@hidden> writes:
>
>> I have just cut the release branch for Emacs-23.2.  It's at:
>>
>>    sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-23>
>> Any changes which you'd like to see in Emacs-23.x should be installed
>> there and only there (from where we will then merge it back onto the
>> trunk).
>
> Also, note that I intend to make a new pretest tomorrow, from the
> release branch.
>
> Now that the release branch has been made, please install there only
> fixes that are regressions with respect to Emacs 22.3.  If you think a
> non-regression fix should go into the branch, please ask Stefan or
> myself, or discuss on emacs-devel.
>
> Some of the changes in NEWS have yet to be documentated; if you have
> some time, help in this area would be much appreciated.
>
> As for the trunk, new features intended for Emacs 24 (and bugfixes not
> safe for Emacs 23.2) can now be checked in.  However, if the change is
> major (or if you have commit access but are not a regular contributor)
> please inform emacs-devel first.
>
> -----
>
> This is also a good point for people to chime in on their plans for
> Emacs 24.  Stefan and I have had some discussions about this; here is
> our current list of major changes that we'd like to see included:
>
> * The package manager (Tromey et al.).
>
> * Bidi support (Eli).
>
> * Better VC interaction DVCSs (Dan, etc?).
>   As an exception, we plan to backport VC improvements to Emacs 23.3.
>
> * Color-theme, or something like it.
>   (Maybe using Custom Themes?).
>
> * Concurrency? (Scrivano et al.)
>   (Even if we can't get this ready in time, it would be good to make
>   this an "experimental" compile-time option.)
>
> * Lexbind? (Miles).
>   (Miles, how realistic is it to include this?)
>
> * TTZ's experiment with SVG progress bar, abstracted into a general
>   Emacs library for embedded graphics.
>   If we can do this, I would also like to seriously consider switching
>   to SVG as the default image library, replacing our use of xpm (e.g.,
>   the inline xpm images that we use for certain buffer widgets should be
>   turned into SVG).

I have an interactive bounding box app "dragbox.el" for marking regions
in images. It would be nice if that usecase could also be covered by the
new embedded svg library.

It would also be nice if the ImageMagick patch could be included.
It would give us an extra way of rendering SVG too.

Maybe image libraries could be made pluggable, as discussed in the ffi
thread recently? I think the image library support code is already very
modular, only actual dynamic loading is missing.


> * GTK widget embedding code? (Joakim).
>   (Joakim, how realistic is it to include this?)
>   The preceding SVG widget feature might make this less necessary; I'm
>   not sure.

Its not totally unrealistic. The patch needs way more testing and code
quality assurance though, at the least. The interface isn't finished.

There are also several corner cases I've ignored for now.

Maybe it could be an experimental option, like you describe for
"concurrency" above.

> Other stuff we'd like to see happen, if possible, are:
>
> * Increased usage of the Semantic library by other parts of Emacs.

Indeed. Also more language support(I have some half baked Java support
code using Clojure I'd like to discuss (Clojure is a Lisp on top of the
Java Virtual Machine which interacts nicely with Emacs))

>
> * Improving the Customize user interface (I have some working in this
>   area that I'm going to commit soon).
>
-- 
Joakim Verona




reply via email to

[Prev in Thread] Current Thread [Next in Thread]