Feature freeze on October 1

Feature freeze on October 1

[Chong Yidong]

The trunk is just about ready to go into feature freeze for the 24.3
release.  We will begin the freeze on October 1, a couple of weeks from
now.  If you are working on a feature that you'd like included in 24.3,
please commit it before October 1 or ask for an extension.

As usual, once the freeze is in effect, please commit only bug fixes to
the trunk, i.e. no new features or non-trivial internals changes.  If
you would like an exception, ask for one on emacs-devel.

Thanks.

Re: Feature freeze on October 1

[Daniel Colascione]

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

On 9/15/12 6:55 PM, Chong Yidong wrote:
> The trunk is just about ready to go into feature freeze for the 24.3
> release.  We will begin the freeze on October 1, a couple of weeks from
> now.  If you are working on a feature that you'd like included in 24.3,
> please commit it before October 1 or ask for an extension.

Can I get my cygw32 work into 24.3? I'll try to get it ready by the
first, but depending on work scheduling, I might need another week or so.



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

Re: Feature freeze on October 1

[Stefan Monnier]

>> The trunk is just about ready to go into feature freeze for the 24.3
>> release.  We will begin the freeze on October 1, a couple of weeks from
>> now.  If you are working on a feature that you'd like included in 24.3,
>> please commit it before October 1 or ask for an extension.
> Can I get my cygw32 work into 24.3?

I'd be happy to see it in 24.3, yes.

> I'll try to get it ready by the first,

That would be preferable, yes.

> but depending on work scheduling, I might need another week or so.

Try to make it as "obviously safe" as possible, then.


        Stefan

Re: Feature freeze on October 1

[David Engster]

Chong Yidong writes:
> The trunk is just about ready to go into feature freeze for the 24.3
> release.  We will begin the freeze on October 1, a couple of weeks from
> now.  If you are working on a feature that you'd like included in 24.3,
> please commit it before October 1 or ask for an extension.

I've been busy merging CEDET with Emacs. I already merged all the
changes from Emacs trunk to CEDET trunk, and I'm currently working on
the other way round. I think I should be able to have our 'to-emacs'
branch ready till October 1st, which could then be merged in.

However, we also wanted to pull in the CEDET grammar generation
packages, Bovine and Wisent, which are not yet part of Emacs. This will
require more work, since we have to update those to properly conform
with Emacs's coding standards. I cannot do this until October; maybe
Someone Else can take a look, otherwise I definitely need an extension.
Also, I don't know if copyright issues are fully worked out for them.

-David

Re: Feature freeze on October 1

[Stefan Monnier]

> the other way round. I think I should be able to have our 'to-emacs'
> branch ready till October 1st, which could then be merged in.

This merge is important, yes.  Please let us know if you can't make it
for October 1st.

> However, we also wanted to pull in the CEDET grammar generation
> packages, Bovine and Wisent, which are not yet part of Emacs. This will
> require more work, since we have to update those to properly conform
> with Emacs's coding standards. I cannot do this until October; maybe
> Someone Else can take a look, otherwise I definitely need an extension.
> Also, I don't know if copyright issues are fully worked out for them.

Sounds like maybe this won't make it for 24.3.
Note that it can still be done during the freeze and installed in the
"to be 24.4" branch.


        Stefan

Re: Feature freeze on October 1

[David Engster]

Stefan Monnier writes:
>> However, we also wanted to pull in the CEDET grammar generation
>> packages, Bovine and Wisent, which are not yet part of Emacs. This will
>> require more work, since we have to update those to properly conform
>> with Emacs's coding standards. I cannot do this until October; maybe
>> Someone Else can take a look, otherwise I definitely need an extension.
>> Also, I don't know if copyright issues are fully worked out for them.
>
> Sounds like maybe this won't make it for 24.3.
> Note that it can still be done during the freeze and installed in the
> "to be 24.4" branch.

Actually, I forgot that we already ship those packages in the
admin/grammars directory since Emacs v23.2a, so at least the copyright
stuff is in order. So there's only the question whether those two
packages are good enough for regular inclusion, or if they need
extensive changes.

-David

CEDET merge (was: Feature freeze on October 1)

[David Engster]

Stefan Monnier writes:
>> the other way round. I think I should be able to have our 'to-emacs'
>> branch ready till October 1st, which could then be merged in.
>
> This merge is important, yes.  Please let us know if you can't make it
> for October 1st.

I have successfully merged CEDET trunk into the current codebase from
Emacs bzr. The result can be seen in the 'to-emacs' branch from CEDET
upstream:

 bzr checkout bzr://cedet.bzr.sourceforge.net/bzrroot/cedet/code/to-emacs

To update the Emacs repository, first get a patch by doing

 cd to-emacs
 bzr diff -r tag:EMACS_110047.. admin etc lisp > ~/cedet-patch

and then simply

 cd emacs/trunk
 patch -p0 < ~/cedet-patch

It should apply and compile cleanly (only the Python parser is throwing
some warnings).

Please do not commit this patch yet, since it definitely needs some
further testing. My plan is to check the code with our test suite, which
will need a few tweaks first to work with stock Emacs, though.

A few further comments:

- I've restricted myself to the files currently in Emacs trunk, meaning
  no new files are pulled in. This means, the patch will not introduce
  new CEDET features like support for Android, Arduino, Fortran 90, the
  M3 menu, clang completions, etc.

- As you can see in the above 'bzr diff' command, I've not yet taken
  care of the texinfo files.

- Then there's the ChangeLog issue... We have a package in CEDET which
  generates ChangeLogs from our bzr commit logs. I'm not sure if such a
  fine-grained ChangeLog is necessary for an update like this. Also, I
  would have to exclude all logs regarding files not in Emacs trunk.

- I cannot check for FSF papers, but I've been careful to always ask,
  and I'm sure the same applies to Eric and others who can commit to
  CEDET. Still, please double-check. A 'bzr log -n0 -r 8208' will give
  you a list of the commits from the merge.

I'd like to thank Lluís in helping us to get this thing going. I hope
this branch is pretty much what he envisioned in the beginning. :-)
Also, many thanks go to Aaron Bentley for helping me when I hit a bzr
bug during the final merge.

-David

Re: CEDET merge

[David Engster]

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

David Engster writes:
> Stefan Monnier writes:
>>> the other way round. I think I should be able to have our 'to-emacs'
>>> branch ready till October 1st, which could then be merged in.
>>
>> This merge is important, yes.  Please let us know if you can't make it
>> for October 1st.
>
> Please do not commit this patch yet, since it definitely needs some
> further testing. My plan is to check the code with our test suite, which
> will need a few tweaks first to work with stock Emacs, though.

I've checked the new code base with our test suite and fixed a bunch of
stuff. Everything's working now except for a few minor things, so I
think the branch is now ready for merging.

You can obtain a patch file from our 'to-emacs' branch (for details see
my last mail), but I've also attached it to this message so everyone can
check it easily. There's no ChangeLog yet, so if you want to check the
logs you still need our 'to-emacs' branch.

Please take a look at the issues I raised in my previous mail, since
they still apply (esp. regarding checking for papers).

Additionally, I've also regenerated the Elisp parsers from the updated
grammar files. This converted some more explicit copyright ranges like

Copyright (C) 2002-2004, 2007, 2010-2012  Free Software Foundation, Inc

to a simple range like this

Copyright (C) 2002-2012 Free Software Foundation, Inc.

Is this acceptable? Also, it removed the 'Author: David Ponce' line from
cedet/semantic/grammar.el, but I think it didn't make sense anyway since
it is a generated file (from admin/grammars/grammar.wy, where he's still
credited).

I left the grammars and parser generator in admin/grammars for now, but
IMO the generator bovine-grammar.el and wisent-grammar.el should
eventually be moved to their proper locations underneath lisp/. The main
grammar generation is already in lisp/semantic/grammar.el and hence was
in Emacs all the time; the two files above are just refinements for the
two different grammar styles.

-David


[-- Attachment #2: cedet-update-patch.diff.gz --]
[-- Type: application/octet-stream, Size: 102025 bytes --]

Re: CEDET merge

[David Engster]

David Engster writes:
> Also, it removed the 'Author: David Ponce' line from
> cedet/semantic/grammar.el,

This should read: cedet/semantic/grammar-wy.el.

Also, I should mention that this patch introduces two new files:
etc/srecode/c.srt and etc/srecode/ede-autoconf.srt, which will have to
be added to the repository.

-David

Re: CEDET merge

[Glenn Morris]

David Engster wrote:

> Additionally, I've also regenerated the Elisp parsers from the updated
> grammar files. This converted some more explicit copyright ranges like
>
> Copyright (C) 2002-2004, 2007, 2010-2012  Free Software Foundation, Inc
>
> to a simple range like this
>
> Copyright (C) 2002-2012 Free Software Foundation, Inc.
>
> Is this acceptable?

If the former is the true statement, that the latter is not an
acceptable alternative, no. If the former was for some reason incorrect
and the latter is correct, then obviously it is ok.

http://www.gnu.org/prep/maintain/maintain.html#Copyright-Notices

Re: CEDET merge

[Paul Eggert]

>> > This converted some more explicit copyright ranges like
>> >
>> > Copyright (C) 2002-2004, 2007, 2010-2012  Free Software Foundation, Inc
>> >
>> > to a simple range like this
>> >
>> > Copyright (C) 2002-2012 Free Software Foundation, Inc.
>> >
>> > Is this acceptable?

> If the former is the true statement, that the latter is not an
> acceptable alternative, no. If the former was for some reason incorrect
> and the latter is correct, then obviously it is ok.

If we're talking about Emacs, "2002-2012" is a
true statement, is acceptable, and is what the
GNU coding standards currently recommend.
New versions of Emacs were published (at least via
a revision-control system) in all those years, and
there's a "NOTE ON COPYRIGHT YEARS" in the README
file that explains all this, so the GNU rules are being
followed for copyright years if the file says just
"2002-2012".

Re: CEDET merge

[Glenn Morris]

Paul Eggert wrote:

> If we're talking about Emacs, "2002-2012" is a true statement, is
> acceptable, and is what the GNU coding standards currently recommend.
> New versions of Emacs were published (at least via a revision-control
> system) in all those years, and there's a "NOTE ON COPYRIGHT YEARS" in
> the README file that explains all this, so the GNU rules are being
> followed for copyright years if the file says just "2002-2012".

CEDET was not part of Emacs until 2009, so it depends on when/how CEDET
was released before that.

Re: CEDET merge

[Chong Yidong]

David Engster <deng@randomsample.de> writes:

> I've checked the new code base with our test suite and fixed a bunch of
> stuff. Everything's working now except for a few minor things, so I
> think the branch is now ready for merging.
>
> You can obtain a patch file from our 'to-emacs' branch (for details see
> my last mail), but I've also attached it to this message so everyone can
> check it easily. There's no ChangeLog yet, so if you want to check the
> logs you still need our 'to-emacs' branch.

OK, I will perform the merge soon.  Thanks for all your work.

> I cannot check for FSF papers, but I've been careful to always ask,
> and I'm sure the same applies to Eric and others who can commit to
> CEDET. Still, please double-check. A 'bzr log -n0 -r 8208' will give
> you a list of the commits from the merge.

The papers appear to be in order.

I assume that the scymtym <scymtym@gmmx.net> listed in your commit logs
is a pseudonym for Jan Moringen (who does have papers).  Let me know if
that is not correct.

Re: CEDET merge

[Eric M. Ludlam]

On 09/30/2012 11:44 PM, Chong Yidong wrote:
> David Engster<deng@randomsample.de>  writes:
>
>> I've checked the new code base with our test suite and fixed a bunch of
>> stuff. Everything's working now except for a few minor things, so I
>> think the branch is now ready for merging.
>>
>> You can obtain a patch file from our 'to-emacs' branch (for details see
>> my last mail), but I've also attached it to this message so everyone can
>> check it easily. There's no ChangeLog yet, so if you want to check the
>> logs you still need our 'to-emacs' branch.
>
> OK, I will perform the merge soon.  Thanks for all your work.
>
>> I cannot check for FSF papers, but I've been careful to always ask,
>> and I'm sure the same applies to Eric and others who can commit to
>> CEDET. Still, please double-check. A 'bzr log -n0 -r 8208' will give
>> you a list of the commits from the merge.
>
> The papers appear to be in order.
>
> I assume that the scymtym<scymtym@gmmx.net>  listed in your commit logs
> is a pseudonym for Jan Moringen (who does have papers).  Let me know if
> that is not correct.

Yes, that is Jan.

If you have other email questions, there is a list in 
cedet-update-changelog.el at the root of the CEDET tree.

Eric

Re: CEDET merge

[David Engster]

Chong Yidong writes:
> David Engster <deng@randomsample.de> writes:
>
>> I've checked the new code base with our test suite and fixed a bunch of
>> stuff. Everything's working now except for a few minor things, so I
>> think the branch is now ready for merging.
>>
>> You can obtain a patch file from our 'to-emacs' branch (for details see
>> my last mail), but I've also attached it to this message so everyone can
>> check it easily. There's no ChangeLog yet, so if you want to check the
>> logs you still need our 'to-emacs' branch.
>
> OK, I will perform the merge soon.  Thanks for all your work.

Unfortunately, I see now that I forgot to remove some defadvices. After
applying the patch, please remove the two defadvices for hideif from
semantic/bovine/c.el. We have to see if we somehow can implement this
feature using hooks, or maybe we have to remove the semantical
hideif-feature altogether.

Also, I merged lots of stuff from senator.el (including some defadvices)
which shouldn't land in Emacs. So for now, I would suggest to simply
revert senator.el after the patch is applied. I think Eric wanted to
remove senator.el at some point in time, but I guess we don't have a
good replacement yet...?

-David

Re: CEDET merge

[Chong Yidong]

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

David Engster <deng@randomsample.de> writes:

> Unfortunately, I see now that I forgot to remove some defadvices. After
> applying the patch, please remove the two defadvices for hideif from
> semantic/bovine/c.el. We have to see if we somehow can implement this
> feature using hooks, or maybe we have to remove the semantical
> hideif-feature altogether.
>
> Also, I merged lots of stuff from senator.el (including some defadvices)
> which shouldn't land in Emacs. So for now, I would suggest to simply
> revert senator.el after the patch is applied. I think Eric wanted to
> remove senator.el at some point in time, but I guess we don't have a
> good replacement yet...?

I've done the merge, omitting senator and the defadvices as you
suggested.

To replace the defadvice, it is acceptable to just change the code of
hif-defined and hif-lookup directly to refer to
semantic-c-takeover-hideif (if it is bound); no need to use a hook.
Feel free to submit a patch, or I'll get around to it when I have the
time.

Attached is a patch of leftovers, consisting of a few whitespace
cleanups and file header fixes.  Please apply to the to-emacs branch or
wherever is appropriate.  Thanks.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: cedet-back.patch --]
[-- Type: text/x-diff, Size: 16644 bytes --]

=== modified file 'lisp/cedet/cedet.el'
*** lisp/cedet/cedet.el	2012-09-25 20:18:22 +0000
--- lisp/cedet/cedet.el	2012-10-01 17:26:33 +0000
***************
*** 44,51 ****
      (cedet         ,cedet-version "common"   "common" 	        )
      (eieio         "1.4"           nil       "eieio"       )
      (semantic      "2.1"           nil       "semantic/doc")
!     (srecode       "1.1"           nil       "srecode"     ) 
!     (ede           "1.1"           nil       "ede"         )    
      (speedbar      "1.0.4"         nil       "speedbar"    )
      (cogre         "1.1"           nil       "cogre"       )
      (cedet-contrib "1.1"           "contrib" nil           )
--- 44,51 ----
      (cedet         ,cedet-version "common"   "common" 	        )
      (eieio         "1.4"           nil       "eieio"       )
      (semantic      "2.1"           nil       "semantic/doc")
!     (srecode       "1.1"           nil       "srecode"     )
!     (ede           "1.1"           nil       "ede"         )
      (speedbar      "1.0.4"         nil       "speedbar"    )
      (cogre         "1.1"           nil       "cogre"       )
      (cedet-contrib "1.1"           "contrib" nil           )

=== modified file 'lisp/cedet/ede.el'
*** lisp/cedet/ede.el	2012-09-25 20:18:22 +0000
--- lisp/cedet/ede.el	2012-10-01 17:26:44 +0000
***************
*** 382,390 ****
    (oset (ede-current-project) configuration-default newconfig)
    (message "%s will now build in %s mode."
  	   (object-name (ede-current-project))
! 	   newconfig)
!   )
! 	   
  
  (defun ede-customize-forms-menu (menu-def)
    "Create a menu of the project, and targets that can be customized.
--- 382,388 ----
    (oset (ede-current-project) configuration-default newconfig)
    (message "%s will now build in %s mode."
  	   (object-name (ede-current-project))
! 	   newconfig))
  
  (defun ede-customize-forms-menu (menu-def)
    "Create a menu of the project, and targets that can be customized.
***************
*** 879,885 ****
  
    (project-add-file target (buffer-file-name))
    (setq ede-object nil)
!   
    ;; Setup buffer local variables.
    (ede-initialize-state-current-buffer)
  
--- 877,883 ----
  
    (project-add-file target (buffer-file-name))
    (setq ede-object nil)
! 
    ;; Setup buffer local variables.
    (ede-initialize-state-current-buffer)
  
***************
*** 1424,1430 ****
      ;; This is a heavy hammer, but will apply variables properly
      ;; based on stacking between the toplevel and child projects.
      (ede-map-buffers 'ede-apply-project-local-variables)
!     
      value))
  
  (defun ede-apply-project-local-variables (&optional buffer)
--- 1422,1428 ----
      ;; This is a heavy hammer, but will apply variables properly
      ;; based on stacking between the toplevel and child projects.
      (ede-map-buffers 'ede-apply-project-local-variables)
! 
      value))
  
  (defun ede-apply-project-local-variables (&optional buffer)

=== modified file 'lisp/cedet/ede/auto.el'
*** lisp/cedet/ede/auto.el	2012-09-25 20:18:22 +0000
--- lisp/cedet/ede/auto.el	2012-10-01 17:26:36 +0000
***************
*** 35,41 ****
  (declare-function ede-add-project-to-global-list "ede")
  
  (defclass ede-project-autoload-dirmatch ()
!   ((fromconfig :initarg :fromconfig 
  	       :initform nil
  	       :documentation
  	       "A config file within which the match pattern lives.")
--- 35,41 ----
  (declare-function ede-add-project-to-global-list "ede")
  
  (defclass ede-project-autoload-dirmatch ()
!   ((fromconfig :initarg :fromconfig
  	       :initform nil
  	       :documentation
  	       "A config file within which the match pattern lives.")
***************
*** 70,76 ****
  
       ;; Error for wierd stuff
       (t (error "Unknown dirmatch type.")))))
!   
  
  (defmethod ede-do-dirmatch ((dirmatch ede-project-autoload-dirmatch) file)
    "Does DIRMATCH match the filename FILE."
--- 70,76 ----
  
       ;; Error for wierd stuff
       (t (error "Unknown dirmatch type.")))))
! 
  
  (defmethod ede-do-dirmatch ((dirmatch ede-project-autoload-dirmatch) file)
    "Does DIRMATCH match the filename FILE."
***************
*** 274,280 ****
  		 (not (ede-dirmatch-installed dirmatch)))
  	    (setq callfcn nil)
  	  ;; Other types of dirmatch:
! 	  (when (and 
  		 ;; If the Emacs Lisp file handling this project hasn't
  		 ;; been loaded, we will use the quick dirmatch feature.
  		 (not (featurep (oref this file)))
--- 274,280 ----
  		 (not (ede-dirmatch-installed dirmatch)))
  	    (setq callfcn nil)
  	  ;; Other types of dirmatch:
! 	  (when (and
  		 ;; If the Emacs Lisp file handling this project hasn't
  		 ;; been loaded, we will use the quick dirmatch feature.
  		 (not (featurep (oref this file)))
***************
*** 292,298 ****
  	(when callfcn
  	  (condition-case nil
  	      (funcall rootfcn file)
! 	    (error 
  	     (funcall rootfcn))))
  	))))
  
--- 292,298 ----
  	(when callfcn
  	  (condition-case nil
  	      (funcall rootfcn file)
! 	    (error
  	     (funcall rootfcn))))
  	))))
  

=== modified file 'lisp/cedet/ede/linux.el'
*** lisp/cedet/ede/linux.el	2012-09-25 20:18:22 +0000
--- lisp/cedet/ede/linux.el	2012-10-01 17:26:43 +0000
***************
*** 302,305 ****
  ;; generated-autoload-load-name: "ede/linux"
  ;; End:
  
! ;;; ede-linux.el ends here
--- 302,305 ----
  ;; generated-autoload-load-name: "ede/linux"
  ;; End:
  
! ;;; ede/linux.el ends here

=== modified file 'lisp/cedet/ede/proj-elisp.el'
*** lisp/cedet/ede/proj-elisp.el	2012-09-25 20:18:22 +0000
--- lisp/cedet/ede/proj-elisp.el	2012-10-01 17:26:38 +0000
***************
*** 36,43 ****
     (keybindings :initform nil)
     (phony :initform t)
     (sourcetype :initform '(ede-source-emacs))
!    (availablecompilers :initform '(ede-emacs-compiler 
! 				   ede-xemacs-compiler))
     (aux-packages :initarg :aux-packages
  		 :initform nil
  		 :type list
--- 36,42 ----
     (keybindings :initform nil)
     (phony :initform t)
     (sourcetype :initform '(ede-source-emacs))
!    (availablecompilers :initform '(ede-emacs-compiler ede-xemacs-compiler))
     (aux-packages :initarg :aux-packages
  		 :initform nil
  		 :type list

=== modified file 'lisp/cedet/semantic/bovine/c.el'
*** lisp/cedet/semantic/bovine/c.el	2012-09-30 08:28:41 +0000
--- lisp/cedet/semantic/bovine/c.el	2012-10-01 17:26:48 +0000
***************
*** 459,479 ****
  (defvar semantic-c-takeover-hideif nil
    "Non-nil when Semantic is taking over hideif features.")
  
! (defadvice hif-defined (around semantic-c activate)
!   "Is the variable defined?"
!   (if semantic-c-takeover-hideif
!       (setq ad-return-value
! 	    (semantic-c-hideif-defined (ad-get-arg 0)))
!     ad-do-it))
  
! (defadvice hif-lookup (around semantic-c activate)
!   "Is the argument defined?  Return true or false."
!   (let ((ans nil))
!     (when semantic-c-takeover-hideif
!       (setq ans (semantic-c-hideif-lookup (ad-get-arg 0))))
!     (if (null ans)
! 	ad-do-it
!       (setq ad-return-value ans))))
  
  ;;; #if macros
  ;;
--- 459,479 ----
  (defvar semantic-c-takeover-hideif nil
    "Non-nil when Semantic is taking over hideif features.")
  
! ;; (defadvice hif-defined (around semantic-c activate)
! ;;   "Is the variable defined?"
! ;;   (if semantic-c-takeover-hideif
! ;;       (setq ad-return-value
! ;; 	    (semantic-c-hideif-defined (ad-get-arg 0)))
! ;;     ad-do-it))
  
! ;; (defadvice hif-lookup (around semantic-c activate)
! ;;   "Is the argument defined?  Return true or false."
! ;;   (let ((ans nil))
! ;;     (when semantic-c-takeover-hideif
! ;;       (setq ans (semantic-c-hideif-lookup (ad-get-arg 0))))
! ;;     (if (null ans)
! ;; 	ad-do-it
! ;;       (setq ad-return-value ans))))
  
  ;;; #if macros
  ;;

=== modified file 'lisp/cedet/semantic/bovine/make-by.el'
*** lisp/cedet/semantic/bovine/make-by.el	2012-09-30 10:36:41 +0000
--- lisp/cedet/semantic/bovine/make-by.el	2012-10-01 17:26:47 +0000
***************
*** 1,6 ****
  ;;; semantic/bovine/make-by.el --- Generated parser support file
  
! ;; Copyright (C) 1999-2012 Free Software Foundation, Inc.
  
  ;; This file is part of GNU Emacs.
  
--- 1,6 ----
  ;;; semantic/bovine/make-by.el --- Generated parser support file
  
! ;; Copyright (C) 1999-2004, 2008-2012  Free Software Foundation, Inc.
  
  ;; This file is part of GNU Emacs.
  

=== modified file 'lisp/cedet/semantic/bovine/scm-by.el'
*** lisp/cedet/semantic/bovine/scm-by.el	2012-09-30 10:36:41 +0000
--- lisp/cedet/semantic/bovine/scm-by.el	2012-10-01 17:26:46 +0000
***************
*** 1,6 ****
  ;;; semantic/bovine/scm-by.el --- Generated parser support file
  
! ;; Copyright (C) 2001-2012 Free Software Foundation, Inc.
  
  ;; This file is part of GNU Emacs.
  
--- 1,6 ----
  ;;; semantic/bovine/scm-by.el --- Generated parser support file
  
! ;; Copyright (C) 2001, 2003, 2009-2012 Free Software Foundation, Inc.
  
  ;; This file is part of GNU Emacs.
  

=== modified file 'lisp/cedet/semantic/grammar-wy.el'
*** lisp/cedet/semantic/grammar-wy.el	2012-09-30 10:36:41 +0000
--- lisp/cedet/semantic/grammar-wy.el	2012-10-01 17:27:09 +0000
***************
*** 1,6 ****
  ;;; semantic/grammar-wy.el --- Generated parser support file
  
! ;; Copyright (C) 2002-2012 Free Software Foundation, Inc.
  
  ;; This file is part of GNU Emacs.
  
--- 1,6 ----
  ;;; semantic/grammar-wy.el --- Generated parser support file
  
! ;; Copyright (C) 2002-2004, 2009-2012  Free Software Foundation, Inc.
  
  ;; This file is part of GNU Emacs.
  

=== modified file 'lisp/cedet/semantic/tag-ls.el'
*** lisp/cedet/semantic/tag-ls.el	2012-09-25 20:18:22 +0000
--- lisp/cedet/semantic/tag-ls.el	2012-10-01 17:26:49 +0000
***************
*** 114,120 ****
  	      taglist1 (cdr taglist1)
  	      taglist2 (cdr taglist2)))
        ans))
!    
     ;; The attributes are not the same?
     ((not (equal value1 value2))
      nil)
--- 114,120 ----
  	      taglist1 (cdr taglist1)
  	      taglist2 (cdr taglist2)))
        ans))
! 
     ;; The attributes are not the same?
     ((not (equal value1 value2))
      nil)

=== modified file 'lisp/cedet/semantic/wisent/javat-wy.el'
*** lisp/cedet/semantic/wisent/javat-wy.el	2012-09-30 10:36:41 +0000
--- lisp/cedet/semantic/wisent/javat-wy.el	2012-10-01 17:27:11 +0000
***************
*** 1,6 ****
  ;;; semantic/wisent/javat-wy.el --- Generated parser support file
  
! ;; Copyright (C) 2002-2012 Free Software Foundation, Inc.
  
  ;; This file is part of GNU Emacs.
  
--- 1,6 ----
  ;;; semantic/wisent/javat-wy.el --- Generated parser support file
  
! ;; Copyright (C) 2002, 2007, 2009-2012  Free Software Foundation, Inc.
  
  ;; This file is part of GNU Emacs.
  

=== modified file 'lisp/cedet/semantic/wisent/js-wy.el'
*** lisp/cedet/semantic/wisent/js-wy.el	2012-09-30 10:36:41 +0000
--- lisp/cedet/semantic/wisent/js-wy.el	2012-10-01 17:27:09 +0000
***************
*** 1,6 ****
  ;;; semantic/wisent/js-wy.el --- Generated parser support file
  
! ;; Copyright (C) 2005-2012 Free Software Foundation, Inc.
  ;; Copyright (C) 1998-2011 Ecma International.
  
  ;; This file is part of GNU Emacs.
--- 1,6 ----
  ;;; semantic/wisent/js-wy.el --- Generated parser support file
  
! ;; Copyright (C) 2005, 2009-2012  Free Software Foundation, Inc.
  ;; Copyright (C) 1998-2011 Ecma International.
  
  ;; This file is part of GNU Emacs.

=== modified file 'lisp/cedet/semantic/wisent/python.el'
*** lisp/cedet/semantic/wisent/python.el	2012-09-25 20:18:22 +0000
--- lisp/cedet/semantic/wisent/python.el	2012-10-01 17:27:10 +0000
***************
*** 393,399 ****
       (cons "static"
  	   (semantic-tag-get-attribute tag :typemodifiers))))
  
!   ;; TODO 
    ;; + check for decorators classmethod
    ;; + check for operators
    tag)
--- 393,399 ----
       (cons "static"
  	   (semantic-tag-get-attribute tag :typemodifiers))))
  
!   ;; TODO
    ;; + check for decorators classmethod
    ;; + check for operators
    tag)
***************
*** 445,451 ****
  	(setq expand (cons (semantic-tag-clone tag E) expand)))
        (setq expand (nreverse expand)))
       )))
!      
  
  \f
  ;;; Overridden Semantic API.
--- 445,451 ----
  	(setq expand (cons (semantic-tag-clone tag E) expand)))
        (setq expand (nreverse expand)))
       )))
! 
  
  \f
  ;;; Overridden Semantic API.

=== modified file 'lisp/cedet/srecode/srt-wy.el'
*** lisp/cedet/srecode/srt-wy.el	2012-09-30 13:27:07 +0000
--- lisp/cedet/srecode/srt-wy.el	2012-10-01 17:27:16 +0000
***************
*** 1,6 ****
  ;;; srecode/srt-wy.el --- Generated parser support file
  
! ;; Copyright (C) 2005-2012 Free Software Foundation, Inc.
  
  ;; This file is part of GNU Emacs.
  
--- 1,6 ----
  ;;; srecode/srt-wy.el --- Generated parser support file
  
! ;; Copyright (C) 2005, 2007-2012 Free Software Foundation, Inc.
  
  ;; This file is part of GNU Emacs.
  

=== modified file 'lisp/emacs-lisp/eieio-base.el'
*** lisp/emacs-lisp/eieio-base.el	2012-09-30 08:28:41 +0000
--- lisp/emacs-lisp/eieio-base.el	2012-10-01 17:26:01 +0000
***************
*** 230,238 ****
  for CLASS.  Optional ALLOW-SUBCLASS says that it is ok for
  `eieio-peristent-read' to load in subclasses of class instead of
  being pendantic."
!   (when (not class)
!     (message "Unsafe call to `eieio-persistent-read'.")
!     )
    (when (and class (not (class-p class)))
      (signal 'wrong-type-argument (list 'class-p class)))
    (let ((ret nil)
--- 230,237 ----
  for CLASS.  Optional ALLOW-SUBCLASS says that it is ok for
  `eieio-peristent-read' to load in subclasses of class instead of
  being pendantic."
!   (unless class
!     (message "Unsafe call to `eieio-persistent-read'."))
    (when (and class (not (class-p class)))
      (signal 'wrong-type-argument (list 'class-p class)))
    (let ((ret nil)
***************
*** 272,287 ****
    (let ((objclass (nth 0 inputlist))
  	(objname (nth 1 inputlist))
  	(slots (nthcdr 2 inputlist))
! 	(createslots nil)
! 	)
!     
      ;; If OBJCLASS is an eieio autoload object, then we need to load it.
      (eieio-class-un-autoload objclass)
  
      (while slots
        (let ((name (car slots))
! 	    (value (car (cdr slots)))
! 	    )
  
  	;; Make sure that the value proposed for SLOT is valid.
  	;; In addition, strip out quotes, list functions, and update
--- 271,284 ----
    (let ((objclass (nth 0 inputlist))
  	(objname (nth 1 inputlist))
  	(slots (nthcdr 2 inputlist))
! 	(createslots nil))
! 
      ;; If OBJCLASS is an eieio autoload object, then we need to load it.
      (eieio-class-un-autoload objclass)
  
      (while slots
        (let ((name (car slots))
! 	    (value (car (cdr slots))))
  
  	;; Make sure that the value proposed for SLOT is valid.
  	;; In addition, strip out quotes, list functions, and update
***************
*** 366,372 ****
  		    (nreverse objlist)))
  		 (t
  		  proposed-value))))
! 	 
  	 ((stringp proposed-value)
  	  ;; Else, check for strings, remove properties.
  	  (substring-no-properties proposed-value))
--- 363,369 ----
  		    (nreverse objlist)))
  		 (t
  		  proposed-value))))
! 
  	 ((stringp proposed-value)
  	  ;; Else, check for strings, remove properties.
  	  (substring-no-properties proposed-value))

=== modified file 'lisp/emacs-lisp/eieio.el'
*** lisp/emacs-lisp/eieio.el	2012-09-25 20:18:22 +0000
--- lisp/emacs-lisp/eieio.el	2012-10-01 17:26:03 +0000
***************
*** 792,798 ****
  	(when (string-match "\\.elc$" fname)
  	  (setq fname (substring fname 0 (1- (length fname)))))
  	(put cname 'class-location fname)))
!     
      ;; We have a list of custom groups.  Store them into the options.
      (let ((g (class-option-assoc options :custom-groups)))
        (mapc (lambda (cg) (add-to-list 'g cg)) groups)
--- 792,798 ----
  	(when (string-match "\\.elc$" fname)
  	  (setq fname (substring fname 0 (1- (length fname)))))
  	(put cname 'class-location fname)))
! 
      ;; We have a list of custom groups.  Store them into the options.
      (let ((g (class-option-assoc options :custom-groups)))
        (mapc (lambda (cg) (add-to-list 'g cg)) groups)
***************
*** 1270,1278 ****
  		  `(apply ,(list 'quote impl) local-args)
  		`(apply #',impl local-args))
  	      ;(,impl local-args)
! 	      ))))
!      )
!   ))
  
  (defsubst eieio-defgeneric-reset-generic-form-primary-only-one (method)
    "Setup METHOD to call the generic form."
--- 1270,1276 ----
  		  `(apply ,(list 'quote impl) local-args)
  		`(apply #',impl local-args))
  	      ;(,impl local-args)
! 	      )))))))
  
  (defsubst eieio-defgeneric-reset-generic-form-primary-only-one (method)
    "Setup METHOD to call the generic form."

Re: CEDET merge

[Chong Yidong]

Chong Yidong <cyd@gnu.org> writes:

> I've done the merge, omitting senator and the defadvices as you
> suggested.

Actually, I seem to be having uploading to bzr right now.  If it doesn't
go through tonight, I'll try again tomorrow.

Re: CEDET merge

[Chong Yidong]

Chong Yidong <cyd@gnu.org> writes:

> To replace the defadvice, it is acceptable to just change the code of
> hif-defined and hif-lookup directly to refer to
> semantic-c-takeover-hideif (if it is bound); no need to use a hook.
> Feel free to submit a patch, or I'll get around to it when I have the
> time.

I've done that now (see the patch below, committed to trunk).

=== modified file 'lisp/progmodes/hideif.el'
*** lisp/progmodes/hideif.el	2012-08-22 07:17:52 +0000
--- lisp/progmodes/hideif.el	2012-10-02 15:19:52 +0000
***************
*** 329,344 ****
    "Prepend (var value) pair to hide-ifdef-env."
    (setq hide-ifdef-env (cons (cons var value) hide-ifdef-env)))
  
  
  (defun hif-lookup (var)
!   ;; (message "hif-lookup %s" var)
!   (let ((val (assoc var hide-ifdef-env)))
!     (if val
! 	(cdr val)
!       hif-undefined-symbol)))
  
  (defun hif-defined (var)
!    (if (assoc var hide-ifdef-env) 1 0))
  
  ;;===%%SF%% evaluation (End)  ===
  
--- 329,351 ----
    "Prepend (var value) pair to hide-ifdef-env."
    (setq hide-ifdef-env (cons (cons var value) hide-ifdef-env)))
  
+ (declare-function semantic-c-hideif-lookup  "semantic/bovine/c" (var))
+ (declare-function semantic-c-hideif-defined "semantic/bovine/c" (var))
  
  (defun hif-lookup (var)
!   (or (when (bound-and-true-p semantic-c-takeover-hideif)
! 	(semantic-c-hideif-lookup var))
!       (let ((val (assoc var hide-ifdef-env)))
! 	(if val
! 	    (cdr val)
! 	  hif-undefined-symbol))))
  
  (defun hif-defined (var)
!   (cond
!    ((bound-and-true-p semantic-c-takeover-hideif)
!     (semantic-c-hideif-defined var))
!    ((assoc var hide-ifdef-env) 1)
!    (t 0)))
  
  ;;===%%SF%% evaluation (End)  ===
  

.

Re: CEDET merge

[David Engster]

David Engster writes:
> I left the grammars and parser generator in admin/grammars for now, but
> IMO the generator bovine-grammar.el and wisent-grammar.el should
> eventually be moved to their proper locations underneath lisp/. The main
> grammar generation is already in lisp/semantic/grammar.el and hence was
> in Emacs all the time; the two files above are just refinements for the
> two different grammar styles.

Any chance we can do this for 24.3.? I think this is a frequently
requested feature.

-David

Re: CEDET merge

[Chong Yidong]

David Engster <deng@randomsample.de> writes:

>> I left the grammars and parser generator in admin/grammars for now, but
>> IMO the generator bovine-grammar.el and wisent-grammar.el should
>> eventually be moved to their proper locations underneath lisp/. The main
>> grammar generation is already in lisp/semantic/grammar.el and hence was
>> in Emacs all the time; the two files above are just refinements for the
>> two different grammar styles.
>
> Any chance we can do this for 24.3.? I think this is a frequently
> requested feature.

Which subdirectory should they go in?

Re: CEDET merge

[David Engster]

Chong Yidong writes:
> David Engster <deng@randomsample.de> writes:
>
>>> I left the grammars and parser generator in admin/grammars for now, but
>>> IMO the generator bovine-grammar.el and wisent-grammar.el should
>>> eventually be moved to their proper locations underneath lisp/. The main
>>> grammar generation is already in lisp/semantic/grammar.el and hence was
>>> in Emacs all the time; the two files above are just refinements for the
>>> two different grammar styles.
>>
>> Any chance we can do this for 24.3.? I think this is a frequently
>> requested feature.
>
> Which subdirectory should they go in?

wisent-grammar.el would be renamed to lisp/cedet/semantic/wisent/grammar.el

bovine-grammar.el to lisp/cedet/semantic/bovine/grammar.el

I guess the functions `wisent-make-parsers' and `bovine-make-parsers'
and the variables they need could be put in a new file which stays in
admin/grammars, since you've added them specifically for the parser
generation in Emacs trunk.

I guess all that's left then is to add proper provide statements and
autoload cookies to the two above files (for the derived major modes and
for the additions to auto-mode-alist).

-David

Re: CEDET merge

[Chong Yidong]

David Engster <deng@randomsample.de> writes:

> wisent-grammar.el would be renamed to lisp/cedet/semantic/wisent/grammar.el
> bovine-grammar.el to lisp/cedet/semantic/bovine/grammar.el

Done, and the appropriate provide statements and autoload cookies added.

> I guess the functions `wisent-make-parsers' and `bovine-make-parsers'
> and the variables they need could be put in a new file which stays in
> admin/grammars, since you've added them specifically for the parser
> generation in Emacs trunk.

I think we can leave them in those files for now, until we fix the build
system to generate the parsers during the Emacs build process.

By the way, could you or Eric kindly write up a NEWS entry briefly
describing the major changes to CEDET since CEDET-1.0 / Emacs-24.2?

Re: CEDET merge

[Stefan Monnier]

> By the way, could you or Eric kindly write up a NEWS entry briefly
> describing the major changes to CEDET since CEDET-1.0 / Emacs-24.2?

I'm also interested to hear about how close we are to having Emacs's
CEDET and the upstream CEDET actually in sync (and kept in sync via
a semi-automatic process).


        Stefan

Re: CEDET merge

[David Engster]

Stefan Monnier writes:
>> By the way, could you or Eric kindly write up a NEWS entry briefly
>> describing the major changes to CEDET since CEDET-1.0 / Emacs-24.2?
>
> I'm also interested to hear about how close we are to having Emacs's
> CEDET and the upstream CEDET actually in sync (and kept in sync via
> a semi-automatic process).

Regarding the files which are both in Emacs and in CEDET: those are
pretty much in sync now except for some compatibility code we have to
keep for Emacs 23.1.. We also have some 'defadvice' hacks which we
obviously cannot merge. For getting rid of the defadvices, some changes
in Emacs core packages are needed, but I didn't have time to do that
before the freeze (for example, getting proper help buffers for EIEIO
classes and methods is pretty high on my TODO list).

There are still some packages which are only in CEDET upstream for
several reasons: They're either pretty new and not well tested, or are
in our 'contrib' directory and don't have proper papers, or because they
are a bit obscure (sorry Eric ;-) ) and well separated and hence would
better fit into ELPA. For example, I think Cogre (for generating UML
graphs) would be a good candidate for an ELPA package.

Also, we now have two additional branches in CEDET for doing merges to
and from Emacs; those are in fact "real" branches, meaning they have a
common history, and after the first batch of humongous merges they work
pretty painless now. The real work is in doing the 'diff|patch' thingy
from Emacs to CEDET, but I've written a package for that which makes
that fairly fast. All this should make it possible for me to do regular
merges from now on, like the Gnus/Org people do.

In addition, we are planning to move development of certain packages
completely to Emacs trunk. We already did that for Speedbar; the next
candidates are EIEIO and mode-local.

-David

Re: CEDET merge

[Stefan Monnier]

> Regarding the files which are both in Emacs and in CEDET: those are
> pretty much in sync now except for some compatibility code we have to
> keep for Emacs 23.1.. We also have some 'defadvice' hacks which we
> obviously cannot merge. For getting rid of the defadvices, some changes
> in Emacs core packages are needed, but I didn't have time to do that
> before the freeze (for example, getting proper help buffers for EIEIO
> classes and methods is pretty high on my TODO list).

OK.  I expect the removal of defadvice will require some changes to the
core, so probably some discussions to agree on how to do it, right?

> There are still some packages which are only in CEDET upstream for
> several reasons: They're either pretty new and not well tested, or are
> in our 'contrib' directory and don't have proper papers, or because they
> are a bit obscure (sorry Eric ;-) ) and well separated and hence would
> better fit into ELPA. For example, I think Cogre (for generating UML
> graphs) would be a good candidate for an ELPA package.

Adding those that can (i.e. that have the needed copyright paperwork) to
GNU ELPA would be great, yes.

> pretty painless now. The real work is in doing the 'diff|patch' thingy
> from Emacs to CEDET, but I've written a package for that which makes
> that fairly fast. All this should make it possible for me to do regular
> merges from now on, like the Gnus/Org people do.

Sounds good, thank you very much for that work.

> In addition, we are planning to move development of certain packages
> completely to Emacs trunk.  We already did that for Speedbar; the next
> candidates are EIEIO and mode-local.

Reminds me: we should start labeling the files not just with "who's the
maintainer" but also with "is there some external upstream".  Maybe by
adding a "Canonical-URL:" header for those externally-maintained files?

While we generally expect upstreams to take care of tracking the changes
we install, there are many cases where changes only make sense if
there's no external upstream.  E.g. switching from `cl' to `cl-lib',
where the upstream will probably not want to integrate this change
because they care about backward compatibility.

I have some approximate memory of which packages are externally
maintained and which don't, but it would help if I didn't have to rely
on that fuzzy memory.


        Stefan

Re: CEDET merge

[David Engster]

Stefan Monnier writes:
>> Regarding the files which are both in Emacs and in CEDET: those are
>> pretty much in sync now except for some compatibility code we have to
>> keep for Emacs 23.1.. We also have some 'defadvice' hacks which we
>> obviously cannot merge. For getting rid of the defadvices, some changes
>> in Emacs core packages are needed, but I didn't have time to do that
>> before the freeze (for example, getting proper help buffers for EIEIO
>> classes and methods is pretty high on my TODO list).
>
> OK.  I expect the removal of defadvice will require some changes to the
> core, so probably some discussions to agree on how to do it, right?

Sure. I have some ideas on how to do the help buffer stuff for EIEIO,
but it doesn't make sense to discuss this during the freeze.

>> There are still some packages which are only in CEDET upstream for
>> several reasons: They're either pretty new and not well tested, or are
>> in our 'contrib' directory and don't have proper papers, or because they
>> are a bit obscure (sorry Eric ;-) ) and well separated and hence would
>> better fit into ELPA. For example, I think Cogre (for generating UML
>> graphs) would be a good candidate for an ELPA package.
>
> Adding those that can (i.e. that have the needed copyright paperwork) to
> GNU ELPA would be great, yes.

Cogre was written by Eric, but maybe others have contributed. We will
have to look that up.

> Reminds me: we should start labeling the files not just with "who's the
> maintainer" but also with "is there some external upstream".  Maybe by
> adding a "Canonical-URL:" header for those externally-maintained files?

I think a simple flag would suffice, so that those files are excluded
from large changes which break compatibility to older versions, like the
move to `cl-lib'.

-David

Re: CEDET merge

[Glenn Morris]

David Engster wrote:

> There are still some packages which are only in CEDET upstream for
> several reasons: They're either pretty new and not well tested, or are
> in our 'contrib' directory and don't have proper papers, or because they
> are a bit obscure (sorry Eric ;-) ) and well separated and hence would
> better fit into ELPA.

Is there a reason why Emacs does not have the srecode manual?

http://debbugs.gnu.org9966

Re: CEDET merge

[Glenn Morris]

Glenn Morris wrote:

> Is there a reason why Emacs does not have the srecode manual?
>
> http://debbugs.gnu.org9966

Similar question for semantic/adebug.el:

http://debbugs.gnu.org/5761

Re: CEDET merge

[David Engster]

Glenn Morris writes:
> Glenn Morris wrote:
>
>> Is there a reason why Emacs does not have the srecode manual?
>>
>> http://debbugs.gnu.org9966
>
> Similar question for semantic/adebug.el:
>
> http://debbugs.gnu.org/5761

I don't know why those manuals were not included during the first
merge. I guess they should be merged now if the papers for them are in
order.

-David

Re: CEDET merge

[David Engster]

Glenn Morris writes:
>>> Is there a reason why Emacs does not have the srecode manual?
>>>
>>> http://debbugs.gnu.org9966

To revive this thread: I think the following manuals are currently
missing from Emacs:

- Srecode, as mentioned by Glen above
- Bovine and Wisent, which are now proper Emacs packages and hence their
  manuals should be present.

I've skimmed the logs and the Srecode docs were pretty much completely
written by Eric. Wisent and Bovine were written by David Ponce and
Eric. Also, Richard Y. Kim is credited in the AUTHOR line.

-David

Re: CEDET merge

[Glenn Morris]

David Engster wrote:

> To revive this thread: I think the following manuals are currently
> missing from Emacs:
>
> - Srecode, as mentioned by Glen above
> - Bovine and Wisent, which are now proper Emacs packages and hence their
>   manuals should be present.
>
> I've skimmed the logs and the Srecode docs were pretty much completely
> written by Eric. Wisent and Bovine were written by David Ponce and
> Eric. Also, Richard Y. Kim is credited in the AUTHOR line.

Thanks for following up. If everyone who wrote non-trivial portions of
these manuals has a copyright assignment, then I can't see any reason
not to include them in Emacs. For Richard Kim, it looks like anything
before 2010-1-8 is definitely fine.

Re: CEDET merge

[Glenn Morris]

Do you need help adding these manuals to Emacs?

Re: CEDET merge

[David Engster]

Glenn Morris writes:
> Do you need help adding these manuals to Emacs?

Maybe I didn't make myself clear, but I'm actually waiting for a "yes,
go ahead" from the maintainers. Maybe there *is* a reason why the
SRecode manual wasn't merged initially.

-David

Re: CEDET merge

[Glenn Morris]

David Engster wrote:

> Maybe there *is* a reason why the SRecode manual wasn't merged initially.

That's question that started this, 6 weeks ago:

http://lists.gnu.org/archive/html/emacs-devel/2012-10/msg00347.html

I'm interpreting no answer to mean "there is no reason"...

Re: CEDET merge

[Chong Yidong]

David Engster <deng@randomsample.de> writes:

> Maybe I didn't make myself clear, but I'm actually waiting for a "yes,
> go ahead" from the maintainers. Maybe there *is* a reason why the
> SRecode manual wasn't merged initially.

Yes, please go ahead.  Thanks.

Re: CEDET merge

[David Engster]

Chong Yidong writes:
> David Engster <deng@randomsample.de> writes:
>
>> wisent-grammar.el would be renamed to lisp/cedet/semantic/wisent/grammar.el
>> bovine-grammar.el to lisp/cedet/semantic/bovine/grammar.el
>
> Done, and the appropriate provide statements and autoload cookies added.

Thanks. I forgot one thing: For generating a parser, Semantic must be
enabled. That means, if a user just loads a grammar and hits C-c C-c
without Semantic being enabled, he'll get a "bad input grammar"
error. We have actually the same problem with Srecode templates (see Bug
#9968).

I think it is clearly not a good idea to simply enable Semantic globally
in this case. Instead, we could enable it only for the current buffer by
putting

  (unless semantic-mode
    (require 'semantic)
    (semantic-new-buffer-fcn))

into bovine/wisent-grammar-mode and srecode-template-mode. I think this
should always work. Eric, please correct me if I'm wrong.

>> I guess the functions `wisent-make-parsers' and `bovine-make-parsers'
>> and the variables they need could be put in a new file which stays in
>> admin/grammars, since you've added them specifically for the parser
>> generation in Emacs trunk.
>
> I think we can leave them in those files for now, until we fix the build
> system to generate the parsers during the Emacs build process.

OK.

> By the way, could you or Eric kindly write up a NEWS entry briefly
> describing the major changes to CEDET since CEDET-1.0 / Emacs-24.2?

Sure. We have a NEWS file for the CEDET 1.1 release, so we just have to
extract the relevant portions from there.

-David

Re: CEDET merge

[Alex Ott]

Hi all

Is it possible to update Java parts of CEDET in Emacs with the
changes, that were made last weeks? At least for cedet-java.el &
db-javap.el - I think, that these changes can be useful for many Emacs
users who are using it to program Java...

On Sun, Sep 30, 2012 at 3:55 PM, David Engster <deng@randomsample.de> wrote:
> David Engster writes:
>> Stefan Monnier writes:
>>>> the other way round. I think I should be able to have our 'to-emacs'
>>>> branch ready till October 1st, which could then be merged in.
>>>
>>> This merge is important, yes.  Please let us know if you can't make it
>>> for October 1st.
>>
>> Please do not commit this patch yet, since it definitely needs some
>> further testing. My plan is to check the code with our test suite, which
>> will need a few tweaks first to work with stock Emacs, though.
>
> I've checked the new code base with our test suite and fixed a bunch of
> stuff. Everything's working now except for a few minor things, so I
> think the branch is now ready for merging.
>
> You can obtain a patch file from our 'to-emacs' branch (for details see
> my last mail), but I've also attached it to this message so everyone can
> check it easily. There's no ChangeLog yet, so if you want to check the
> logs you still need our 'to-emacs' branch.
>
> Please take a look at the issues I raised in my previous mail, since
> they still apply (esp. regarding checking for papers).
>
> Additionally, I've also regenerated the Elisp parsers from the updated
> grammar files. This converted some more explicit copyright ranges like
>
> Copyright (C) 2002-2004, 2007, 2010-2012  Free Software Foundation, Inc
>
> to a simple range like this
>
> Copyright (C) 2002-2012 Free Software Foundation, Inc.
>
> Is this acceptable? Also, it removed the 'Author: David Ponce' line from
> cedet/semantic/grammar.el, but I think it didn't make sense anyway since
> it is a generated file (from admin/grammars/grammar.wy, where he's still
> credited).
>
> I left the grammars and parser generator in admin/grammars for now, but
> IMO the generator bovine-grammar.el and wisent-grammar.el should
> eventually be moved to their proper locations underneath lisp/. The main
> grammar generation is already in lisp/semantic/grammar.el and hence was
> in Emacs all the time; the two files above are just refinements for the
> two different grammar styles.
>
> -David
>



-- 
With best wishes,                    Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)
Skype: alex.ott

Re: Feature freeze on October 1

[Bastien]

Chong Yidong <cyd@gnu.org> writes:

> The trunk is just about ready to go into feature freeze for the 24.3
> release.  We will begin the freeze on October 1, a couple of weeks from
> now.  If you are working on a feature that you'd like included in 24.3,
> please commit it before October 1 or ask for an extension.

Thanks for letting us know!

Org 7.9 has been released three weeks ago and I plan to release 
Org 7.9.2 by the next sunday (minor release are bug-fix only releases.)

I will commit Org 7.9.2 by October 1st.

-- 
 Bastien

Re: Feature freeze on October 1

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Date: Sun, 16 Sep 2012 09:55:48 +0800
> 
> The trunk is just about ready to go into feature freeze for the 24.3
> release.  We will begin the freeze on October 1, a couple of weeks from
> now.  If you are working on a feature that you'd like included in 24.3,
> please commit it before October 1 or ask for an extension.

Can we please get rid of the memory allocation (in load_charset_map)
during a call to maybe_unify_char, which already caused trouble during
release of 24.2?  I had a couple of crashes in Emacs 24.2 lately, all
of them inside ralloc.c.  I'm currently trying a change that could
avoid the crashes, but I think the ultimate fix would be not to
disable relocation at all, as ralloc.c was probably not really
designed for that.

Perhaps Handa-san could describe what would it take to get rid of
maybe_unify_char, or at least the large memory allocation inside it?
Then we could decide whether I or someone else could do that in time,
if Handa-san cannot.

TIA.

Re: Feature freeze on October 1

[Stefan Monnier]

> Can we please get rid of the memory allocation (in load_charset_map)
> during a call to maybe_unify_char, which already caused trouble during
> release of 24.2?

That would be very welcome, yes.  I asked Handa-san to look into it, but
it seems that he hasn't found time for it yet.  IIRC the main issue is
to move unification from the time when we read a char from the buffer to
the time we read a char from outside Emacs.  AFAIK unification is
already performed when we read a char from outside Emacs, so maybe all
it takes is to remove the maybe_unify_char thingy?


        Stefan

Re: Feature freeze on October 1

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Chong Yidong <cyd@gnu.org>, Kenichi Handa <handa@gnu.org>,
>         emacs-devel@gnu.org
> Date: Mon, 17 Sep 2012 12:54:50 -0400
> 
> AFAIK unification is already performed when we read a char from
> outside Emacs

Where does that happen in the code?

Re: Feature freeze on October 1

[Stefan Monnier]

>> AFAIK unification is already performed when we read a char from
>> outside Emacs
> Where does that happen in the code?

I assume it's done in the coding-system's decoding code.


        Stefan

Re: Feature freeze on October 1

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: handa@gnu.org, cyd@gnu.org, emacs-devel@gnu.org
> Date: Mon, 17 Sep 2012 15:36:42 -0400
> 
> >> AFAIK unification is already performed when we read a char from
> >> outside Emacs
> > Where does that happen in the code?
> 
> I assume it's done in the coding-system's decoding code.

But that doesn't get run (or at least not always) when a character is
typed on the keyboard, does it?  E.g., on MS-Windows characters are
read directly in Unicode when possible.  I'm sure Emacs does something
like that on X as well.

So it looks like some un-unified characters can still sneak into the
buffer.

> so maybe all it takes is to remove the maybe_unify_char thingy?

Not sure that's all.  I hope Handa-san could outline the plan for
attacking this problem, then maybe I could work on at least part of
that, if not all of it.

Re: Feature freeze on October 1

[Stefan Monnier]

>> I assume it's done in the coding-system's decoding code.
> But that doesn't get run (or at least not always) when a character is
> typed on the keyboard, does it?

Coding-system decoding is sometimes applied to keyboard events
(e.g. under ttys) but not always, indeed.

> E.g., on MS-Windows characters are read directly in Unicode when
> possible.  I'm sure Emacs does something like that on X as well.

Indeed, and that should be just fine, there's no need for additional
unification if we already have a Unicode char.

> So it looks like some un-unified characters can still sneak into the
> buffer.

The un-unified chars are those outside of Unicode, so it shouldn't be
an issue.

>> so maybe all it takes is to remove the maybe_unify_char thingy?
> Not sure that's all.  I hope Handa-san could outline the plan for
> attacking this problem, then maybe I could work on at least part of
> that, if not all of it.

Yup.


        Stefan

Re: Feature freeze on October 1

[Kenichi Handa]

Very sorry for the late response on this matter.

In article <83ehlvy2ec.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> > Cc: handa@gnu.org, cyd@gnu.org, emacs-devel@gnu.org
> > Date: Mon, 17 Sep 2012 15:36:42 -0400
> > 
> > >> AFAIK unification is already performed when we read a char from
> > >> outside Emacs
> > > Where does that happen in the code?
> > 
> > I assume it's done in the coding-system's decoding code.

Yes.

> But that doesn't get run (or at least not always) when a character is
> typed on the keyboard, does it?  E.g., on MS-Windows characters are
> read directly in Unicode when possible.  I'm sure Emacs does something
> like that on X as well.

> So it looks like some un-unified characters can still sneak into the
> buffer.

On X, Emacs uses X input method which returns characters
encoded in the current locale, and thus Emacs decodes them
by Vlocale_coding_system.  So, the unification should be
done here too.

> > so maybe all it takes is to remove the maybe_unify_char thingy?

> Not sure that's all.  I hope Handa-san could outline the plan for
> attacking this problem, then maybe I could work on at least part of
> that, if not all of it.

I have not yet figured out in detail the effect, but, what
should be done, I think, is to remove the call of
MAYBE_UNIFY_CHAR in char_string and string_char of
character.c.

---
Kenichi Handa
handa@gnu.org

Re: Feature freeze on October 1

[Eli Zaretskii]

> From: Kenichi Handa <handa@gnu.org>
> Cc: monnier@IRO.UMontreal.CA, cyd@gnu.org, emacs-devel@gnu.org
> Date: Sun, 23 Sep 2012 11:05:12 +0900
> 
> I have not yet figured out in detail the effect, but, what
> should be done, I think, is to remove the call of
> MAYBE_UNIFY_CHAR in char_string and string_char of
> character.c.

Thanks.  I'll have a stab at that soon.

Is the October 1 deadline still valid, btw?  Or did it move?

Re: Feature freeze on October 1

[Eli Zaretskii]

> Date: Mon, 24 Sep 2012 16:40:22 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: cyd@gnu.org, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org
> 
> > From: Kenichi Handa <handa@gnu.org>
> > Cc: monnier@IRO.UMontreal.CA, cyd@gnu.org, emacs-devel@gnu.org
> > Date: Sun, 23 Sep 2012 11:05:12 +0900
> > 
> > I have not yet figured out in detail the effect, but, what
> > should be done, I think, is to remove the call of
> > MAYBE_UNIFY_CHAR in char_string and string_char of
> > character.c.
> 
> Thanks.  I'll have a stab at that soon.

I did that in trunk revision 110192.

Should we also remove MAYBE_UNIFY_CHAR and maybe_unify_char as well?
And what about CHAR_STRING_ADVANCE_NO_UNIFY and
STRING_CHAR_ADVANCE_NO_UNIFY?  Should we remove them and use,
respectively, CHAR_STRING_ADVANCE and STRING_CHAR_ADVANCE instead?  Or
do we want to leave all these in place for now, to keep the option of
going back to using the unification in some cases?

Re: Feature freeze on October 1

[Kenichi Handa]

In article <837griinsy.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> Should we also remove MAYBE_UNIFY_CHAR and maybe_unify_char as well?

No, they are still used in decode_char.

> And what about CHAR_STRING_ADVANCE_NO_UNIFY and
> STRING_CHAR_ADVANCE_NO_UNIFY?  Should we remove them and use,
> respectively, CHAR_STRING_ADVANCE and STRING_CHAR_ADVANCE instead?
> Or do we want to leave all these in place for now, to keep
> the option of going back to using the unification in some
> cases?

Ummm, how about doing this in coding.c and don't change the
callers.

#define CHAR_STRING_ADVANCE_NO_UNIFY CHAR_STRING_ADVANCE
#define STRING_CHAR_ADVANCE_NO_UNIFY STRING_CHAR_ADVANCE

Then we won't forget that callers expect non-unify versions.

---
Kenichi Handa
handa@gnu.org

Re: Feature freeze on October 1

[Eli Zaretskii]

> From: Kenichi Handa <handa@gnu.org>
> Cc: cyd@gnu.org, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org
> Date: Tue, 25 Sep 2012 21:12:41 +0900
> 
> > And what about CHAR_STRING_ADVANCE_NO_UNIFY and
> > STRING_CHAR_ADVANCE_NO_UNIFY?  Should we remove them and use,
> > respectively, CHAR_STRING_ADVANCE and STRING_CHAR_ADVANCE instead?
> > Or do we want to leave all these in place for now, to keep
> > the option of going back to using the unification in some
> > cases?
> 
> Ummm, how about doing this in coding.c and don't change the
> callers.
> 
> #define CHAR_STRING_ADVANCE_NO_UNIFY CHAR_STRING_ADVANCE
> #define STRING_CHAR_ADVANCE_NO_UNIFY STRING_CHAR_ADVANCE
> 
> Then we won't forget that callers expect non-unify versions.

Done as trunk revision 110196.

Thanks.

Re: Feature freeze on October 1

[Kenichi Handa]

In article <833926i82o.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > #define CHAR_STRING_ADVANCE_NO_UNIFY CHAR_STRING_ADVANCE
> > #define STRING_CHAR_ADVANCE_NO_UNIFY STRING_CHAR_ADVANCE
> > 
> > Then we won't forget that callers expect non-unify versions.

> Done as trunk revision 110196.

Thank you!

By the way, I vaguely remember that some workaround code was
added to avoid the buffer relocation problem.  Do you
remember where was it?  Or, is it just my false memory?

---
Kenichi Handa
handa@gnu.org

Re: Feature freeze on October 1

[Eli Zaretskii]

> From: Kenichi Handa <handa@gnu.org>
> Cc: cyd@gnu.org, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org
> Date: Wed, 26 Sep 2012 22:57:35 +0900
> 
> In article <833926i82o.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > #define CHAR_STRING_ADVANCE_NO_UNIFY CHAR_STRING_ADVANCE
> > > #define STRING_CHAR_ADVANCE_NO_UNIFY STRING_CHAR_ADVANCE
> > > 
> > > Then we won't forget that callers expect non-unify versions.
> 
> > Done as trunk revision 110196.
> 
> Thank you!

Thanks for your guidance.

> By the way, I vaguely remember that some workaround code was
> added to avoid the buffer relocation problem.  Do you
> remember where was it?  Or, is it just my false memory?

Your memory is fine.  The workaround code is in ralloc.c and in
maybe_unify_char.  But since we still call maybe_unify_char in
decode_char, I don't think we can remove those workarounds yet, can
we?

Re: Feature freeze on October 1

[Stefan Monnier]

> Your memory is fine.  The workaround code is in ralloc.c and in
> maybe_unify_char.  But since we still call maybe_unify_char in
> decode_char, I don't think we can remove those workarounds yet, can
> we?

Are there calls to decode_char which aren't prepared to run Elisp code?


        Stefan

Re: Feature freeze on October 1

[Kenichi Handa]

In article <jwvlifwsh1f.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> > Your memory is fine.  The workaround code is in ralloc.c and in
> > maybe_unify_char.  But since we still call maybe_unify_char in
> > decode_char, I don't think we can remove those workarounds yet, can
> > we?

> Are there calls to decode_char which aren't prepared to run Elisp code?

maybe_unify_char doesn't run Elisp code but allocates a Lisp
vector and a Lisp chartable via load_charset.

And I'm not sure that all calls to decode_char are prepared
to buffer/string relocation.

---
Kenichi Handa
handa@gnu.org

Re: Feature freeze on October 1

[Stefan Monnier]

>> > Your memory is fine.  The workaround code is in ralloc.c and in
>> > maybe_unify_char.  But since we still call maybe_unify_char in
>> > decode_char, I don't think we can remove those workarounds yet, can
>> > we?
>> Are there calls to decode_char which aren't prepared to run Elisp code?
> maybe_unify_char doesn't run Elisp code but allocates a Lisp
> vector and a Lisp chartable via load_charset.

Oh, indeed, I see it should not be able to run arbitrary Elisp, so the
damage is a bit more limited.

> And I'm not sure that all calls to decode_char are prepared
> to buffer/string relocation.

String relocation only happens during GC, which normally only happens
during Elisp evaluation, so that shouldn't be an issue.
But, yes, it seems that ccl.c and maybe coding.c both have uses of
decode_char where buffer relocation can cause problems
(CODING_DECODE_CHAR seems to try and handle it explicitly, but I'm not
sure it's sufficient).


        Stefan

Re: Feature freeze on October 1

[Kenichi Handa]

In article <jwv626zy6nx.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > And I'm not sure that all calls to decode_char are prepared
> > to buffer/string relocation.

> String relocation only happens during GC, which normally only happens
> during Elisp evaluation, so that shouldn't be an issue.

I see.

> But, yes, it seems that ccl.c and maybe coding.c both have uses of
> decode_char where buffer relocation can cause problems

In ccl.c, ccl_driver uses DECODE_CHAR, and ccl_driver itself
has no problem because it doesn't uses a pointer into
buffer/string.  But, I noticed that the callers of that
function in coding.c (decode_coding_ccl and
encode_coding_ccl) has to prepare for buffer relocation.
I've just installed a fix.

> (CODING_DECODE_CHAR seems to try and handle it explicitly, but I'm not
> sure it's sufficient).

At least, it should be sufficient for pointers used by code
conversion routines.  Isn't it?

---
Kenichi Handa
handa@gnu.org

Re: Feature freeze on October 1

[Stefan Monnier]

> In ccl.c, ccl_driver uses DECODE_CHAR, and ccl_driver itself
> has no problem because it doesn't uses a pointer into
> buffer/string.  But, I noticed that the callers of that
> function in coding.c (decode_coding_ccl and
> encode_coding_ccl) has to prepare for buffer relocation.
> I've just installed a fix.

Great, thank you.

>> (CODING_DECODE_CHAR seems to try and handle it explicitly, but I'm not
>> sure it's sufficient).
> At least, it should be sufficient for pointers used by code
> conversion routines.  Isn't it?

I have no particular reason to think it's not sufficient, but I haven't
looked closely enough to convince myself that it is.


        Stefan

Re: Feature freeze on October 1

[Stefan Monnier]

> Should we also remove MAYBE_UNIFY_CHAR and maybe_unify_char as well?

I think so, yes.

> And what about CHAR_STRING_ADVANCE_NO_UNIFY and
> STRING_CHAR_ADVANCE_NO_UNIFY?  Should we remove them and use,
> respectively, CHAR_STRING_ADVANCE and STRING_CHAR_ADVANCE instead?

Yes.

> Or do we want to leave all these in place for now, to keep the option
> of going back to using the unification in some cases?

We have the Bazaar history for that.


        Stefan

Re: Feature freeze on October 1

[Tassilo Horn]

Chong Yidong <cyd@gnu.org> writes:

> The trunk is just about ready to go into feature freeze for the 24.3
> release.  We will begin the freeze on October 1, a couple of weeks
> from now.  If you are working on a feature that you'd like included in
> 24.3, please commit it before October 1 or ask for an extension.

Ok, I have a new doc-view feature in the queue which allows slicing
according to BoundingBox information.  Basically, that allows for
setting the optimal slice, i.e., all margins are completely cropped.
I didn't need to modify existing code, just add some new functions, so
I'm rather confident it won't break anything that works now.

I need to do some more testing and document that feature, but I'll be
ready before October 1st.

Bye,
Tassilo

Re: Feature freeze on October 1

[Stefan Merten]

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

Hi!

4 days ago Chong Yidong wrote:
> If you are working on a feature that you'd like included in 24.3,
> please commit it before October 1 or ask for an extension.

I'm currently working on integration of `imenu'/`which-func' support
for `rst-mode'. Bug #11711 - being a feature request - has a patch
which seems to work. However, a proper integration needs refactoring
of the patch and a few other parts. I'm into this right now but given
my two week vacation starting next week I won't be able to commit a
final version of this feature before October 1.

Second I'd like to revamp the faces for section headers. At the moment
there is some automatic calculation of the faces but in the past this
caused some pain for users and I decided to replace it with normal
`defface'. AFAICS this is not much work but a user visible change.
Again I can't commit this before October 1.

So I'd like to ask for an extension until October 15. Is that ok?

> As usual, once the freeze is in effect, please commit only bug fixes to
> the trunk, i.e. no new features or non-trivial internals changes.  If
> you would like an exception, ask for one on emacs-devel.

I have a lot of ert-based tests for my `rst-mode' and as `testcover'
told me I have a really good test coverage :-) . Therefore I'm pretty
sure I won't break anything when refactoring. Under these conditions
is refactoring allowed even after the freeze?

In this case I could commit the current `imenu'/`which-func' feature
immediately and refactor it later and now work on the face stuff. This
may result in a shorter extension period.

In addition I'd like to know how long the trunk is frozen.


						Grüße

						Stefan

[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]

Re: Feature freeze on October 1

[Chong Yidong]

Stefan Merten <smerten@oekonux.de> writes:

> I'm currently working on integration of `imenu'/`which-func' support
> for `rst-mode'. Bug #11711 - being a feature request - has a patch
> which seems to work. However, a proper integration needs refactoring
> of the patch and a few other parts. I'm into this right now but given
> my two week vacation starting next week I won't be able to commit a
> final version of this feature before October 1.
>
> Second I'd like to revamp the faces for section headers. At the moment
> there is some automatic calculation of the faces but in the past this
> caused some pain for users and I decided to replace it with normal
> `defface'. AFAICS this is not much work but a user visible change.
> Again I can't commit this before October 1.
>
> So I'd like to ask for an extension until October 15. Is that ok?

OK, assuming your changes are localized to imenu/which-func/rst-mode.

> In addition I'd like to know how long the trunk is frozen.

We are planning to experiment with a short freeze this time round.  The
current idea is to freeze for about a month, make the release branch,
then open the trunk for commits.  More details will be forthcoming.

Re: Feature freeze on October 1

[Leo]

On 2012-09-21 11:07 +0800, Chong Yidong wrote:
> We are planning to experiment with a short freeze this time round.  The
> current idea is to freeze for about a month, make the release branch,
> then open the trunk for commits.  More details will be forthcoming.

This looks like an excellent scheme!

Leo

Re: Feature freeze on October 1

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Date: Fri, 21 Sep 2012 11:07:43 +0800
> Cc: emacs-devel@gnu.org
> 
> We are planning to experiment with a short freeze this time round.  The
> current idea is to freeze for about a month, make the release branch,
> then open the trunk for commits.

Not sure what would be the difference between one-month freeze and
zero-month freeze.

Re: Feature freeze on October 1

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> We are planning to experiment with a short freeze this time round.  The
>> current idea is to freeze for about a month, make the release branch,
>> then open the trunk for commits.
>
> Not sure what would be the difference between one-month freeze and
> zero-month freeze.

Judging by past experience, the month after the freeze is spent cleaning
up various changes squeezed in at (and after) the last minute.  A
one-month freeze seems like a good solution, to avoid dealing with the
hassle of merging to another branch during this period.

Re: Feature freeze on October 1

[Stefan Monnier]

>> We are planning to experiment with a short freeze this time round.  The
>> current idea is to freeze for about a month, make the release branch,
>> then open the trunk for commits.
> Not sure what would be the difference between one-month freeze and
> zero-month freeze.

There's also the fear that a zero month freeze would lead to too many
people continuing the use the trunk without paying any attention to the
release branch.


        Stefan

Re: Feature freeze on October 1

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Not sure what would be the difference between one-month freeze and
 > zero-month freeze.

Speaking from experience and observation, more testing.  Some people
will never test the release code, some people will always test it.
For some people in the middle, not needing to switch to a branch means
that they will test that code until the branch is actually made.

Whether it will actually work that way for Emacs, you won't know until
you try it.

Steve

Re: Feature freeze on October 1

[Stefan Merten]

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

Hi!

I found more time for working on `rst-mode' then I expected :-) .

2 days ago Chong Yidong wrote:
> Stefan Merten <smerten@oekonux.de> writes:
>> I'm currently working on integration of `imenu'/`which-func' support
>> for `rst-mode'. Bug #11711 - being a feature request - has a patch
>> which seems to work. However, a proper integration needs refactoring
>> of the patch and a few other parts. I'm into this right now but given
>> my two week vacation starting next week I won't be able to commit a
>> final version of this feature before October 1.

I already committed a version although it needs some refactoring. In
principle my last version can go into 24.3 though. It's functionally
complete.

>> Second I'd like to revamp the faces for section headers. At the moment
>> there is some automatic calculation of the faces but in the past this
>> caused some pain for users and I decided to replace it with normal
>> `defface'. AFAICS this is not much work but a user visible change.
>> Again I can't commit this before October 1.

That was much easier than I thought and I already committed a version
with this stuff.

I released this version upstream, too, so if anything went wrong for
this stuff I think I'll get response soon and can fix it after the
freeze period.

>> So I'd like to ask for an extension until October 15. Is that ok?
> 
> OK, assuming your changes are localized to imenu/which-func/rst-mode.

Thanks. However, having completed my homework sooner than I expected
the current state of `rst.el' can be frozen, actually.


						Grüße

						Stefan

[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]

Re: Feature freeze on October 1

[Stefan Monnier]

> Thanks. However, having completed my homework sooner than I expected
> the current state of `rst.el' can be frozen, actually.

Great, thanks,


        Stefan