Feature Freeze

Feature Freeze

[Nick Roberts]

The last three bugs that I've seen are due to changes made in the last few
days.  I don't know what problems they solved and clearly the bugs they've
introduced is more apparent than the ones they've fixed.

If the intention really is to make a release how about introducing a freeze
where *all* developers must get approval before making *any* changes?  Or
alternatively let's forget the freeze and allow any changes.  This intermediate
state is a nonsense.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Feature Freeze

[Chong Yidong]

> If the intention really is to make a release how about introducing a
> freeze where *all* developers must get approval before making *any*
> changes?

The changes to sit-for were discussed at length on this list.

Re: Feature Freeze

[Nick Roberts]

Chong Yidong writes:
 > > If the intention really is to make a release how about introducing a
 > > freeze where *all* developers must get approval before making *any*
 > > changes?
 > 
 > The changes to sit-for were discussed at length on this list.

I'm talking generally.  Fixing a bug introduced into Emacs three years ago
seems like progress.  Fixing a bug introduced three days ago doesn't.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Feature freeze

[Stefan Monnier]

Time is up!

I think it's about time we freeze the features for Emacs-25.  There are
a few things I hope can still make it into this new release, (such as
the xwidget branch (long overdue) and the dynload/modules, for example),
so the exact schedule and details are still up for discussion.

But I'll leave these decisions to someone else, because I also take this
opportunity to step down as head maintainer.

It's time for me to move on, and it's time for new blood to take
the lead.  I'm not about to disappear, but I won't be reading
emacs-devel (nor bug-gnu-emacs) at least for a while, so if you need
something from me, put me explicitly in the Cc.

Thank you all for bearing with me as head maintainer, it's been a great
ride, I hope you enjoyed it as much as I did.


        Stefan

Re: Feature freeze

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

Hey Stefan,

Wishing you success with your next venture too. It was great to have
discussions and learn from you on this list.

You will be missed. Looking forward to what new ideas are being put into
the pipeline with the help and support of the next head maintainer.

Kaushal
On Sep 21, 2015 4:43 PM, "Stefan Monnier" <monnier@iro.umontreal.ca> wrote:

> Time is up!
>
> I think it's about time we freeze the features for Emacs-25.  There are
> a few things I hope can still make it into this new release, (such as
> the xwidget branch (long overdue) and the dynload/modules, for example),
> so the exact schedule and details are still up for discussion.
>
> But I'll leave these decisions to someone else, because I also take this
> opportunity to step down as head maintainer.
>
> It's time for me to move on, and it's time for new blood to take
> the lead.  I'm not about to disappear, but I won't be reading
> emacs-devel (nor bug-gnu-emacs) at least for a while, so if you need
> something from me, put me explicitly in the Cc.
>
> Thank you all for bearing with me as head maintainer, it's been a great
> ride, I hope you enjoyed it as much as I did.
>
>
>         Stefan
>
>

[-- Attachment #2: Type: text/html, Size: 1590 bytes --]

Re: Feature freeze

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 263 bytes --]

I regularly describe to fellow programmers how vibrant the emacs project
has become.  You deserve the lion's share of the credit.  May we be blessed
with a new head maintainer as competent, creative, courteous and visionary
as you have been

Best of luck,

/john

[-- Attachment #2: Type: text/html, Size: 374 bytes --]

Re: Feature freeze

[Rasmus]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Time is up!

Cool! 

> But I'll leave these decisions to someone else, because I also take this
> opportunity to step down as head maintainer.
>
> It's time for me to move on, and it's time for new blood to take
> the lead.  I'm not about to disappear, but I won't be reading
> emacs-devel (nor bug-gnu-emacs) at least for a while, so if you need
> something from me, put me explicitly in the Cc.
>
> Thank you all for bearing with me as head maintainer, it's been a great
> ride, I hope you enjoyed it as much as I did.

Damn, I hate Mondays...  Well, best of luck!  And thanks a lot for all of
your contributions thus far and also future contributions.

Rasmus

-- 
Dobbelt-A

Re: Feature freeze

[Xue Fuqiao]

Hi Stefan,

Thanks for your great 7 years of being an elite technical leader, and
pulling Emacs forward for 10+ years!  Especially thanks for your
contributions to vc-svn, Emacs server, PCL-CVS (just like Magit for
Git!), smerge-mode and diff-mode, mpc, smie, pcase, cl-lib (CL at
runtime!), gv, nadvice (which is really easy to use) and countless
contributions to GNU ELPA, *.texi and doc strings, Unicode support,
CEDET, plus many other places all over Emacs.

Personally, I'd like to express my gratitude for your guidance and
patience, which makes me more proficient in Emacs development.  Wish you
success with your next venture!

Re: Feature freeze

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Mon, 21 Sep 2015 15:39:55 -0400
> 
> It's time for me to move on, and it's time for new blood to take
> the lead.  I'm not about to disappear, but I won't be reading
> emacs-devel (nor bug-gnu-emacs) at least for a while, so if you need
> something from me, put me explicitly in the Cc.
> 
> Thank you all for bearing with me as head maintainer, it's been a great
> ride, I hope you enjoyed it as much as I did.

We did enjoy that ride, and you _will_ be missed.  Thank you for those
wonderful years, and I hope your "infrequent" appearances here will be
more frequent.

Re: Feature freeze

[martin rudalics]

 > I also take this opportunity to step down as head maintainer.

I was afraid this would happen.

Thanks for bearing with us, martin

Re: Feature freeze

[Zack Piper]

On Mon, 21 Sep 2015 21:39:55 +0200,
Stefan Monnier wrote:
> 
> Time is up!
> 
> I think it's about time we freeze the features for Emacs-25.  There are
> a few things I hope can still make it into this new release, (such as
> the xwidget branch (long overdue) and the dynload/modules, for example),
> so the exact schedule and details are still up for discussion.

I'm looking forward to these features.

> 
> But I'll leave these decisions to someone else, because I also take this
> opportunity to step down as head maintainer.

Thank you for your hard work, and good luck in your future endeavors.

> 
> It's time for me to move on, and it's time for new blood to take
> the lead.  I'm not about to disappear, but I won't be reading
> emacs-devel (nor bug-gnu-emacs) at least for a while, so if you need
> something from me, put me explicitly in the Cc.
> 
> Thank you all for bearing with me as head maintainer, it's been a great
> ride, I hope you enjoyed it as much as I did.
> 
> 
>         Stefan
> 

Re: Feature freeze

[Aurélien Aptel]

On Mon, Sep 21, 2015 at 9:39 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> I think it's about time we freeze the features for Emacs-25.  There are
> a few things I hope can still make it into this new release, (such as
> the xwidget branch (long overdue) and the dynload/modules, for example),
> so the exact schedule and details are still up for discussion.

Yeah I would also like to have the modules in too! I'll update the
relevant thread.

> Thank you all for bearing with me as head maintainer, it's been a great
> ride, I hope you enjoyed it as much as I did.

Aww :( You will be missed.
You always took time to explain stuff when I asked dumb questions,
really appreciated that :D

Re: Feature freeze

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 144 bytes --]

Thanks for all your work and time, Stefan. You've done a brilliant job. And
thanks for dragging me onto this mess as well.

Best of luck,
Artur

[-- Attachment #2: Type: text/html, Size: 187 bytes --]

Re: Feature freeze

[Tassilo Horn]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> Thanks for all your work and time, Stefan.  You've done a brilliant
> job.

I second this.  You've been a fantastic maintainer!

> And thanks for dragging me onto this mess as well.

Oh, yes.  Thanks also for dragging Artur into this mess! :-)

Bye,
Tassilo

Re: Feature freeze

[Eric Abrahamsen]

Aurélien Aptel <aurelien.aptel+emacs@gmail.com> writes:

> On Mon, Sep 21, 2015 at 9:39 PM, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
>> I think it's about time we freeze the features for Emacs-25.  There are
>> a few things I hope can still make it into this new release, (such as
>> the xwidget branch (long overdue) and the dynload/modules, for example),
>> so the exact schedule and details are still up for discussion.
>
> Yeah I would also like to have the modules in too! I'll update the
> relevant thread.
>
>> Thank you all for bearing with me as head maintainer, it's been a great
>> ride, I hope you enjoyed it as much as I did.
>
> Aww :( You will be missed.
> You always took time to explain stuff when I asked dumb questions,
> really appreciated that :D

Amen to this. I got a lot of assistance and encouragement, and that made
the process of contributing to (and using) Emacs really pleasurable.
Thanks, and stick around.

Re: Feature freeze

[Alan Mackenzie]

Hello, Stefan.

On Mon, Sep 21, 2015 at 03:39:55PM -0400, Stefan Monnier wrote:
> Time is up!

> I think it's about time we freeze the features for Emacs-25.  There are
> a few things I hope can still make it into this new release, (such as
> the xwidget branch (long overdue) and the dynload/modules, for example),
> so the exact schedule and details are still up for discussion.

> But I'll leave these decisions to someone else, because I also take this
> opportunity to step down as head maintainer.

> It's time for me to move on, and it's time for new blood to take
> the lead.  I'm not about to disappear, but I won't be reading
> emacs-devel (nor bug-gnu-emacs) at least for a while, so if you need
> something from me, put me explicitly in the Cc.

> Thank you all for bearing with me as head maintainer, it's been a great
> ride, I hope you enjoyed it as much as I did.

Yes, all good things come to an end.  Thanks for all the hard work over
the years (and decades), and wishing you a more relaxed and less
stressful future.

We're going to miss you!

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Feature freeze

[Oleh Krehel]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Thank you all for bearing with me as head maintainer, it's been a great
> ride, I hope you enjoyed it as much as I did.

You were a great maintainer, thanks for all your work.
And best of luck in your new projects.

    Oleh

Re: Feature freeze

[Dmitry Gutov]

Hello Stefan,

On 09/21/2015 10:39 PM, Stefan Monnier wrote:

> Thank you all for bearing with me as head maintainer, it's been a great
> ride, I hope you enjoyed it as much as I did.

Thank you very much for your work, patience and fruitful discussions 
over the years (as well as the less fruitful ones, all of those are 
surely my fault).

It's hard for me to imagine Emacs development without your guiding hand, 
but I hope we'll manage somehow.

Best of luck in all your endeavors. Come back to govern anytime. ;)

Re: Feature freeze

[Paul Eggert]

On 09/21/2015 12:39 PM, Stefan Monnier wrote:
> Thank you all for bearing with me as head maintainer

It was more the other way round: you were bearing us, and doing it so 
well that we all got a little spoiled.  Thanks for the ride, and please 
don't be a stranger.

Re: Feature freeze

[Bastien]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 09/21/2015 12:39 PM, Stefan Monnier wrote:
>> Thank you all for bearing with me as head maintainer
>
> It was more the other way round: you were bearing us, and doing it so
> well that we all got a little spoiled.*

Exactly my feelings.  *Thanks* Stefan!

-- 
 Bastien

Re: Feature freeze

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 383 bytes --]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

Hi Stefan,

> I'll leave these decisions to someone else, because I also take this
> opportunity to step down as head maintainer.

I'm wondering how it will work from there.  Will you look for a new head
maintainer, or is this task up to somebody else?  Or maybe we already
have a new head maintainer and I missed it?

Cheers,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: Feature freeze

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

We need a new Emacs maintainer (better, two).  I have asked Stefan to
help recruit the new maintainers and work with them in a transition.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Feature freeze

[Leo Liu]

On 2015-09-22 03:39 +0800, Stefan Monnier wrote:
> Thank you all for bearing with me as head maintainer, it's been a great
> ride, I hope you enjoyed it as much as I did.

Stefan, thanks for the generous contribution to emacs which has become
my favourite development environment. Thanks also for teaching me many
things emacs ;)

Leo

Re: Feature freeze

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 266 bytes --]

On 09/21/2015 12:39 PM, Stefan Monnier wrote:
> But I'll leave these decisions to someone else, because I also take this
> opportunity to step down as head maintainer.

Thanks for your hard work and numerous improvements to Emacs. Good luck
with everything!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Feature freeze

[John Wiegley]

>>>>> Daniel Colascione <dancol@dancol.org> writes:

> On 09/21/2015 12:39 PM, Stefan Monnier wrote:
>> But I'll leave these decisions to someone else, because I also take this
>> opportunity to step down as head maintainer.

> Thanks for your hard work and numerous improvements to Emacs. Good luck with
> everything!

Indeed, Stefan, I can't thank you enough. Emacs is the center of my electronic
life!

John

Re: Feature freeze

[joakim]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Time is up!
>
> I think it's about time we freeze the features for Emacs-25.  There are
> a few things I hope can still make it into this new release, (such as
> the xwidget branch (long overdue) and the dynload/modules, for example),
> so the exact schedule and details are still up for discussion.

It would be pretty nice to finally merge the Xwidget branch.

I'm not sure how to proceed though. I'm pretty swamped with work at the
moment, and I would likely need some assistance.

> But I'll leave these decisions to someone else, because I also take this
> opportunity to step down as head maintainer.
>
> It's time for me to move on, and it's time for new blood to take
> the lead.  I'm not about to disappear, but I won't be reading
> emacs-devel (nor bug-gnu-emacs) at least for a while, so if you need
> something from me, put me explicitly in the Cc.
>
> Thank you all for bearing with me as head maintainer, it's been a great
> ride, I hope you enjoyed it as much as I did.
>
>
>         Stefan
>

-- 
Joakim Verona

Feature freeze

[Stefan Monnier]

The trunk is now officially "frozen for new features".
IOW, feel free to keep installing bug-fixes, manual updates, and things
like that, but refrain from installing changes that introduce new
features.


        Stefan

Re: Feature freeze

[Dmitry Gutov]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> The trunk is now officially "frozen for new features".
> IOW, feel free to keep installing bug-fixes, manual updates, and things
> like that, but refrain from installing changes that introduce new
> features.

Is it too late to install the "make electric-pair-mode smarter/more
useful" patch? It's been discussed for some time.

Re: Feature freeze

[Leo Liu]

On 2013-12-24 12:49 +0800, Dmitry Gutov wrote:
> Is it too late to install the "make electric-pair-mode smarter/more
> useful" patch? It's been discussed for some time.

I also wish it applied.

Leo

Re: Feature freeze

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 463 bytes --]

I'm also in favour of installing the electric-pair-mode patch. It will be a
big improvement for newcomers who are unlikely to use a third-party
alternative (at least not from day 1).


On 24 December 2013 08:08, Leo Liu <sdl.web@gmail.com> wrote:

> On 2013-12-24 12:49 +0800, Dmitry Gutov wrote:
> > Is it too late to install the "make electric-pair-mode smarter/more
> > useful" patch? It's been discussed for some time.
>
> I also wish it applied.
>
> Leo
>
>

[-- Attachment #2: Type: text/html, Size: 890 bytes --]

Re: Feature freeze

[Stefan Monnier]

>> The trunk is now officially "frozen for new features".
>> IOW, feel free to keep installing bug-fixes, manual updates, and things
>> like that, but refrain from installing changes that introduce new
>> features.
> Is it too late to install the "make electric-pair-mode smarter/more
> useful" patch? It's been discussed for some time.

No, this one is "already accepted", so it can be installed.


        Stfean

Re: Feature freeze

[João Távora]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>> The trunk is now officially "frozen for new features".
>>> IOW, feel free to keep installing bug-fixes, manual updates, and things
>>> like that, but refrain from installing changes that introduce new
>>> features.
>> Is it too late to install the "make electric-pair-mode smarter/more
>> useful" patch? It's been discussed for some time.
>
> No, this one is "already accepted", so it can be installed.

I can do it myself if someone grants me write permission on Savannah.

BTW that could also help with the (unrelated) synch'ing of yasnippet's
upstream and GNU ELPA's.

João

Re: Feature freeze

[Stefan Monnier]

> I can do it myself if someone grants me write permission on Savannah.

Good idea.  Please request membership in the "emacs" group from your
savannah account,


        Stefan

Re: Feature freeze

[João Távora]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> I can do it myself if someone grants me write permission on Savannah.
>
> Good idea.  Please request membership in the "emacs" group from your
> savannah account,

So I did and I commited the new features in revno: 115759. Have a look
and tell me how much I messed up :-) Not much I hope...

João

Re: Feature freeze

[João Távora]

>>> I can do it myself if someone grants me write permission on Savannah.
>> Good idea.  Please request membership in the "emacs" group from your
>> savannah account,
> So I did and I commited the new features in revno: 115759. Have a look
> and tell me how much I messed up :-) Not much I hope...

Two things:

* Somehow my patch didn't make it to emacs-diffs, but bzr log reports
  it.

  However, and curiously, I can see it parenting a revision pushed shortly
  thereafter, http://thread.gmane.org/gmane.emacs.diffs/123754.

  Did anything funny happen? I followed the instructions at
  http://www.emacswiki.org/emacs/BzrForEmacsDevs#toc11.

* I noticed only now that the new tests for the "autowrapping"
  functionality in test/automated/electric-tests.el (i.e. the ones that
  use `region-active-p') are broken, but only when run from "make
  check", a target that I became aware of just now.

  Should these be skipped in that situation?

João

Re: Feature freeze

[Eli Zaretskii]

> From: joaotavora@gmail.com (João Távora)
> Date: Thu, 26 Dec 2013 23:46:01 +0000
> Cc: emacs-devel@gnu.org, João Távora <joaot@siscog.pt>,
> 	Dmitry Gutov <dgutov@yandex.ru>
> 
> * Somehow my patch didn't make it to emacs-diffs, but bzr log reports
>   it.

emacs-diffs is a moderated list, so messages by non-members get held
until approved by the moderator (who is a human, and needs to sleep
from time to time).

>   However, and curiously, I can see it parenting a revision pushed shortly
>   thereafter, http://thread.gmane.org/gmane.emacs.diffs/123754.
> 
>   Did anything funny happen? I followed the instructions at
>   http://www.emacswiki.org/emacs/BzrForEmacsDevs#toc11.

Nothing funny, thank you.  Your commit was delivered to the repository
as expected, but the email message to emacs-diffs, generated by bzr on
your behalf, was held (until a few minutes ago).

Re: Feature freeze

[Dmitry Gutov]

On 27.12.2013 00:16, João Távora wrote:
> So I did and I commited the new features in revno: 115759. Have a look
> and tell me how much I messed up :-) Not much I hope...

Works quite well so far, thank you.

The commit not showing up in emacs-diffs is weird, though. I've seen my 
commits appear out of order, but they did show up eventually.

Re: Feature freeze

[David Engster]

Stefan Monnier writes:
> The trunk is now officially "frozen for new features".
> IOW, feel free to keep installing bug-fixes, manual updates, and things
> like that, but refrain from installing changes that introduce new
> features.

I would very much like to get the better help support for EIEIO methods
and classes in the next release. We discussed it here in February:

http://thread.gmane.org/gmane.emacs.devel/156807

I got sidetracked at that time, but I'm currently working it. The
essential functionality won't change, though: the main work is done in
eieio.el and eieio-opt.el. The only things that get's added to
help-fns.el is the new `help-fns-describe-function-functions' hook.

Would it be OK to apply it in the coming days?

Also, I'd like to do another sync from CEDET upstream, but AFAICS that's
only bugfixes.

-David

Re: Feature freeze

[Stefan Monnier]

> I got sidetracked at that time, but I'm currently working it. The
> essential functionality won't change, though: the main work is done in
> eieio.el and eieio-opt.el. The only things that get's added to
> help-fns.el is the new `help-fns-describe-function-functions' hook.
> Would it be OK to apply it in the coming days?

I remember discussions around that, yes.  Send us the patch and we'll
see if that can be installed.

> Also, I'd like to do another sync from CEDET upstream, but AFAICS that's
> only bugfixes.

If it's only bug-fixes then it's fine, yes.


        Stefan

Re: Feature freeze

[David Engster]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

Stefan Monnier writes:
>> I got sidetracked at that time, but I'm currently working it. The
>> essential functionality won't change, though: the main work is done in
>> eieio.el and eieio-opt.el. The only things that get's added to
>> help-fns.el is the new `help-fns-describe-function-functions' hook.
>> Would it be OK to apply it in the coming days?
>
> I remember discussions around that, yes.  Send us the patch and we'll
> see if that can be installed.

Much to my surprise I didn't get much done over the holidays, but
anyway, here it is.

The patch looks large, but as you can see, most of the stuff is just for
displaying the class/constructor/slot descriptions. The real core of the
patch is, as I've written above, the new hook in help-fns.el.

Is it OK to install, or will it have to wait?

-David


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: eieio-help-fns-patch.diff --]
[-- Type: text/x-diff, Size: 16935 bytes --]

=== modified file 'lisp/emacs-lisp/eieio-opt.el'
--- lisp/emacs-lisp/eieio-opt.el	2014-01-01 07:43:34 +0000
+++ lisp/emacs-lisp/eieio-opt.el	2014-01-06 21:32:16 +0000
@@ -77,101 +77,76 @@
 ;;;###autoload(defalias 'describe-class 'eieio-describe-class)
 
 ;;;###autoload
-(defun eieio-describe-class (class &optional headerfcn)
+(defun eieio-describe-class (class)
   "Describe a CLASS defined by a string or symbol.
-If CLASS is actually an object, then also display current values of that object.
-Optional HEADERFCN should be called to insert a few bits of info first."
-  (interactive (list (eieio-read-class "Class: ")))
-  (with-output-to-temp-buffer (help-buffer) ;"*Help*"
-    (help-setup-xref (list #'eieio-describe-class class headerfcn)
-		     (called-interactively-p 'interactive))
-
-    (when headerfcn (funcall headerfcn))
-    (prin1 class)
-    (princ " is a")
-    (if (class-option class :abstract)
-	(princ "n abstract"))
-    (princ " class")
-    ;; Print file location
-    (when (get class 'class-location)
-      (princ " in `")
-      (princ (file-name-nondirectory (get class 'class-location)))
-      (princ "'"))
-    (terpri)
-    ;; Inheritance tree information
-    (let ((pl (eieio-class-parents class)))
-      (when pl
-	(princ " Inherits from ")
-	(while pl
-	  (princ "`") (prin1 (car pl)) (princ "'")
-	  (setq pl (cdr pl))
-	  (if pl (princ ", ")))
-	(terpri)))
-    (let ((ch (eieio-class-children class)))
-      (when ch
-	(princ " Children ")
-	(while ch
-	  (princ "`") (prin1 (car ch)) (princ "'")
-	  (setq ch (cdr ch))
-	  (if ch (princ ", ")))
-	(terpri)))
-    (terpri)
-    ;; System documentation
-    (let ((doc (documentation-property class 'variable-documentation)))
-      (when doc
-	(princ "Documentation:")
-	(terpri)
-	(princ doc)
-	(terpri)
-	(terpri)))
-    ;; Describe all the slots in this class
-    (eieio-describe-class-slots class)
-    ;; Describe all the methods specific to this class.
-    (let ((methods (eieio-all-generic-functions class))
-	  (doc nil))
-      (if (not methods) nil
-	(princ "Specialized Methods:")
-	(terpri)
-	(terpri)
-	(while methods
-	  (setq doc (eieio-method-documentation (car methods) class))
-	  (princ "`")
-	  (prin1 (car methods))
-	  (princ "'")
-	  (if (not doc)
-	      (princ "  Undocumented")
-	    (if (car doc)
-		(progn
-		  (princ "  :STATIC ")
-		  (prin1 (car (car doc)))
-		  (terpri)
-		  (princ (cdr (car doc)))))
-	    (setq doc (cdr doc))
-	    (if (car doc)
-		(progn
-		  (princ "  :BEFORE ")
-		  (prin1 (car (car doc)))
-		  (terpri)
-		  (princ (cdr (car doc)))))
-	    (setq doc (cdr doc))
-	    (if (car doc)
-		(progn
-		  (princ "  :PRIMARY ")
-		  (prin1 (car (car doc)))
-		  (terpri)
-		  (princ (cdr (car doc)))))
-	    (setq doc (cdr doc))
-	    (if (car doc)
-		(progn
-		  (princ "  :AFTER ")
-		  (prin1 (car (car doc)))
-		  (terpri)
-		  (princ (cdr (car doc)))))
-	    (terpri)
-	    (terpri))
-	  (setq methods (cdr methods))))))
-  (with-current-buffer (help-buffer)
-    (buffer-string)))
+If CLASS is actually an object, then also display current values of that object."
+  ;; Header line
+  (prin1 class)
+  (insert " is a"
+	  (if (class-option class :abstract)
+	      "n abstract"
+	    "")
+	  " class")
+  (let ((location (get class 'class-location)))
+    (when location
+      (insert " in `")
+      (help-insert-xref-button
+       (file-name-nondirectory location)
+       'eieio-class-def class location)
+      (insert "'")))
+  (insert ".\n")
+  ;; Parents
+  (let ((pl (eieio-class-parents class))
+	cur)
+    (when pl
+      (insert " Inherits from ")
+      (while (setq cur (pop pl))
+	(insert "`")
+	(help-insert-xref-button (symbol-name cur)
+				 'help-function cur)
+	(insert (if pl "', " "'")))
+      (insert ".\n")))
+  ;; Children
+  (let ((ch (eieio-class-children class))
+	cur)
+    (when ch
+      (insert " Children ")
+      (while (setq cur (pop ch))
+	(insert "`")
+	(help-insert-xref-button (symbol-name cur)
+				 'help-function cur)
+	(insert (if ch "', " "'")))
+      (insert ".\n")))
+  ;; System documentation
+  (let ((doc (documentation-property class 'variable-documentation)))
+    (when doc
+      (insert "\n" doc "\n\n")))
+  ;; Describe all the slots in this class
+  (eieio-describe-class-slots class)
+  ;; Describe all the methods specific to this class.
+  (let ((methods (eieio-all-generic-functions class))
+	(type [":STATIC" ":BEFORE" ":PRIMARY" ":AFTER"])
+	counter doc argshl dochl)
+    (when methods
+      (insert (propertize "Specialized Methods:\n\n" 'face 'bold))
+      (while methods
+	(setq doc (eieio-method-documentation (car methods) class))
+	(insert "`")
+	(help-insert-xref-button (symbol-name (car methods))
+				 'help-function (car methods))
+	(insert "'")
+	(if (not doc)
+	    (insert "  Undocumented")
+	  (setq counter 0)
+	  (dolist (cur doc)
+	    (when cur
+	      (insert " " (aref type counter) " "
+		      (prin1-to-string (car cur) (current-buffer))
+		      "\n"
+		      (cdr cur)))
+	    (setq counter (1+ counter))))
+	(insert "\n\n")
+	(setq methods (cdr methods))))))
 
 (defun eieio-describe-class-slots (class)
   "Describe the slots in CLASS.
@@ -185,28 +160,27 @@
 	 (i      0)
 	 (prot   (eieio--class-protection cv))
 	 )
-    (princ "Instance Allocated Slots:")
-    (terpri)
-    (terpri)
+    (insert (propertize "Instance Allocated Slots:\n\n"
+			'face 'bold))
     (while names
-      (if (car prot) (princ "Private "))
-      (princ "Slot: ")
-      (prin1 (car names))
-      (when (not (eq (aref types i) t))
-	(princ "    type = ")
-	(prin1 (aref types i)))
-      (unless (eq (car deflt) eieio-unbound)
-	(princ "    default = ")
-	(prin1 (car deflt)))
-      (when (car publp)
-	(princ "    printer = ")
-	(prin1 (car publp)))
-      (when (car docs)
-	(terpri)
-	(princ "  ")
-	(princ (car docs))
-	(terpri))
-      (terpri)
+      (insert
+       (concat
+	(when (car prot)
+	  (propertize "Private " 'face 'bold))
+	(propertize "Slot: " 'face 'bold)
+	(prin1-to-string (car names))
+	(unless (eq (aref types i) t)
+	  (concat "    type = "
+		  (prin1-to-string (aref types i))))
+	(unless (eq (car deflt) eieio-unbound)
+	  (concat "    default = "
+		  (prin1-to-string (car deflt))))
+	(when (car publp)
+	  (concat "    printer = "
+		  (prin1-to-string (car publp))))
+	(when (car docs)
+	  (concat "\n  " (car docs) "\n"))
+	"\n"))
       (setq names (cdr names)
 	    docs (cdr docs)
 	    deflt (cdr deflt)
@@ -219,61 +193,30 @@
 	  i     0
 	  prot  (eieio--class-class-allocation-protection cv))
     (when names
-	(terpri)
-	(princ "Class Allocated Slots:"))
-	(terpri)
-	(terpri)
+      (insert (propertize "\nClass Allocated Slots:\n\n" 'face 'bold)))
     (while names
-      (when (car prot)
-	(princ "Private "))
-      (princ "Slot: ")
-      (prin1 (car names))
-      (unless (eq (aref types i) t)
-	(princ "    type = ")
-	(prin1 (aref types i)))
-      (condition-case nil
-	  (let ((value (eieio-oref class (car names))))
-	    (princ "   value = ")
-	    (prin1 value))
+      (insert
+       (concat
+	(when (car prot)
+	  "Private ")
+	"Slot: "
+	(prin1-to-string (car names))
+	(unless (eq (aref types i) t)
+	  (concat "    type = "
+		  (prin1-to-string (aref types i))))
+	(condition-case nil
+	    (let ((value (eieio-oref class (car names))))
+	      (concat "   value = "
+		      (prin1-to-string value)))
 	  (error nil))
-      (when (car docs)
-	(terpri)
-	(princ "  ")
-	(princ (car docs))
-	(terpri))
-      (terpri)
+	(when (car docs)
+	  (concat "\n\n " (car docs) "\n"))
+	"\n"))
       (setq names (cdr names)
 	    docs (cdr docs)
 	    prot (cdr prot)
 	    i (1+ i)))))
 
-;;;###autoload
-(defun eieio-describe-constructor (fcn)
-  "Describe the constructor function FCN.
-Uses `eieio-describe-class' to describe the class being constructed."
-  (interactive
-   ;; Use eieio-read-class since all constructors have the same name as
-   ;; the class they create.
-   (list (eieio-read-class "Class: ")))
-  (eieio-describe-class
-   fcn (lambda ()
-	 ;; Describe the constructor part.
-	 (prin1 fcn)
-	 (princ " is an object constructor function")
-	 ;; Print file location
-	 (when (get fcn 'class-location)
-	   (princ " in `")
-	   (princ (file-name-nondirectory (get fcn 'class-location)))
-	   (princ "'"))
-	 (terpri)
-	 (princ "Creates an object of class ")
-	 (prin1 fcn)
-	 (princ ".")
-	 (terpri)
-	 (terpri)
-	 ))
-  )
-
 (defun eieio-build-class-list (class)
   "Return a list of all classes that inherit from CLASS."
   (if (class-p class)
@@ -330,87 +273,99 @@
 ;;;###autoload(defalias 'describe-generic 'eieio-describe-generic)
 (defalias 'eieio-describe-method 'eieio-describe-generic)
 
-;;;###autoload
-(defun eieio-describe-generic (generic)
-  "Describe the generic function GENERIC.
-Also extracts information about all methods specific to this generic."
-  (interactive (list (eieio-read-generic "Generic Method: ")))
-  (eieio--check-type generic-p generic)
-  (with-output-to-temp-buffer (help-buffer) ; "*Help*"
-    (help-setup-xref (list #'eieio-describe-generic generic)
-		     (called-interactively-p 'interactive))
-
-    (prin1 generic)
-    (princ " is a generic function")
-    (when (generic-primary-only-p generic)
-      (princ " with only ")
-      (when (generic-primary-only-one-p generic)
-	(princ "one "))
-      (princ "primary method")
-      (when (not (generic-primary-only-one-p generic))
-	(princ "s"))
-      )
-    (princ ".")
-    (terpri)
-    (terpri)
-    (let ((d (documentation generic)))
-      (if (not d)
-	  (princ "The generic is not documented.\n")
-	(princ "Documentation:")
-	(terpri)
-	(princ d)
-	(terpri)
-	(terpri)))
-    (princ "Implementations:")
-    (terpri)
-    (terpri)
-    (let ((i 4)
-	  (prefix [ ":STATIC" ":BEFORE" ":PRIMARY" ":AFTER" ] ))
-      ;; Loop over fanciful generics
-      (while (< i 7)
-	(let ((gm (aref (get generic 'eieio-method-tree) i)))
-	  (when gm
-	    (princ "Generic ")
-	    (princ (aref prefix (- i 3)))
-	    (terpri)
-	    (princ (or (nth 2 gm) "Undocumented"))
-	    (terpri)
-	    (terpri)))
-	(setq i (1+ i)))
-      (setq i 0)
-      ;; Loop over defined class-specific methods
-      (while (< i 4)
-	(let ((gm (reverse (aref (get generic 'eieio-method-tree) i)))
-	      location)
-	  (while gm
-	    (princ "`")
-	    (prin1 (car (car gm)))
-	    (princ "'")
-	    ;; prefix type
-	    (princ " ")
-	    (princ (aref prefix i))
-	    (princ " ")
-	    ;; argument list
-	    (let* ((func (cdr (car gm)))
-		   (arglst (eieio-lambda-arglist func)))
-	      (prin1 arglst))
-	    (terpri)
-	    ;; 3 because of cdr
-	    (princ (or (documentation (cdr (car gm)))
-		       "Undocumented"))
-	    ;; Print file location if available
-	    (when (and (setq location (get generic 'method-locations))
-		       (setq location (assoc (caar gm) location)))
-	      (setq location (cadr location))
-	      (princ "\n\nDefined in `")
-	      (princ (file-name-nondirectory location))
-	      (princ "'\n"))
-	    (setq gm (cdr gm))
-	    (terpri)
-	    (terpri)))
-	(setq i (1+ i)))))
-  (with-current-buffer (help-buffer)
-    (buffer-string)))
+(define-button-type 'eieio-method-def
+  :supertype 'help-xref
+  'help-function (lambda (class method file)
+		   (eieio-help-find-method-definition class method file))
+  'help-echo (purecopy "mouse-2, RET: find method's definition"))
+
+(define-button-type 'eieio-class-def
+  :supertype 'help-xref
+  'help-function (lambda (class file)
+		   (eieio-help-find-class-definition class file))
+  'help-echo (purecopy "mouse-2, RET: find class definition"))
+
+;;;###autoload
+(defun eieio-help-constructor (ctr)
+  "Describe CTR if it is a class constructor."
+  (when (class-p ctr)
+    (let ((location (get ctr 'class-location)))
+      (goto-char (point-min))
+      (delete-region (point) (point-at-eol))
+      (prin1 ctr)
+      (insert " is an object constructor function in `")
+      (help-insert-xref-button
+       (file-name-nondirectory location)
+       'eieio-class-def ctr location)
+      (insert "'.\nCreates an object of class " (symbol-name ctr) ".")
+      (goto-char (point-max))
+      (save-excursion
+	(insert (propertize "\n\nClass description:\n" 'face 'bold))
+	(eieio-describe-class ctr))
+      )))
+
+
+;;;###autoload
+(defun eieio-help-generic (generic)
+  "Describe GENERIC if it is a generic function."
+  (when (generic-p generic)
+    (save-excursion
+      (goto-char (point-min))
+      (when (re-search-forward " in `.+'.$" nil t)
+	(replace-match ".")))
+    (save-excursion
+      (insert "\n\nThis is a generic function"
+	      (cond
+	       ((and (generic-primary-only-p generic)
+		     (generic-primary-only-one-p generic))
+		" with only one primary method")
+	       ((generic-primary-only-p generic)
+		" with only primary methods")
+	       (t ""))
+	      ".\n\n")
+      (insert (propertize "Implementations:\n\n" 'face 'bold))
+      (let ((i 4)
+	    (prefix [ ":STATIC" ":BEFORE" ":PRIMARY" ":AFTER" ] ))
+	;; Loop over fanciful generics
+	(while (< i 7)
+	  (let ((gm (aref (get generic 'eieio-method-tree) i)))
+	    (when gm
+	      (insert "Generic "
+		      (aref prefix (- i 3))
+		      "\n"
+		      (or (nth 2 gm) "Undocumented")
+		      "\n\n")))
+	  (setq i (1+ i)))
+	(setq i 0)
+	;; Loop over defined class-specific methods
+	(while (< i 4)
+	  (let* ((gm (reverse (aref (get generic 'eieio-method-tree) i)))
+		 cname location)
+	    (while gm
+	      (setq cname (caar gm))
+	      (insert "`")
+	      (help-insert-xref-button (symbol-name cname)
+				       'help-variable cname)
+	      (insert "' " (aref prefix i) " ")
+	      ;; argument list
+	      (let* ((func (cdr (car gm)))
+		     (arglst (eieio-lambda-arglist func)))
+		(prin1 arglst (current-buffer)))
+	      (insert "\n"
+		      (or (documentation (cdr (car gm)))
+			  "Undocumented"))
+	      ;; Print file location if available
+	      (when (and (setq location (get generic 'method-locations))
+			 (setq location (assoc cname location)))
+		(setq location (cadr location))
+		(insert "\n\nDefined in `")
+		(help-insert-xref-button
+		 (file-name-nondirectory location)
+		 'eieio-method-def cname generic location)
+		(insert "'\n"))
+	      (setq gm (cdr gm))
+	      (insert "\n")))
+	  (setq i (1+ i)))))))
 
 (defun eieio-lambda-arglist (func)
   "Return the argument list of FUNC, a function body."
@@ -584,21 +539,13 @@
 
 ;;; HELP AUGMENTATION
 ;;
-(define-button-type 'eieio-method-def
-  :supertype 'help-xref
-  'help-function (lambda (class method file)
-		   (eieio-help-find-method-definition class method file))
-  'help-echo (purecopy "mouse-2, RET: find method's definition"))
-
-(define-button-type 'eieio-class-def
-  :supertype 'help-xref
-  'help-function (lambda (class file)
-		   (eieio-help-find-class-definition class file))
-  'help-echo (purecopy "mouse-2, RET: find class definition"))
-
 (defun eieio-help-find-method-definition (class method file)
   (let ((filename (find-library-name file))
 	location buf)
+    (when (symbolp class)
+      (setq class (symbol-name class)))
+    (when (symbolp method)
+      (setq method (symbol-name method)))
     (when (null filename)
       (error "Cannot find library %s" file))
     (setq buf (find-file-noselect filename))
@@ -622,6 +569,8 @@
       (beginning-of-line))))
 
 (defun eieio-help-find-class-definition (class file)
+  (when (symbolp class)
+    (setq class (symbol-name class)))
   (let ((filename (find-library-name file))
 	location buf)
     (when (null filename)

=== modified file 'lisp/emacs-lisp/eieio.el'
--- lisp/emacs-lisp/eieio.el	2014-01-01 07:43:34 +0000
+++ lisp/emacs-lisp/eieio.el	2014-01-04 09:04:08 +0000
@@ -865,6 +865,10 @@
 of `eq'."
   (error "EIEIO: `change-class' is unimplemented"))
 
+;; Hook ourselves into help system for describing classes and methods.
+(add-hook 'help-fns-describe-function-functions 'eieio-help-generic)
+(add-hook 'help-fns-describe-function-functions 'eieio-help-constructor)
+
 ;;; Interfacing with edebug
 ;;
 (defun eieio-edebug-prin1-to-string (object &optional noescape)

=== modified file 'lisp/help-fns.el'
--- lisp/help-fns.el	2014-01-01 07:43:34 +0000
+++ lisp/help-fns.el	2014-01-04 09:04:08 +0000
@@ -32,6 +32,12 @@
 
 ;;; Code:
 
+(defvar help-fns-describe-function-functions nil
+  "List of functions to run in help buffer in `describe-function'.
+Those functions will be run after the header line and argument
+list was inserted, and before the documentation will be inserted.
+The functions will receive the function name as argument.")
+
 ;; Functions
 
 ;;;###autoload
@@ -653,7 +659,7 @@
           (help-fns--compiler-macro function)
           (help-fns--parent-mode function)
           (help-fns--obsolete function)
-
+	  (run-hook-with-args 'help-fns-describe-function-functions function)
           (insert "\n"
                   (or doc "Not documented.")))))))
 

Re: Feature freeze

[Stefan Monnier]

> Is it OK to install, or will it have to wait?

Looks OK.  Please install, tho see nitpicks below.

> +  ;; Describe all the slots in this class

Please punctuate the comments (IIUC you didn't actually change this
comment, but while you're there, you might as well do it ;-).

> +(defvar help-fns-describe-function-functions nil
> +  "List of functions to run in help buffer in `describe-function'.
> +Those functions will be run after the header line and argument
> +list was inserted, and before the documentation will be inserted.
> +The functions will receive the function name as argument.")
> +
>  ;; Functions
> 
>  ;;;###autoload
> @@ -653,7 +659,7 @@
>            (help-fns--compiler-macro function)
>            (help-fns--parent-mode function)
>            (help-fns--obsolete function)
> -
> +	  (run-hook-with-args 'help-fns-describe-function-functions function)

Looks good, but please move help-fns--compiler-macro,
help-fns--parent-mode, help-fns--obsolete to
help-fns-describe-function-functions while you're there.


        Stefan

Re: Feature freeze

[David Engster]

Stefan Monnier writes:
>>  ;;;###autoload
>> @@ -653,7 +659,7 @@
>>            (help-fns--compiler-macro function)
>>            (help-fns--parent-mode function)
>>            (help-fns--obsolete function)
>> -
>> +	  (run-hook-with-args 'help-fns-describe-function-functions function)
>
> Looks good, but please move help-fns--compiler-macro,
> help-fns--parent-mode, help-fns--obsolete to
> help-fns-describe-function-functions while you're there.

Yes, will do.

One more question which I forgot to ask: I did rename
`eieio-describe-constructor' and `eieio-describe-generic' to
`eieio-help-constructor' and `eieio-help-generic', since they are not
interactive anymore but augment an existing help buffer. Those two
however had aliases `describe-constructor' and `describe-generic', which
I'd like to remove. Would that be OK? I don't think anyone was using
those, and calling the normal `describe-function' on a constructor or
generic will now give the same information.

If you'd like to keep them, I'd simply re-implement them as small
wrappers for `describe-function'.

-David

Re: Feature freeze

[Stefan Monnier]

> interactive anymore but augment an existing help buffer. Those two
> however had aliases `describe-constructor' and `describe-generic', which
> I'd like to remove. Would that be OK?

Yes, thanks,


        Stefan

Re: Feature freeze

[David Engster]

Stefan Monnier writes:
>> interactive anymore but augment an existing help buffer. Those two
>> however had aliases `describe-constructor' and `describe-generic', which
>> I'd like to remove. Would that be OK?
>
> Yes, thanks,

Pushed. I will update NEWS tomorrow.

What I didn't find out is how to update the extracted autoloads at the
end of lisp/emacs-lisp/eieio.el, so those are still wrong. 'make
autoloads' doesn't do the trick. Any hints?

-David

Re: Feature freeze

[Glenn Morris]

David Engster wrote:

> What I didn't find out is how to update the extracted autoloads at the
> end of lisp/emacs-lisp/eieio.el, so those are still wrong. 'make
> autoloads' doesn't do the trick. Any hints?

There's something weird there.
How did those autoloads get into eieio.el in the first place, when it is
not the value of any other file's generated-autoload-file setting?
(They are also in loaddefs.el, which is where `make autoloads' will
update them.)

Maybe there was such a setting at some point in the past, but it was
removed? Or were those autoloads added to eieio.el by hand?

I suggest you fix it up by hand.

Re: Feature freeze

[Glenn Morris]

Glenn Morris wrote:

> Maybe there was such a setting at some point in the past, but it was
> removed?

Yes: I intentionally added it in r103332.
It was removed it r110325 "Update CEDET from upstream".
I guess that was unintentional.

I suggest you check that revision and make any necessary fixes.


In a way, this is an autoloads bug:
If a file foo.el used to contain a file-local generated-autoload-file: bar.el
setting, but then it gets removed, the autoloads will not be removed
from bar.el.

Re: Feature freeze

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 08 Jan 2014 17:37:31 -0500
> 
> In a way, this is an autoloads bug:
> If a file foo.el used to contain a file-local generated-autoload-file: bar.el
> setting, but then it gets removed, the autoloads will not be removed
> from bar.el.

Perhaps we should fix this, either in the Makefile or maybe via some
file-local variables wizardry.

Re: Feature freeze

[David Engster]

Glenn Morris writes:
> Glenn Morris wrote:
>
>> Maybe there was such a setting at some point in the past, but it was
>> removed?
>
> Yes: I intentionally added it in r103332.
> It was removed it r110325 "Update CEDET from upstream".
> I guess that was unintentional.

Yes, that was my fault. Thanks for looking into this.

> I suggest you check that revision and make any necessary fixes.

But I guess there must be some reason why you used 'eieio.el' as
generated autoload file instead of using loaddefs.el? Is it OK to just
remove the autoloads from eieio.el and fix AUTOGEN_VCS in Makefile.in,
or should I restore it to the way it was?

-David

Re: Feature freeze

[Glenn Morris]

David Engster wrote:

> But I guess there must be some reason why you used 'eieio.el' as
> generated autoload file instead of using loaddefs.el? 

I did that because those autoloads were already in eieio.el, but
hand-written rather than auto-generated.

You know better than I where those autoloads need to be.
Do they only make sense after eieio is loaded, or are they external
access points.

Re: Feature freeze

[David Engster]

Glenn Morris writes:
> David Engster wrote:
>> But I guess there must be some reason why you used 'eieio.el' as
>> generated autoload file instead of using loaddefs.el? 
>
> I did that because those autoloads were already in eieio.el, but
> hand-written rather than auto-generated.

Ah yes, I now dimly remember writing those...

> You know better than I where those autoloads need to be.
> Do they only make sense after eieio is loaded, or are they external
> access points.

They really only make sense when EIEIO is already loaded, so I restored
the old behavior.

-David

Re: Feature freeze

[Nix]

On 6 Jan 2014, David Engster outgrape:
> Much to my surprise I didn't get much done over the holidays, but
> anyway, here it is.

As an eieio user long frustrated by the opacity caused by its poor help
integration:

Best patch so far this year! Thank you thank you!

(not that that's really saying *that* much, what with freeze and New
Year and all. But still.)

Re: Feature freeze

[Stefan Monnier]

> The trunk is now officially "frozen for new features".

BTW, the plan is to keep it frozen for a month or so, after which we'll
make a release branch and open up the trunk for changes again.


        Stefan

Re: Feature freeze

[Michael Albinus]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> The trunk is now officially "frozen for new features".
> IOW, feel free to keep installing bug-fixes, manual updates, and things
> like that, but refrain from installing changes that introduce new
> features.

Do we have a list of bug numbers, which shall be fixed before the
release? Preferred as (user) tags in debbugs or alike, that the list can
be kept up-to-date.

>         Stefan

Best regards, Michael.

Re: Feature freeze

[Stefan Monnier]

>> The trunk is now officially "frozen for new features".
>> IOW, feel free to keep installing bug-fixes, manual updates, and things
>> like that, but refrain from installing changes that introduce new
>> features.
> Do we have a list of bug numbers, which shall be fixed before the
> release? Preferred as (user) tags in debbugs or alike, that the list can
> be kept up-to-date.

No, but I encourage everyone to tag as "important" any bug that they
think should be fixed.  Of course, that should be someone else's bug.
If you think your own bug-report is important, send me an email.


        Stefan

Re: Feature freeze

[Michael Albinus]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> No, but I encourage everyone to tag as "important" any bug that they
> think should be fixed.  Of course, that should be someone else's bug.
> If you think your own bug-report is important, send me an email.

That will work fine if the bug is related to Emacs only. When it is
assigned to several packages in parallel, like Emacs and Gnus, it is not
obvious whether it must be fixed in the next Emacs release or the next
Gnus release.

But let's start with this. Conflicts in intended release versionss the
bug shall be fixed could be solved when they happen. With the debbugs
package from GNU ELPA, we get the list of bugs:

(debbugs-gnu '("serious" "important") '("emacs") nil t)

Admittedly, the last one has been submitted by me. Maybe somebody else
could check, whether the severity is proper. It is a security flaw, so I
believe it shall be fixed soon.

If one prefers the bug list as TODO items of org-mode, one could apply

(debbugs-org '("serious" "important") '("emacs") nil)

>         Stefan

Best regards, Michael.

Feature freeze

[Stefan Monnier]

If you want to install some new features in Emacs's trunk, do it now,
because the trunk will be feature-frozen starting next week-end.


        Stefan "who wouldn't want Santa to come and install some
                undiscussed new feature while we sleep"

Re: Feature freeze

[Jambunathan K]

Stefan

I would like to merge my pending changes to ox-odt.el directly to the
Emacs trunk.

A recent change in LibreOffice 4.1 is causing the documents produced by
the ODT exporter to be "un-openable".  See
http://lists.gnu.org/archive/html/emacs-orgmode/2013-12/msg00047.html

If you are interested you can send me the instruction off the list.

NOTE: In principle, I will not commit my changes to Org-mode repo.  The
rest can be negotiated.

Jambunathan K.

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> If you want to install some new features in Emacs's trunk, do it now,
> because the trunk will be feature-frozen starting next week-end.
>
>
>         Stefan "who wouldn't want Santa to come and install some
>                 undiscussed new feature while we sleep"

Re: Feature freeze

[Stefan Monnier]

> I would like to merge my pending changes to ox-odt.el directly to the
> Emacs trunk.

AFAIK, currently, you haven't signed the necessary copyright paperwork,
so we can't accept your changes.  If you want to contribute patches to
Emacs, please address this first.

As for changes to Org, you can send them via M-x report-emacs-bug or
send them to Org maintainers directly.  The Org code will be sync'd back
to Emacs (they got a special "feature freeze exemption"), so it will
work as well.


        Stefan

Re: Feature freeze

[Jambunathan K]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> I would like to merge my pending changes to ox-odt.el directly to the
>> Emacs trunk.

> If you want to contribute patches to Emacs, please address this first.

Will do (See "Conditions Apply" below).

> As for changes to Org, you can send them via M-x report-emacs-bug or
> send them to Org maintainers directly.  The Org code will be sync'd back
> to Emacs (they got a special "feature freeze exemption"), so it will
> work as well.

As the original author of ox-odt.el, I would like to manage the changes
directly in Emacs trunk.  I don't want to deal with any intermediaries
committing changes on my behalf.

Re: Feature freeze

[Glenn Morris]

Stefan Monnier wrote:

> The Org code will be sync'd back to Emacs (they got a special "feature
> freeze exemption")

Any special reason for this exception?
Is it just "lives in an external repo and is big"?
Because there were large non-bugfix Org mode changes late during
the 24.3 cycle, which were so big they were basically impossible to
check, and they caused some problems:

http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00108.html

So personally I'm disappointed to see the same thing on the cards again.

Re: Feature freeze

[Stefan Monnier]

> Any special reason for this exception?
> Is it just "lives in an external repo and is big"?

Pretty much, yes.

> Because there were large non-bugfix Org mode changes late during
> the 24.3 cycle, which were so big they were basically impossible to
> check, and they caused some problems:
> http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00108.html
> So personally I'm disappointed to see the same thing on the cards again.

This "feature freeze exemption" isn't meant to imply "commit any time
you like".  Basically, what it means for me is that if/when they have
code ready to merge into Emacs, we may accept it even after the freeze,
as long as there's still enough time before the release.

E.g. installing a new version in January should be fine, February,
probably, and after that, less likely, tho it depends on how well the
release process is going.  Does that sound good enough for you?


        Stefan

Re: Feature freeze

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Mon, 16 Dec 2013 13:49:25 -0500
> Cc: emacs-devel@gnu.org
> 
> This "feature freeze exemption" isn't meant to imply "commit any time
> you like".  Basically, what it means for me is that if/when they have
> code ready to merge into Emacs, we may accept it even after the freeze,
> as long as there's still enough time before the release.

How is this different from what I might have in my local feature
branch?

Re: Feature freeze

[Stefan Monnier]

>> This "feature freeze exemption" isn't meant to imply "commit any time
>> you like".  Basically, what it means for me is that if/when they have
>> code ready to merge into Emacs, we may accept it even after the freeze,
>> as long as there's still enough time before the release.
> How is this different from what I might have in my local feature
> branch?

The code coming in from Org's repository has generally gone through some
reasonable beta-testing (and normally, the rest of Emacs
doesn't/shouldn't depend on Org's code, so a problem in Org mode
shouldn't affect the rest of the release too significantly).



        Stefan

Re: Feature freeze

[Jambunathan K]

Stefan

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> I would like to merge my pending changes to ox-odt.el directly to the
>> Emacs trunk.
>
> AFAIK, currently, you haven't signed the necessary copyright paperwork,
> so we can't accept your changes.  If you want to contribute patches to
> Emacs, please address this first.

My offer stands.

Don't hesitate to write to me if there is a felt need for having my
patches in Emacs.  I will oblige in no time.

Jambunathan K

Re: Feature freeze

[Michael Albinus]

Jambunathan K <kjambunathan@gmail.com> writes:

> I would like to merge my pending changes to ox-odt.el directly to the
> Emacs trunk.

[...]

> NOTE: In principle, I will not commit my changes to Org-mode repo.  The
> rest can be negotiated.

IIRC, you have vetoed applying any of your patches to the org-mode
project. Do you have changed your mind?

If not, I believe your patches are not applicable to Emacs proper as well.

> Jambunathan K.

Best regards, Michael.

Re: Feature freeze

[Jambunathan K]

Michael Albinus <michael.albinus@gmx.de> writes:

>> NOTE: In principle, I will not commit my changes to Org-mode repo.  The
>> rest can be negotiated.
>
> IIRC, you have vetoed applying any of your patches to the org-mode
> project.

There is no such veto.

I will not personally commit to Orgmode repo.  If the code gets merged
from Emacs repo back to Orgmode repo (by someone else) I have nothing
against it.

> Do you have changed your mind?

I have never changed my mind.

ODT exporter was created as a "donation" to Emacs.  It will remain so.
I still answer questions on the mailing list and accumulate patches in a
private repo.

Re: Feature freeze

[Michael Albinus]

Jambunathan K <kjambunathan@gmail.com> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>>> NOTE: In principle, I will not commit my changes to Org-mode repo.  The
>>> rest can be negotiated.
>>
>> IIRC, you have vetoed applying any of your patches to the org-mode
>> project.
>
> There is no such veto.
>
> I will not personally commit to Orgmode repo.  If the code gets merged
> from Emacs repo back to Orgmode repo (by someone else) I have nothing
> against it.
>
>> Do you have changed your mind?
>
> I have never changed my mind.

Then I must have misunderstood you:

"ox-odt.el/ox-freemind.el: Please remove it from Org core and don't
 distribute these files with Org."

<http://thread.gmane.org/gmane.emacs.orgmode/68127>

"I would like to remove ox-html.el from Org distribution."

<http://thread.gmane.org/gmane.emacs.orgmode/68128>

Best regards, Michael.

Re: Feature freeze

[Jambunathan K]

Michael Albinus <michael.albinus@gmx.de> writes:

> Then I must have misunderstood you:

Yes.  But you are not alone in that camp...

Re: Feature freeze

[Jambunathan K]

> "ox-odt.el/ox-freemind.el: Please remove it from Org core and don't
>  distribute these files with Org."
>
> <http://thread.gmane.org/gmane.emacs.orgmode/68127>
>
> "I would like to remove ox-html.el from Org distribution."
>
> <http://thread.gmane.org/gmane.emacs.orgmode/68128>

Irrelevant.  The code is part of Org-mode repo and it is part of Emacs.

Re: Feature freeze

[Michael Albinus]

Jambunathan K <kjambunathan@gmail.com> writes:

>> "ox-odt.el/ox-freemind.el: Please remove it from Org core and don't
>>  distribute these files with Org."
>>
>> <http://thread.gmane.org/gmane.emacs.orgmode/68127>
>>
>> "I would like to remove ox-html.el from Org distribution."
>>
>> <http://thread.gmane.org/gmane.emacs.orgmode/68128>
>
> Irrelevant.  The code is part of Org-mode repo and it is part of Emacs.

I remember you did a lot of people busy with this kind of requests. It
would be annoying to see such messages from you again, that's why I have
asked for your today's position.

Until you claim that those games are over now from your side, I would
recommend not to accept patches from you. But of course, I'm neither the
Emacs nor the Org-mode maintainer.

Best regards, Michael.

Re: Feature freeze

[Jambunathan K]

Michael Albinus <michael.albinus@gmx.de> writes:

> But of course, I'm neither the Emacs nor the Org-mode maintainer.

Yes.

Re: Feature freeze

[Juanma Barranquero]

On Tue, Dec 17, 2013 at 7:52 AM, Michael Albinus <michael.albinus@gmx.de> wrote:

> Until you claim that those games are over now from your side, I would
> recommend not to accept patches from you.

+1

Re: Feature freeze

[Jambunathan K]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Tue, Dec 17, 2013 at 7:52 AM, Michael Albinus <michael.albinus@gmx.de> wrote:
>
>> Until you claim that those games are over now from your side, I would
>> recommend not to accept patches from you.
>
> +1

What sort of absurdity is this.  You take CA or Disclaimer, you put the
patch in Emacs and forget about it.

Hint: Jambunathan K is a GIGO machine.  Next time you talk to me, try
putting in something other than Garbage.

Re: Feature freeze

[Jay Belanger]

Jambunathan K <kjambunathan@gmail.com> writes:

> Juanma Barranquero <lekktu@gmail.com> writes:
>
>> On Tue, Dec 17, 2013 at 7:52 AM, Michael Albinus <michael.albinus@gmx.de> wrote:
>>
>>> Until you claim that those games are over now from your side, I would
>>> recommend not to accept patches from you.
>>
>> +1
>
> What sort of absurdity is this.

The sort that is based on your previous behavior.

Re: Feature freeze

[Jambunathan K]

Jay Belanger <jay.p.belanger@gmail.com> writes:

> The sort that is based on your previous behavior.

What was that previous behaviour based on?  Could you summarize in your
own words why I cancelled my assignment in first place?  Let me see how
much of a context you can provide.

Jambunathan K.

Re: Feature freeze

[Jay Belanger]

> What was that previous behaviour based on?

Your immaturity, I would assume.
Since you refuse to say that your games are over now, I take it you
leave open the possibility that they might continue.

> Could you summarize in your own words why I cancelled my assignment in
> first place?

It was the hissy fit and your stated desire to cause problems that
bothered people, which were not acceptable behavior under any
circumstances.

Re: Feature freeze

[Jambunathan K]

Jay

Don't take covers.  Answer my question or leave the room.

Jambunathan K.

Jay Belanger <jay.p.belanger@gmail.com> writes:

>> What was that previous behaviour based on?
>
> Your immaturity, I would assume.
> Since you refuse to say that your games are over now, I take it you
> leave open the possibility that they might continue.
>
>> Could you summarize in your own words why I cancelled my assignment in
>> first place?
>
> It was the hissy fit and your stated desire to cause problems that
> bothered people, which were not acceptable behavior under any
> circumstances.

Re: Feature freeze

[Jay Belanger]

Jambunathan K <kjambunathan@gmail.com> writes:

> Answer my question or leave the room.

The only worthwhile question that you asked was why people were agreeing
with the statement:

>>> Until you claim that those games are over now from your side, I would
>>> recommend not to accept patches from you.

I explained why people have a problem with your behavior, but you seem
to be ignoring that, and as before, you are behaving poorly.  You seem
intent on throwing another hissy fit, and the concern that you might
again purposely try to cause problems is real.
I'll let others worry about that; as for you:
  *plonk*

Re: Feature freeze

[Jambunathan K]

Jay Belanger <jay.p.belanger@gmail.com> writes:

> I'll let others worry about that

"Better done than said"

Re: Feature freeze

[Glenn Morris]

People, please stop rising to the bait.

Re: Feature freeze

[Jambunathan K]

Glenn Morris <rgm@gnu.org> writes:

> People, please stop rising to the bait.

Knee-jerk reaction from one and all, save from some quarters.

Re: Feature freeze

[Stefan Monnier]

People, can we please move on to other things than bashing each other?
Thank you,


        Stefan

Re: Feature freeze

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

Doesn’t it make more sense to have the feature freeze in the beginning of January? Many people will take some time off work around Christmas and will probably have a bit of extra time to work on things they want to include in Emacs 24.4. I was planning to integrate ruby-tools in ruby-mode, but I’m not sure I’ll be able to do it by the end of the week.

--  
Cheers,
Bozhidar


On Sunday, December 15, 2013 at 3:35 PM, Stefan Monnier wrote:

> If you want to install some new features in Emacs's trunk, do it now,
> because the trunk will be feature-frozen starting next week-end.
>  
>  
> Stefan "who wouldn't want Santa to come and install some
> undiscussed new feature while we sleep"
>  
>  



[-- Attachment #2: Type: text/html, Size: 1413 bytes --]

bug#9031: Unused vars etc. in chartab.c, composite.c, gtkutil.c

[Paul Eggert]

This patch fixes some minor problems on the Emacs trunk.

Normally I'd just install this, but we're in a feature freeze
now and this patch doesn't fix any actual bugs, so I'm filing
a bug report instead, to record the issues.

# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: eggert@cs.ucla.edu-20110709062840-jdrk1zrclfflltae
# target_branch: bzr+ssh://eggert@bzr.savannah.gnu.org/emacs/trunk
# testament_sha1: 935c16305b271d2f38af33043c16de6e23c306ca
# timestamp: 2011-07-08 23:28:47 -0700
# base_revision_id: sdl.web@gmail.com-20110709031157-d7vix3jz1gpb29bw
# 
# Begin patch
=== modified file 'src/ChangeLog'
--- src/ChangeLog	2011-07-08 20:39:30 +0000
+++ src/ChangeLog	2011-07-09 06:28:40 +0000
@@ -1,5 +1,12 @@
 2011-07-08  Paul Eggert  <eggert@cs.ucla.edu>
 
+	Fix minor problems found by static checking.
+	* chartab.c (char_table_set_range, map_sub_char_table)
+	(uniprop_table_uncompress): Remove unused locals.
+	(uniprop_table): Now static.
+	* composite.c (_work_char): Remove unused static var.
+	* gtkutil.c (qttip_cb): Remove stray no-effect statement.
+
 	Use pthread_sigmask, not sigprocmask (Bug#9010).
 	sigprocmask is portable only for single-threaded applications, and
 	Emacs can be multi-threaded when it uses GTK.

=== modified file 'src/chartab.c'
--- src/chartab.c	2011-07-07 04:16:52 +0000
+++ src/chartab.c	2011-07-09 06:28:40 +0000
@@ -485,7 +485,6 @@
 char_table_set_range (Lisp_Object table, int from, int to, Lisp_Object val)
 {
   struct Lisp_Char_Table *tbl = XCHAR_TABLE (table);
-  Lisp_Object *contents = tbl->contents;
 
   if (from == to)
     char_table_set (table, from, val);
@@ -759,8 +758,6 @@
 		    Lisp_Object function, Lisp_Object table, Lisp_Object arg, Lisp_Object val,
 		    Lisp_Object range, Lisp_Object top)
 {
-  /* Pointer to the elements of TABLE. */
-  Lisp_Object *contents;
   /* Depth of TABLE.  */
   int depth;
   /* Minimum and maxinum characters covered by TABLE. */
@@ -777,14 +774,12 @@
       struct Lisp_Sub_Char_Table *tbl = XSUB_CHAR_TABLE (table);
 
       depth = XINT (tbl->depth);
-      contents = tbl->contents;
       min_char = XINT (tbl->min_char);
       max_char = min_char + chartab_chars[depth - 1] - 1;
     }
   else
     {
       depth = 0;
-      contents = XCHAR_TABLE (table)->contents;
       min_char = 0;
       max_char = MAX_CHAR;
     }
@@ -1143,7 +1138,6 @@
   Lisp_Object sub = make_sub_char_table (3, min_char, Qnil);
   struct Lisp_Sub_Char_Table *subtbl = XSUB_CHAR_TABLE (sub);
   const unsigned char *p, *pend;
-  int i;
 
   XSUB_CHAR_TABLE (table)->contents[idx] = sub;
   p = SDATA (val), pend = p + SBYTES (val);
@@ -1316,7 +1310,7 @@
    function may load a Lisp file and thus may cause
    garbage-collection.  */
 
-Lisp_Object
+static Lisp_Object
 uniprop_table (Lisp_Object prop)
 {
   Lisp_Object val, table, result;

=== modified file 'src/composite.c'
--- src/composite.c	2011-07-07 16:18:25 +0000
+++ src/composite.c	2011-07-09 06:28:40 +0000
@@ -967,7 +967,6 @@
 }
 
 static Lisp_Object _work_val;
-static int _work_char;
 
 /* 1 iff the character C is composable.  Characters of general
    category Z? or C? are not composable except for ZWNJ and ZWJ. */

=== modified file 'src/gtkutil.c'
--- src/gtkutil.c	2011-07-08 17:57:55 +0000
+++ src/gtkutil.c	2011-07-09 06:28:40 +0000
@@ -647,7 +647,6 @@
       /* Change stupid Gtk+ default line wrapping.  */
       p = gtk_widget_get_parent (x->ttip_lbl);
       list = gtk_container_get_children (GTK_CONTAINER (p));
-      iter;
       for (iter = list; iter; iter = g_list_next (iter))
         {
           GtkWidget *w = GTK_WIDGET (iter->data);

# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWeoOTFQABHpfgAAwUHf/91sH
0AC////wYAf99dikKUFEaHR0AAUCGpEyaaM9U0ZpMmho09TTJhMjQwhhJIIYJoRiVPU8jKeUGg0a
aMmmIOYAAAAAAAAAAGJFT/VTwBT00j1MgDIaPUyD0RoA5gAAAAAAAAAAKkkBExGmmjIGpphNTE0m
1GTTR5RAyujahbZcL/mRiMY+gvwE7KK46KZmEAYi+mDO5Z0mOeWxa9GjHPRa1sbsHBdwvvaMX0Kp
1FGIIpEJJAJY+pN0Iuap4SwYimt4OqVzO3BXGSLrF7Peqzcptkyqe8t6gP3O8eMcB7/qfIfAwXif
U7GT+7FKTWuYvw0MB/yxrdPDt7eHbWGL+qwOxoLY8b/0GHlYj1k9fKqwZ0/27nBjjVVWD/w2HOpK
6r7y0qQ8lPLrs6ZM13VPZ6PB1h/biF6jrrTrk+EIQyLbG56JzmHDizlb5IF6QJVQLCdpomHPVWjo
vke3K0N9O+p11yYROku4xNKmVRJWONLmmUZ5rExvkKwwqJK/tUWdliRwCsT8xks0DNijLlj6BkED
luKbCfOd4JaRCXmfl0PdFCWL+wbeJnT2hVCVgTTBXoUTcUKln5Q4xlDnsXaOpUxBUIOYco/SHAED
Uf3qJobwXU8CufO+HEam2mXn+vFg6nlV1gXXkuQIhwGc7PBw8Xf1u90fmWOJOvjqrLo4ksqJOLA6
SdmWBiQNO6ccUomBm+MqIwglzvIq8fORgCYOR+eR0XJ2jUmgvMbwqaUGMDTKUrxydNLLAUSVVg/o
iqUTFZ0bF80OphWlfu1Ya2DBr1WYVa/iutYiZhN2RDOpA7/0U+gVrsGMYyBNm9BxeQKsiMBiDgT+
jQkbmeM1sFtSskuBaHShHXpc6eSVvRKZHOUdUpjaXsRwN/Cbzk2NdtyzF8+s230VHuIa1eWgbQx1
b7gUIl0un3gvCdLlLyLkzuxMktXpBiYcMTN2yv3TalOpCJQ4GglaDrcl7Sxy5zZax1zVkkl+ON2y
7rys9jg05KdDG2PVsaFMFeWNtTLcSAoX7EXFAXrfgulLOCiZ7RzcUYvSCcEXMNyVyBYnrJGW5lvN
PbMbUvAzLWDLFiY8s/FiLtoPQsBI7MClIk8qYD5ZA84HlzHAiQ672aq1bVbmO323NMprZSa5uWWb
drZy9fSR9hlqcxbbS3Upoc1ka3FTNdmuSywpkylsE2tEM8FOp7psdk01VU4Wqqe5Vqjl+5XJlCdp
zuOEzJEIBIbZGoHl2NBmH6wYHA6BQHNgVQChT6/G5cMn0UpS5/l6QmjInc9G+uFs27b18a9+iLlD
nysTQ2tsPOY/r7N5m/bJupUzbbPyo0pKi+ZKVD8Mn05miPXoaZ5vd8ny7G/3zns9+K/k683Nhztc
n4sPs8V8zJ6v1T5yHKLTiCQMmATzpiA1h5Q6KTGRqP02CAOiUEorAQXYCA3OWg/RxXX1Zta+/Obj
ZCcScTnaGnmrY/qE0TXleujW7vd29u8wb+lVmiTjpaRql7sZo++6/jyeLwas/ixa3T3bfNN8/Qmh
lCfCifvm+p9/VLouDyX5ogoA2p/VfZ9kvAaPGu8pdTie5kcckD2h+wOXZU6lnR1FQo3Ptobp9Ljb
pfHgb1njCayXW8sSdva1abOh1fH4vM9ntYstFFv6erTtnjyst0f0uPhzqk8H5Txff6vJR7JQ3+eb
8fDVInyfNm0m/FcjNF70efW83y+F7ft67+DjE+VPD5Wk1LMubH0YLmY2ErY6kzW7icj1P1MicLTo
VKfScL2uS1nOqoUd0ifw2Qn2nPOrU9vau588Lcibf+3RLVHrvGt5TdUK6X1+b7o9bMXmlRwncSxv
1w10er7+LpYOpGby+3SfNH4xjmfhfLj0/uauolnpT7zv1U7ieNLX90LGZ0xx/h7jvnIdG1FLDRCY
HQUKSxM7+DwJpeC9g0JPePbYYSe8ybozL3Y5zB2tLBMWKXSXMbLX+FwyLmsxha95XS6UpvYRivfT
kTSkuoYFk6e5mTnblcrLdcTJH7LpMm+Htrc0bb0qOm5vT8s7O7U3sjfd2LFDhMk/nF15a8IupmvM
30NRPPo9mzUo7Si0OTyMDYOwLAS1LHiaCnQn5AnpYlOYvFgkKaUxxpNzW73fCfExvZOed/AtrVOV
KqxxRrixom2pVL/maU3OqjQpUKeehd4XcpOnf8Fngc38+OLGEwMHsLo1DiThE6YwZtzaMVzfUNDs
jcZN0foaoc6fay2rRYbHSw6hwkij3LLld0J0OTe3Pia9h06ec2xeu+RM0wTgj3m3uwejbK0UTnbp
NxNm+Ppz5ybCNjcoOD3JXp/a/nGqJHsBf+LuSKcKEh1ByYqA

bug#9031: Installed rest of patch

[Paul Eggert]

I see that I was too cautious, in that some of my patch
was derived independently and installed into the trunk
as part of bzr 105059.  I just now installed the rest of
the patch and am marking this bug report as done.

bug#9031: Installed rest of patch

[Juanma Barranquero]

On Sun, Jul 10, 2011 at 07:21, Paul Eggert <eggert@cs.ucla.edu> wrote:

> I see that I was too cautious

Removing dead code and unused variables is not a new feature, and we
haven't even started pretest yet as there have been no pretest
releases.

    Juanma

bug#9031: Installed rest of patch

[Stefan Monnier]

>> I see that I was too cautious
> Removing dead code and unused variables is not a new feature, and we
> haven't even started pretest yet as there have been no pretest
> releases.

At the same time, we're in feature freeze, which means we want to limit
code changes to bug fixes because we'd rather not add more bugs at
this stage.  So it's better to keep code cleanups for later (you could
try to install them in the `pending' branch, but such code cleanups are
likely to generate merge conflicts).


        Stefan

bug#9031: Installed rest of patch

[Paul Eggert]

On 07/11/11 05:49, Stefan Monnier wrote:
> it's better to keep code cleanups for later

This particular fix is both a code cleanup and a bug fix.
The latter, because often compilers complain about unused
local variables, and we'd rather have Emacs builds that
don't have useless chatter and generate bug reports that
waste everybody's time later.

Compiler warnings are a judgment call.  Pacifying
every compiler would be a never-ending task, and we shouldn't
try to do that.  But this particular case is a trivial and
obviously-safe change, and it fixes GCC warnings about
code that was introduced after the feature freeze.
The (admittedly minor) benefit of such a change surely
exceeds its cost.

I'd prefer it if, when one builds Emacs, one gets no more
compile-time diagnostics than one did when the feature
freeze was introduced.  This shouldn't be an absolute goal
and it shouldn't stand in the way of more-important issues,
but surely it's not an unreasonable aspiration.

> you could
> try to install them in the `pending' branch, but such code cleanups are
> likely to generate merge conflicts

Does this advice mean that code cleanups should not be installed
anywhere now, not even in the 'pending' branch?  I ask because I
have some integer-overflow-and-signedness-related cleanups and
bug-fixes in my private copy that should really get incorporated
at some point.

(Sorry, I don't know the current practice with regards to the
'pending' branch; maybe 'pending' should be documented somewhere
under admin/?)

bug#9031: Installed rest of patch

[Stefan Monnier]

>> it's better to keep code cleanups for later
> This particular fix is both a code cleanup and a bug fix.

Yes, it was OK.  I just felt that Juanma's answer was a bit too much
on the "we're not yet in pretest" side, so I wanted to compensate by
reminding people that we should think of fixing bugs now, not cleaning
things up.

>> you could try to install them in the `pending' branch, but such code
>> cleanups are likely to generate merge conflicts
> Does this advice mean that code cleanups should not be installed
> anywhere now, not even in the 'pending' branch?

You can install them there, but that branch is really meant to be
a repository of patches that will get merged to trunk in some distant
future.  Code that touches a lot of code is likely to encounter merge
conflicts when we get to that distant future.  And changes which need to
apply to "all places where foo happens" are even more likely to be
out-of-date when we get to that distant future.

> I ask because I have some integer-overflow-and-signedness-related
> cleanups and bug-fixes in my private copy that should really get
> incorporated at some point.

Put them somewhere.  But I suspect that it'll be easier to re-do them
than to merge the current patch several months from now, so it's
probably important to store somewhere the "how did I come up with this
patch" along with the patch.

> (Sorry, I don't know the current practice with regards to the
> 'pending' branch; maybe 'pending' should be documented somewhere
> under admin/?)

It's "documented" in http://bzr.savannah.gnu.org/r/emacs/README.
We don't really want to encourage people to use it too much, since the
focus should instead move to fixing bugs.  But sometimes it's easier to
install the patch somewhere than to try to mark some bug report as "it's
got a patch and the patch is good to go, we just have to wait for the
trunk to open up again before we can install it".


        Stefan

bug#9031: Installed rest of patch

[Juanma Barranquero]

On Tue, Jul 12, 2011 at 06:51, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Yes, it was OK.  I just felt that Juanma's answer was a bit too much
> on the "we're not yet in pretest" side, so I wanted to compensate by
> reminding people that we should think of fixing bugs now, not cleaning
> things up.

Believe it or not, I'm quite conservative with respect to pretests.

But... a formal announcemente about which state are we just now and
when do we <em>expect</em> to release the first pretest tarball would
be welcome.

    Juanma

Feature freeze

[Stefan Monnier]

> But... a formal announcemente about which state are we just now and
> when do we <em>expect</em> to release the first pretest tarball would
> be welcome.

OK, so to clarify:
- We started the feature freeze on July 1.
- The freeze is somewhat progressive/soft and we hope to harden it by end
  of July.
- The first pretest will come out as soon as we don't have enough bugs
  open to keep us busy (more or less).  How long that will take after
  the hard feature freeze is not yet determined.


        Stefan

Feature freeze

[Chong Yidong]

Hi people,

It's time to begin the feature freeze.

A couple of people still have small non-bugfix patches scheduled to go
into CVS; please check these in over the 24 hours, or email me if you
have problems.  Otherwise, don't commit any more new features.  If in
doubt, email emacs-devel for discussion.

Two exceptions: we'll allow the proced.el and rmail-mbox changes.

There currently isn't any detailed schedule for the release.  My hope
(and I think Stefan concurs) is to have 23.1 out in about six months
from now.  Maybe this is optimistic; we'll see.

My rough plan is to go through the bug list and finish those pertinent
to both Emacs 22 and Emacs 23 first.  About 2 weeks from now, I'll start
the Emacs 22.3 pretest, which hopefully won't take much effort and can
be completed in a month or two.  Once 22.3 is released, we'll take
another look at the bug count and see how soon afterwards we can start
the 23.1 pretest.

There are 180+ outstanding bugs, which can be browsed at the bugtracker
here:

http://emacsbugs.donarmstrong.com/cgi-bin/pkgreport.cgi?which=pkg&data=emacs&archive=no&version=&dist=unstable

Let's get to work on these.  If you need help using the bug tracker,
please email me.

Thanks!

Re: Feature freeze

[Kenichi Handa]

In article <87tze6mz3c.fsf@stupidchicken.com>, Chong Yidong <cyd@stupidchicken.com> writes:

> Hi people,
> It's time to begin the feature freeze.

> A couple of people still have small non-bugfix patches scheduled to go
> into CVS; please check these in over the 24 hours, or email me if you
> have problems.  Otherwise, don't commit any more new features.  If in
> doubt, email emacs-devel for discussion.

> Two exceptions: we'll allow the proced.el and rmail-mbox changes.

> There currently isn't any detailed schedule for the release.  My hope
> (and I think Stefan concurs) is to have 23.1 out in about six months
> from now.  Maybe this is optimistic; we'll see.

> My rough plan is to go through the bug list and finish those pertinent
> to both Emacs 22 and Emacs 23 first.  About 2 weeks from now, I'll start
> the Emacs 22.3 pretest, which hopefully won't take much effort and can
> be completed in a month or two.  Once 22.3 is released, we'll take
> another look at the bug count and see how soon afterwards we can start
> the 23.1 pretest.

As I wrote before, I'm now working on the new implementation
of automatic-character-composition that doesn't use text
property.  The work is not for a new feature, but I realized
that an element in composition-function-table must be
changed slightly, and a few new Lisp functions must be
added (in a broad sense, it's a new feature).  Please let me
check-in the necessary changes for that work even after the
feature freeze.

---
Kenichi Handa
handa@ni.aist.go.jp

RE: finger-pointer curser as default for mouse-face text

[Drew Adams]

1. We can no doubt find a good way to let click mouse-1 be used to follow
links and push action buttons - and still let it be used as it is now
(99.99%). We've discussed several possibilities, and we can discuss more and
settle on a good design. Already, IMO, acceptable approaches have been
discussed, but there is no reason not to scrutinize the issue more before we
make a change. David is right that whatever design we choose should not be
based only on how current code happens to be implemented; it should make
sense as a design, not just as a coding workaround.


2. Default behavior - One of the main reasons to make this fairly major
change to longstanding Emacs behavior is to bring Emacs behavior in line
with what users experience elsewhere. [This is not an argument for aligning
Emacs to every convention existing outside Emacs, but when a convention is
reasonable and fairly compatible, then it can at least be _considered_ for
possible adoption.]

This conventional behavior is especially important for _new_ Emacs users.
It makes sense, if we make this change to Emacs, to make the new behavior
the _default_ behavior. Let experienced Emacs users turn it off, if they
like, but let new Emacs users find it on by default. It would be silly to
require new users to somehow discover how to achieve this conventional
behavior. Emacs lovers often enjoy discovering not-so-obvious Emacs
features, but the standard, simple stuff should be obvious for newbies.

Sometimes we seem to be taking the view that if a candidate change is
recognized as very useful but it isn't 100% pluggable or it interferes with
current behavior or implementation a tiny bit, then the proper course of
action is to add it to Emacs, but turn it off. IMO, whether a feature should
be on or off by default should be determined first by whether or not it is
useful to most users and it might not be discovered by them if off by
default.

An argument for 100% correctness in 100% of contexts is appropriate to
consider, but as a secondary argument - it should generally not be the main
criterion for whether something is on by default. If something is _very_
broken, then it probably shouldn't be added at all. If something is, say,
1/10 broken and cannot easily be fixed, then one could argue for adding it
only as a non-default option, but if functionality and performance are close
to 100%, then the main argument for defaulting should be in terms of
usefulness.

[Yes, there are also arguments for not turning on something that will
interfere with minimal operation (e.g. -nw), and, yes, those arguments can
trump the main argument about useful service to most users. But sometimes
such minimal operation can be cantoned within, say, a command-line option,
so that the default behavior can be different in this case.]


3. Time-delay - Without having tried the time-delay implementation, my guess
is that it would be an acceptable solution. The longer delay should be used
for the less common behavior in Emacs - and for the behavior that is less
common (inexistant?) outside of Emacs.

IOW, the normal, short click behavior of mouse-1 should be to follow a link
(or to click a button); the longer "click" should set point or drag or
whatever within the link text. As far as an action button (or an active
image or image map) is concerned, I see little reason for this exceptional
mouse-1 behavior there; such behavior should be reserved for links - which
is one more reason that the long "click" should _not_ be the link-follow
action.

Again, we should be looking for the best design in the wider context of UI
conventions that have grown up around us - not looking for ways to minimize
impact on experienced Emacs users or on the current Emacs implementation.


4. Modifier-key - I still think that a keyboard modifier would be an
acceptable alternative if, for some reason (or in some contexts), the
time-delay approach had drawbacks. Someone argued that it would be hard to
remember. In that case, that is a further argument that setting point &
dragging within link text must be a rare activity: if it were common, you
would have no problem remembering the key sequence. For instance, if you use
M-mouse-1 often for secondary selection then you have no trouble remembering
it; if you use it rarely, then you might forget it.

Also (slightly off-topic), doesn't it make more sense to use modifier keys
for operations that you might want to _repeat_ by just holding down the
modifier key? What's the point of having, say, S-mouse-1 call up a
font-selection dialog box (mouse-set-font)? There are a limited number of
modifier keys - why would we "waste" them on operations that cannot be
repeated? (Yes, that can be an argument against using a modifier with
mouse-1 for selecting link text - so be it. The latter still makes more
sense to me than calling up a dialog box.)


5. Alternatives - Since we have several alternative ways to achieve the
current mouse-1 behavior within link text, I don't see a good argument for
not moving forward with the change we're discussing. These alternatives
might be slightly less convenient than just clicking mouse-1 for this
relatively rare need (selecting text within a link), but so what? If you can
accomplish this need in any of a number of ways, what's the big pb? So far,
we've considered these acceptable alternatives, the first of which already
exists:

 - use the keyboard (set mark; move point)
 - press mouse-1 a little longer
 - click mouse-1 with a modifier (e.g. C-S-mouse-1)

 Drew

Re: finger-pointer curser as default for mouse-face text

[Kim F. Storm]

Good points.  I agree with all of your views.

The default behaviour should be that a "normal" mouse-1 click follows a link.

The problem is how to not break external packages like preview-latex or AUCTex.

But CVS emacs is still far from being released, and I guess that if we
make a clean interface how to inhibit the mapping for specific links,
the package authors will have plenty of time to adapt their code for
CVS emacs.

>  - use the keyboard (set mark; move point)

Make that:  click mouse-1 outside the link, move into the link with the keyboard

>  - press mouse-1 a little longer

As my patch does, and it works nicely!

and you forgot:

- drag mouse-1 inside the link (you may drag it back to the character
  you clicked on, so you don't really mark a region).

>  - click mouse-1 with a modifier (e.g. C-S-mouse-1)

I don't see a need for this.  Better reserve such bindings for
future enhancements.


BTW, I agree that S-mouse-1 wastes a good mouse binding, as you can
easily get the same function from the menu Options > Set font/fontset.

I wish I could use S-mouse-1 to start marking a rectangle in CUA.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: finger-pointer curser as default for mouse-face text

[Luc Teirlinck]

Kim Storm wrote:

   But CVS emacs is still far from being released,

If we keep going on like this, there _never_ will be another release.

    and I guess that if we make a clean interface how to inhibit the
    mapping for specific links, the package authors will have plenty
    of time to adapt their code for CVS emacs.

It is also a matter of not only documenting the new behavior, but also
changing references to the old behavior everywhere in all manuals,
which may be spread all over the place.  Realistically speaking,
implementing the new behavior will introduce bugs that will need to be
fixed.  Everything combined, plenty of resources will be diverted from
working on the release, assuming we still want to have one.

I have not been following this discussion, as I have had no time to do
so.  I thought the purpose of a feature freeze was exactly that people
would not have to divert time away from working on the release by
worrying about substantive new features and their possible negative effects.

Sincerely,

Luc.

Re: finger-pointer curser as default for mouse-face text

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Kim Storm wrote:
>
>    But CVS emacs is still far from being released,
>
> If we keep going on like this, there _never_ will be another release.

I agree, but I think this is an important issue.

>
>     and I guess that if we make a clean interface how to inhibit the
>     mapping for specific links, the package authors will have plenty
>     of time to adapt their code for CVS emacs.
>
> It is also a matter of not only documenting the new behavior, but also
> changing references to the old behavior everywhere in all manuals,
> which may be spread all over the place.  

This is a general - but user customizable - change in behaviour.

As such, we should need to document the current "standard" behaviour,
and then add a section at an appropriate place which says something
like (need to be elaborated on a little bit):

Whenever you can click with mouse-2 to follow a link, you may also be
able to follow the link by a double click or a short click with
mouse-1.  The actual mouse-1 action that you need to follow a link is
controlled by the user option mouse-1-click-follows-link.

One problem is the tooltips which say "click mouse-2 to ...".  
To fix that requires that we change all places where the tooltips
are created (unless there is some place we can put in a clever
rewrite of the message).

>                                          Realistically speaking,
> implementing the new behavior will introduce bugs that will need to be
> fixed.  Everything combined, plenty of resources will be diverted from
> working on the release, assuming we still want to have one.

I don't think there will be many bugs related to this -- some but not many.

> I have not been following this discussion, as I have had no time to do
> so.  I thought the purpose of a feature freeze was exactly that people
> would not have to divert time away from working on the release by
> worrying about substantive new features and their possible negative effects.

That's a problem of a feature freeze that's in place for more than 1 year.

If you look at the change logs, new features still creap in over time.

Global warming may also be a problem :-)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: finger-pointer curser as default for mouse-face text

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> That's a problem of a feature freeze that's in place for more than 1
> year.

IIRC, it was more or less this August, give or take a month or two.
Certainly not a year.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

feature freeze (was: finger-pointer curser as default for mouse-face text)

[Reiner Steib]

On Wed, Oct 27 2004, David Kastrup wrote:

> storm@cua.dk (Kim F. Storm) writes:
>
>> That's a problem of a feature freeze that's in place for more than 1
>> year.
>
> IIRC, it was more or less this August, give or take a month or two.
> Certainly not a year.

It was in May, see e.g.
<URL:http://thread.gmane.org/x5wu3kn0nl.fsf@lola.goethe.zz> or
<URL:http://thread.gmane.org/gmane.emacs.devel/21327>.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: feature freeze

[David Kastrup]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> On Wed, Oct 27 2004, David Kastrup wrote:
>
>> storm@cua.dk (Kim F. Storm) writes:
>>
>>> That's a problem of a feature freeze that's in place for more than 1
>>> year.
>>
>> IIRC, it was more or less this August, give or take a month or two.
>> Certainly not a year.
>
> It was in May, see e.g.
> <URL:http://thread.gmane.org/x5wu3kn0nl.fsf@lola.goethe.zz> or
> <URL:http://thread.gmane.org/gmane.emacs.devel/21327>.

Still quite a short year.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum