CEDET Merge

CEDET Merge

[Edward John Steere]

Hello Everyone,

I've been working on a branch in upstream CEDET which brings it up to
date with the changes which have been made in Emacs core.  I started
this work with the intention of simplifying the merge process from CEDET
upstream into core so that users can benefit from improvements to CEDET
more easily.  I found that the divergence between the two versions of
CEDET has grown quite a bit and all of my work has been dedicated to
getting it to run on Emacs master (26?).

My branch now passes all of CEDETs tests when built against Emacs
@512e988.  I'd like to get these changes synchronised with Emacs core
and have my branch merged to upstream (i.e. CEDET on source forge).

This could be the first step with the second being a repackaging of
upstream so that it only contains the parts which are under active
development and can be installed via ELPA.

May I contribute my changes to a branch on the Savannah repository for
review/commentary?  (If yes, then It'll take a little bit of time to
merge the changes in my branch of CEDET back into Emacs core before I
actually push them up.)

Kind regards,

Edward Steere

Re: CEDET Merge

[Eli Zaretskii]

> From: Edward John Steere <edward.steere@gmail.com>
> Date: Thu, 12 Jan 2017 21:32:36 +0200
> 
> May I contribute my changes to a branch on the Savannah repository for
> review/commentary?

Yes, of course.  Thanks for working on this.

Re: CEDET Merge

[Edward John Steere]

>> From: Edward John Steere <edward.steere@gmail.com>
>> Date: Thu, 12 Jan 2017 21:32:36 +0200
>> 
>> May I contribute my changes to a branch on the Savannah repository for
>> review/commentary?
>
> Yes, of course.  Thanks for working on this.

Great I'll get to work on it and follow up when it's ready.

Re: CEDET Merge

[Bastian Beischer]

Hey Edward,

On Thu, Jan 12, 2017 at 8:32 PM, Edward John Steere
<edward.steere@gmail.com> wrote:
> Hello Everyone,
>
> I've been working on a branch in upstream CEDET which brings it up to
> date with the changes which have been made in Emacs core.  I started
> this work with the intention of simplifying the merge process from CEDET
> upstream into core so that users can benefit from improvements to CEDET
> more easily.  I found that the divergence between the two versions of
> CEDET has grown quite a bit and all of my work has been dedicated to
> getting it to run on Emacs master (26?).
>
> My branch now passes all of CEDETs tests when built against Emacs
> @512e988.  I'd like to get these changes synchronised with Emacs core
> and have my branch merged to upstream (i.e. CEDET on source forge).
>
> This could be the first step with the second being a repackaging of
> upstream so that it only contains the parts which are under active
> development and can be installed via ELPA.
>
> May I contribute my changes to a branch on the Savannah repository for
> review/commentary?  (If yes, then It'll take a little bit of time to
> merge the changes in my branch of CEDET back into Emacs core before I
> actually push them up.)

It's great to hear that you have been working on this. I'm also very
interested in getting CEDET upstream and CEDET in emacs synchronized
again. Please see also this bug report:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23792

This also contains a patch for the emacs sources which I've come up
with half a year ago, but it's probably incomplete and even wrong in
places. But maybe we can compare what we did.

Do you have a git repository cloned from CEDET upstream which contains
your work somewhere? Or did you start by modifying the built-in CEDET
in emacs?

>
> Kind regards,
>
> Edward Steere
>

Cheers
Bastian



-- 
Bastian Beischer
RWTH Aachen University of Technology

@RWTH Aachen
Office: 28 C 203
Phone: +49-241-80-27205
E-mail: beischer@physik.rwth-aachen.de
Address: I. Physikalisches Institut B, Sommerfeldstr. 14, D-52074 Aachen

@CERN
Office: Bdg 32-4-B12
Phone: +41-22-76-75750
E-mail: bastian.beischer@cern.ch
Address: CERN, CH-1211 Geneve 23

Re: CEDET Merge

[Edward John Steere]

Hi Bastian,

> It's great to hear that you have been working on this. I'm also very
> interested in getting CEDET upstream and CEDET in emacs synchronized
> again. Please see also this bug report:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23792

I remember seeing your post a while ago, but had forgotten about it.
I'll take a look now.

> This also contains a patch for the emacs sources which I've come up
> with half a year ago, but it's probably incomplete and even wrong in
> places. But maybe we can compare what we did.
>
> Do you have a git repository cloned from CEDET upstream which contains
> your work somewhere? Or did you start by modifying the built-in CEDET
> in emacs?

I tried various approaches (with varying degrees of success) before
going for something rather brute force: I diffed every file in CEDET
from Emacs core to it's corresponding file in upstream (creating a diff
file per file-pair) and applied the changes to upstream by hand.

At the moment my changes are living on a private repository.  I'd like
to do some tidying up with regards to commits before I make them
available.  I'll get to work on that tomorrow.

> Cheers
> Bastian

Kind regards,

Edward Steere

Re: CEDET Merge

[Edward John Steere]

> Hi Bastian,
>
>> It's great to hear that you have been working on this. I'm also very
>> interested in getting CEDET upstream and CEDET in emacs synchronized
>> again. Please see also this bug report:
>>
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23792
>
> I remember seeing your post a while ago, but had forgotten about it.
> I'll take a look now.
>
>> This also contains a patch for the emacs sources which I've come up
>> with half a year ago, but it's probably incomplete and even wrong in
>> places. But maybe we can compare what we did.
>>
>> Do you have a git repository cloned from CEDET upstream which contains
>> your work somewhere? Or did you start by modifying the built-in CEDET
>> in emacs?
>
> I tried various approaches (with varying degrees of success) before
> going for something rather brute force: I diffed every file in CEDET
> from Emacs core to it's corresponding file in upstream (creating a diff
> file per file-pair) and applied the changes to upstream by hand.
>
> At the moment my changes are living on a private repository.  I'd like
> to do some tidying up with regards to commits before I make them
> available.  I'll get to work on that tomorrow.
>
>> Cheers
>> Bastian
>
> Kind regards,
>
> Edward Steere

Hi All,

Please may I have some advice.  I've been trying to get my change merged
into Emacs core locally, and have had little (read no) success.  These
are the approaches I've tried so far (not verbatim):

 1. git remote add ~/wip/cedet cedet && git merge
 --allow-unrelated-histories etc.
 2. git subtree (not the right model because Cedet mirrors the layout of
    sources in Emacs core)
 3. rm -rf ~/wip/emacs/lisp/cedet && cp ~/wip/cedet/lisp/cedet ~/wip/emacs/cedet

I've opted for option 3 because I realised that I'd already done the
merge in the other direction and now the state of that branch should be
exactly reflected in core.  However, when I try to bootstrap Emacs I get
errors when loading loaddefs.el in lisp/.  It complains about
eieio-defclass-autoload being undefined -- which is fair enough because
that's only autoloaded later, removing the class autoloads which caused
the autoloads to be added produces the same error for
ede-project-autoload.  In the interests of seeing how far I could go
before completely bombing out I removed this autoload as well and I was
confronted with another autoload error, this time in the `jka'
compression library (!?)

What follows is the error with a few lines before it for context (you
can substitute the void variable error with a similar function is void
error for an idea of how the previous two errors looked):

make[3]: Leaving directory '/home/edward/emacs/leim'
LC_ALL=C ./temacs -batch  -l loadup dump
Loading loadup.el (source)...
Using load-path (/home/edward/emacs/lisp)
Loading emacs-lisp/byte-run...
Loading emacs-lisp/backquote...
Loading subr...
Loading version...
Loading widget...
Loading custom...
Loading emacs-lisp/map-ynp...
Loading international/mule...
Loading international/mule-conf...
Loading env...
Loading format...
Loading bindings...
Loading window...
Loading files...
Loading emacs-lisp/macroexp...
Loading cus-face...
Loading faces...
Loading button...
Loading loaddefs.el (source)...
Symbol's value as variable is void: jka-compr-load-suffixes
Makefile:546: recipe for target 'emacs' failed
make[2]: *** [emacs] Error 255
make[2]: Leaving directory '/home/edward/emacs/src'
Makefile:409: recipe for target 'src' failed
make[1]: *** [src] Error 2
make[1]: Leaving directory '/home/edward/emacs'
Makefile:1123: recipe for target 'bootstrap-build' failed
make: *** [bootstrap-build] Error 2

I would greatly appreciate any advice with regards to the best way to
debug errors like this in the build process.

Kind regards,

Edward Steere

Re: CEDET Merge

[Eli Zaretskii]

> From: Edward John Steere <edward.steere@gmail.com>
> Cc: 
> Date: Mon, 16 Jan 2017 20:45:01 +0200
> 
>  3. rm -rf ~/wip/emacs/lisp/cedet && cp ~/wip/cedet/lisp/cedet ~/wip/emacs/cedet
> 
> I've opted for option 3 because I realised that I'd already done the
> merge in the other direction and now the state of that branch should be
> exactly reflected in core.  However, when I try to bootstrap Emacs I get
> errors when loading loaddefs.el in lisp/.  It complains about
> eieio-defclass-autoload being undefined -- which is fair enough because
> that's only autoloaded later, removing the class autoloads which caused
> the autoloads to be added produces the same error for
> ede-project-autoload.  In the interests of seeing how far I could go
> before completely bombing out I removed this autoload as well and I was
> confronted with another autoload error, this time in the `jka'
> compression library (!?)
> 
> What follows is the error with a few lines before it for context (you
> can substitute the void variable error with a similar function is void
> error for an idea of how the previous two errors looked):

Did you try deleting loaddefs.el and running "make maintainer-clean"
before bootstrap?

If you did, and the problem persists, please show the offending parts
on loaddefs.el which trigger these errors.

Re: CEDET Merge

[Edward John Steere]

Hi Eli,

> Did you try deleting loaddefs.el and running "make maintainer-clean"
> before bootstrap?

I did, but to be sure I just did a fresh copy across and ran:
"make maintainer-clean && make bootstrap" and it failed again with the
same error.

> If you did, and the problem persists, please show the offending parts
> on loaddefs.el which trigger these errors.

Here are the offenders for the first error (they come from a new module
in Cedet called cogre):

;;;### (autoloads nil "cogre" "cedet/cogre.el" (0 0 0 0))
;;; Generated autoloads from cedet/cogre.el

(eieio-defclass-autoload 'cogre-graph-element '(eieio-named) "cogre" "A Graph Element.\nGraph elements are anything that is drawn into a `cogre-base-graph'.\nGraph elements have a method for marking themselves dirty.")

(eieio-defclass-autoload 'cogre-base-graph '(eieio-persistent) "cogre" "A Connected Graph.\na connected graph contains a series of nodes and links which are\nrendered in a buffer, or serialized to disk.")

(eieio-defclass-autoload 'cogre-node '(cogre-graph-element) "cogre" "Connected Graph node.\nNodes are regions with a fill color, and some amount of text representing\na status, or values.")

(eieio-defclass-autoload 'cogre-link '(cogre-graph-element) "cogre" "Connected Graph link.\nLinks are lines drawn between two nodes, or possibly loose in space\nas an intermediate step.  Some links have text describing what they\ndo, and most links have special markers on one end or another, such as\narrows or circles.")

(eieio-defclass-autoload 'cogre-arrow '(cogre-link) "cogre" "This type of link is a simple arrow.")


Here are the second offenders (they come from support for compdb and ninja):

(ede-add-project-autoload (ede-project-autoload :name "Compilation DB" :file 'ede/compdb :proj-file "compile_commands.json" :load-type 'ede-compdb-load-project :class-sym 'ede-compdb-project))

(ede-add-project-autoload (ede-project-autoload :name "Ninja" :file 'ede/compdb :proj-file "build.ninja" :load-type 'ede-ninja-load-project :class-sym 'ede-ninja-project))


I can't find any reference to the jka variable in loaddefs.

Kind regards,

Edward Steere

Re: CEDET Merge

[Eli Zaretskii]

> From: Edward John Steere <edward.steere@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 16 Jan 2017 21:55:23 +0200
> 
> Here are the second offenders (they come from support for compdb and ninja):
> 
> (ede-add-project-autoload (ede-project-autoload :name "Compilation DB" :file 'ede/compdb :proj-file "compile_commands.json" :load-type 'ede-compdb-load-project :class-sym 'ede-compdb-project))
> 
> (ede-add-project-autoload (ede-project-autoload :name "Ninja" :file 'ede/compdb :proj-file "build.ninja" :load-type 'ede-ninja-load-project :class-sym 'ede-ninja-project))
> 
> 
> I can't find any reference to the jka variable in loaddefs.

Search for that variable in all of the lisp directory and its
subdirectories.  What hits do you see?  Are any of them in cedet
directories?

Re: CEDET Merge

[Edward John Steere]

> Search for that variable in all of the lisp directory and its
> subdirectories.  What hits do you see?  Are any of them in cedet
> directories?

Nope only hits when I grep recursively from lisp/ are in:
 - jka-cmpr-hook
 - subr
 - jka-compr

Re: CEDET Merge

[Eli Zaretskii]

> From: Edward John Steere <edward.steere@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 16 Jan 2017 22:12:47 +0200
> 
> > Search for that variable in all of the lisp directory and its
> > subdirectories.  What hits do you see?  Are any of them in cedet
> > directories?
> 
> Nope only hits when I grep recursively from lisp/ are in:
>  - jka-cmpr-hook
>  - subr
>  - jka-compr

I understand that you've changed your merge strategy, so please tell
if/when this becomes relevant again.

Thanks for working on this.

Re: CEDET Merge

[Edward John Steere]

> I understand that you've changed your merge strategy, so please tell
> if/when this becomes relevant again.
>
> Thanks for working on this.

Correct.  Thanks for your input anyway.  Hopefully it wont take too long
before I have something to show for my efforts.

Re: CEDET Merge

[Stephen Leake]

Edward John Steere <edward.steere@gmail.com> writes:

>> I understand that you've changed your merge strategy, so please tell
>> if/when this becomes relevant again.
>>
>> Thanks for working on this.
>
> Correct.  Thanks for your input anyway.  Hopefully it wont take too long
> before I have something to show for my efforts.

I'd like to help with this. Perhaps doing some of the merge work, or by
running tests; let me know.

-- 
-- Stephe

Re: CEDET Merge

[Edward John Steere]

> I'd like to help with this. Perhaps doing some of the merge work, or by
> running tests; let me know.

Hi Stephe,

Great!  I could use all the help I can get :-)

Our main concern is to maintain the commit history and I think that my
original approach of merging to CEDET and then back creates too much
noise.  So I'm now considering a new approach and would value your
involvement if we can work out the details.

I think that the best way to go about this is to move everything in the
CEDET project into folders which mirror their destination in core.
Changes will be required for:
 - The grammar files, which need to be in admin/grammars
 - The tests, which need to be in test/manual/cedet
 - The documentation files, which need to move to doc/misc (and
   should probably be flattened.)

Once moved we commit, add CEDET as a remote of Emacs and merge
CEDET/master allowing unrelated histories.  We can delete any files
which fall outside of:
 - admin/grammars
 - test/manual/cedet
 - lisp/cedet
 - doc/misc

We should also delete any added Makefiles, EDE project files and bash
scripts.

This brings us to the topic of collaborating on this change.  I'm not
aware of any strategy for merging which allows for collaboration; so
I've come up with the following hack (comments/adjustments welcome):
 1. create a staging repository for CEDET and make the requisite folder
    structure changes in it
 2. create a branch in the Emacs project and merge allowing unrelated
    histories
 3. delete any files outside of our target folders and commit with
    unresolved conflicts
 4. push up the branch and divvy out files/folders for fixing conflicts
 5. commit and push as we go

If this sounds like something you'd like to be involved in then I'll
start with steps 1.->3. and follow up when I'm done.  If anyone has
a better idea then I'm listening.

(I considered moving the tests, but they have history too and we'd have
to start splitting commits to get them across w/o the rest of upstream
CEDET.  Additionally there's nothing preventing the tests from being run
with CEDET in Emacs core.  Just start it with --no-init add the test
folder to the load path, load the relevant test file and run it.)

Kind regards,

Edward Steere

Re: CEDET Merge

[Stephen Leake]

Edward John Steere <edward.steere@gmail.com> writes:

> This brings us to the topic of collaborating on this change.  I'm not
> aware of any strategy for merging which allows for collaboration; so
> I've come up with the following hack (comments/adjustments welcome):
>  1. create a staging repository for CEDET and make the requisite folder
>     structure changes in it

I guess that's on SourceForge


>  2. create a branch in the Emacs project and merge allowing unrelated
> histories 

I'm not clear what you are merging here. It should not be the whole of
CEDET; step 3 should be done first.

> 3. delete any files outside of our target folders and commit with
> unresolved conflicts 

That gives us a shared base to work on.

> 4. push up the branch and divvy out files/folders for fixing conflicts

Ok.

> 5. commit and push as we go

Ok.

> If this sounds like something you'd like to be involved in then I'll
> start with steps 1.->3. and follow up when I'm done.  

Makes sense.


-- 
-- Stephe

Re: CEDET Merge

[David Engster]

Edward John Steere writes:
> Our main concern is to maintain the commit history and I think that my
> original approach of merging to CEDET and then back creates too much
> noise.

Merging to the CEDET repo is not needed, since we will abandon it
anyway.

> I think that the best way to go about this is to move everything in the
> CEDET project into folders which mirror their destination in core.
> Changes will be required for:
>  - The grammar files, which need to be in admin/grammars
>  - The tests, which need to be in test/manual/cedet
>  - The documentation files, which need to move to doc/misc (and
>    should probably be flattened.)
>
> Once moved we commit, add CEDET as a remote of Emacs and merge
> CEDET/master allowing unrelated histories.

I think it will be less work to simply do the diff|patch game and fixing
a few paths along the way. Since the histories are unrelated, git cannot
really help you with the merges anyway.

> (I considered moving the tests, but they have history too and we'd have
> to start splitting commits to get them across w/o the rest of upstream
> CEDET.  Additionally there's nothing preventing the tests from being run
> with CEDET in Emacs core.  Just start it with --no-init add the test
> folder to the load path, load the relevant test file and run it.)

I wouldn't worry too much about the history of the tests. The authorship
of the changes should be clear, but at least I don't care much for
granularity here.

-David

Re: CEDET Merge

[Edward Steere]

Patching does sound easier.

Given that we might be moving from upstream entirely it might be worth it to keep the commit history if we can though.  I know that git won't make is easy.

If we do go with patching though, and the changes are going to appear in the changelog then how are we going to go about doing that?  Would we use the add-change-log command on all of the commits since the last merge?

One disadvantage of all of this is that git blame results would be more difficult to interpret because the change and author would be documented elsewhere.

> On 17 Jan 2017, at 11:23 PM, David Engster <david@engster.org> wrote:
> 
> Edward John Steere writes:
>> Our main concern is to maintain the commit history and I think that my
>> original approach of merging to CEDET and then back creates too much
>> noise.
> 
> Merging to the CEDET repo is not needed, since we will abandon it
> anyway.
> 
>> I think that the best way to go about this is to move everything in the
>> CEDET project into folders which mirror their destination in core.
>> Changes will be required for:
>> - The grammar files, which need to be in admin/grammars
>> - The tests, which need to be in test/manual/cedet
>> - The documentation files, which need to move to doc/misc (and
>>   should probably be flattened.)
>> 
>> Once moved we commit, add CEDET as a remote of Emacs and merge
>> CEDET/master allowing unrelated histories.
> 
> I think it will be less work to simply do the diff|patch game and fixing
> a few paths along the way. Since the histories are unrelated, git cannot
> really help you with the merges anyway.
> 
>> (I considered moving the tests, but they have history too and we'd have
>> to start splitting commits to get them across w/o the rest of upstream
>> CEDET.  Additionally there's nothing preventing the tests from being run
>> with CEDET in Emacs core.  Just start it with --no-init add the test
>> folder to the load path, load the relevant test file and run it.)
> 
> I wouldn't worry too much about the history of the tests. The authorship
> of the changes should be clear, but at least I don't care much for
> granularity here.
> 
> -David

Re: CEDET Merge

[David Engster]

Edward Steere writes:
> Given that we might be moving from upstream entirely it might be worth
> it to keep the commit history if we can though.  I know that git won't
> make is easy.

The problem with using git is that you will have to edit each commit
anyway, at least that's my experience. You usually need to fix up the
ChangeLog entries in the commit message to conform with the Emacs file
layout. Also, one needs to remove entries which touch files that are not
in Emacs, or which are from authors who haven't signed papers with the
FSF.

> If we do go with patching though, and the changes are going to appear
> in the changelog then how are we going to go about doing that?  Would
> we use the add-change-log command on all of the commits since the last
> merge?
>
> One disadvantage of all of this is that git blame results would be
> more difficult to interpret because the change and author would be
> documented elsewhere.

Things have gotten easier since the actual ChangeLog files get generated
from the commit message. I would try to manually commit the changes with
proper commit messages, so we would retain the history with the
exception of the date of the change, which would be from the day of the
merge.

-David

Re: CEDET Merge

[Edward John Steere]

> Things have gotten easier since the actual ChangeLog files get generated
> from the commit message. I would try to manually commit the changes with
> proper commit messages, so we would retain the history with the
> exception of the date of the change, which would be from the day of the
> merge.
>
> -David

This sounds like a lot of work and the outcome sounds right.

As I said in my previous email I'll make a start on the tests.

Re: CEDET Merge

[David Engster]

Edward John Steere writes:
>> Things have gotten easier since the actual ChangeLog files get generated
>> from the commit message. I would try to manually commit the changes with
>> proper commit messages, so we would retain the history with the
>> exception of the date of the change, which would be from the day of the
>> merge.
>>
>> -David
>
> This sounds like a lot of work and the outcome sounds right.

It's not that bad. 'format-patch' gives me a nice list of patches where
I can correct the paths with 'sed' and fix up the commit messages. It's
only about 100 patches, so I don't think it will take long.

> As I said in my previous email I'll make a start on the tests.

That's great, thanks! I'll push a branch with my progress soon.

-David

Re: CEDET Merge

[Karl Fogel]

David Engster <deng@randomsample.de> writes:
>Edward John Steere writes:
>>> Things have gotten easier since the actual ChangeLog files get generated
>>> from the commit message. I would try to manually commit the changes with
>>> proper commit messages, so we would retain the history with the
>>> exception of the date of the change, which would be from the day of the
>>> merge.
>>>
>>> -David
>>
>> This sounds like a lot of work and the outcome sounds right.
>
>It's not that bad. 'format-patch' gives me a nice list of patches where
>I can correct the paths with 'sed' and fix up the commit messages. It's
>only about 100 patches, so I don't think it will take long.

Regarding the earlier point about retaining history "with the exception of the date of the change":

'git commit' takes an optional '--date' option:

   --date=<date>
     Override the author date used in the commit.

So even the date of each change could be correct.

Best regards,
-Karl

Re: CEDET Merge

[David Engster]

Karl Fogel writes:
> David Engster <deng@randomsample.de> writes:
>>Edward John Steere writes:
>>>> Things have gotten easier since the actual ChangeLog files get generated
>>>> from the commit message. I would try to manually commit the changes with
>
>>>> proper commit messages, so we would retain the history with the
>>>> exception of the date of the change, which would be from the day of the
>>>> merge.
>>>>
>>>> -David
>>>
>>> This sounds like a lot of work and the outcome sounds right.
>>
>>It's not that bad. 'format-patch' gives me a nice list of patches where
>>I can correct the paths with 'sed' and fix up the commit messages. It's
>>only about 100 patches, so I don't think it will take long.
>
> Regarding the earlier point about retaining history "with the exception of the date of the change":
>
> 'git commit' takes an optional '--date' option:
>
>    --date=<date>
>      Override the author date used in the commit.
>
> So even the date of each change could be correct.

Yes, 'git am' does that automatically. However, I always followed the
general rule that the generated ChangeLogs should have the date when the
change enters the Emacs repository, so I'm not sure if I should even
retain the original date?

-David

Re: CEDET Merge

[Stefan Monnier]

> Yes, 'git am' does that automatically. However, I always followed the
> general rule that the generated ChangeLogs should have the date when the
> change enters the Emacs repository, so I'm not sure if I should even
> retain the original date?

AFAIK, Git records the "author date" separately from the "commit date",
so The Right Thing To Do is to use the fancy --date argument to provide
the "author date".  The ChangeLog can use the "commit date" if needed.


        Stefan

Re: CEDET Merge

[David Engster]

Stefan Monnier writes:
>> Yes, 'git am' does that automatically. However, I always followed the
>> general rule that the generated ChangeLogs should have the date when the
>> change enters the Emacs repository, so I'm not sure if I should even
>> retain the original date?
>
> AFAIK, Git records the "author date" separately from the "commit date",
> so The Right Thing To Do is to use the fancy --date argument to provide
> the "author date".  The ChangeLog can use the "commit date" if needed.

Yes, git tracks 'Author' and 'Committer', each with their own date. So
the ChangeLog generator script would need to use the name from 'Author'
with the date from 'Committer'. But does it actually do that? And
wouldn't it be pretty confusing to have dates in the ChangeLog that are
years apart from those in the git log?

-David

Re: CEDET Merge

[Stefan Monnier]

> Yes, git tracks 'Author' and 'Committer', each with their own date. So
> the ChangeLog generator script would need to use the name from 'Author'
> with the date from 'Committer'. But does it actually do that?

If it doesn't, we can change it, so it's not a problem.

> And wouldn't it be pretty confusing to have dates in the ChangeLog
> that are years apart from those in the git log?

That's how things are, by design (tho you can tweak your "git log" to
also output the author date, if you want), so the confusion is not due
to the "--date" argument (and can be fixed after the fact if we decide
so, whereas retroactively fixing the author-date is a lot more
difficult).


        Stefan

Re: CEDET Merge

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Cc: Edward John Steere <edward.steere@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,  Stephen Leake <stephen_leake@stephe-leake.org>,  emacs-devel@gnu.org
> Date: Fri, 20 Jan 2017 23:20:05 +0100
> 
> I always followed the general rule that the generated ChangeLogs
> should have the date when the change enters the Emacs repository

Indeed, that is our rule.

Re: CEDET Merge

[Glenn Morris]

Eli Zaretskii wrote:

>> I always followed the general rule that the generated ChangeLogs
>> should have the date when the change enters the Emacs repository
>
> Indeed, that is our rule.

That was the rule when ChangeLogs were hand-written, but since the
switch to generated ChangeLogs it does not (and cannot) apply.
Git does not record that date.

I suggest anyone working on a CEDET merge simply ignore such issues.

Ref: http://lists.gnu.org/archive/html/emacs-devel/2014-12/msg00102.html
http://lists.gnu.org/archive/html/emacs-devel/2014-12/msg00144.html

Re: CEDET Merge

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: David Engster <deng@randomsample.de>,  kfogel@red-bean.com,  edward.steere@gmail.com,  stephen_leake@stephe-leake.org,  emacs-devel@gnu.org
> Date: Sat, 21 Jan 2017 13:29:58 -0500
> 
> 
> Eli Zaretskii wrote:
> 
> >> I always followed the general rule that the generated ChangeLogs
> >> should have the date when the change enters the Emacs repository
> >
> > Indeed, that is our rule.
> 
> That was the rule when ChangeLogs were hand-written, but since the
> switch to generated ChangeLogs it does not (and cannot) apply.
> Git does not record that date.

Git obviously does record the commit date, so there's no problem with
that rule.

> I suggest anyone working on a CEDET merge simply ignore such issues.

I suggest they don't.

Re: CEDET Merge

[Glenn Morris]

Eli Zaretskii wrote:

>> >> I always followed the general rule that the generated ChangeLogs
>> >> should have the date when the change enters the Emacs repository
>> >
>> > Indeed, that is our rule.
>> 
>> That was the rule when ChangeLogs were hand-written, but since the
>> switch to generated ChangeLogs it does not (and cannot) apply.
>> Git does not record that date.
>
> Git obviously does record the commit date, so there's no problem with
> that rule.

The commit date has no relation to "the date when the change enters the
Emacs repository" (ie, was pushed to Savannah).

If you want a recent example of this, "make ChangeLog" and look at the
dates of "recent" concurrency entries. Some are years old.

Eg git log --fuller 0ccc5d8998a
Both git dates are 2012-08-15, but the correct date would be 2016-12-10:
http://lists.gnu.org/archive/html/emacs-diffs/2016-12/msg00144.html

Re: CEDET Merge

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: deng@randomsample.de,  kfogel@red-bean.com,  edward.steere@gmail.com,  stephen_leake@stephe-leake.org,  emacs-devel@gnu.org
> Date: Sat, 21 Jan 2017 13:52:55 -0500
> 
> > Git obviously does record the commit date, so there's no problem with
> > that rule.
> 
> The commit date has no relation to "the date when the change enters the
> Emacs repository" (ie, was pushed to Savannah).

It does when you commit locally before pushing.  And, as mentioned
here, there's the --date option to control that.

> If you want a recent example of this, "make ChangeLog" and look at the
> dates of "recent" concurrency entries. Some are years old.

That doesn't mean we should drop the rule, just that some people are
not always following rules.

Re: CEDET Merge

[Paul Eggert]

>> If you want a recent example of this, "make ChangeLog" and look at the
>> dates of "recent" concurrency entries. Some are years old.
> That doesn't mean we should drop the rule, just that some people are
> not always following rules.

I guess I'm not following this. For example, commit 
470e3028d8a741d97349faa8fdeb148d913a49d0 ("Fix the MS-Windows build") has a 
commit date of 2015-11-02 19:04:06 2015 +0200, and so "make ChangeLog" dates it 
2015-11-02. And yet this commit was merged into master on 2016-12-10, by you, as 
part of merge commit 2412a1fc05fe9f89b171d0781c2d530923f48adc ("Support 
concurrency in Emacs Lisp"). So when you say "some people are not always 
following rules", do you mean that you did this particular merge incorrectly? Or 
am I not understanding the rules?

Re: CEDET Merge

[Eli Zaretskii]

> Cc: Glenn Morris <rgm@gnu.org>, kfogel@red-bean.com, edward.steere@gmail.com,
>  stephen_leake@stephe-leake.org, deng@randomsample.de, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 21 Jan 2017 14:57:58 -0800
> 
> >> If you want a recent example of this, "make ChangeLog" and look at the
> >> dates of "recent" concurrency entries. Some are years old.
> > That doesn't mean we should drop the rule, just that some people are
> > not always following rules.
> 
> I guess I'm not following this. For example, commit 
> 470e3028d8a741d97349faa8fdeb148d913a49d0 ("Fix the MS-Windows build") has a 
> commit date of 2015-11-02 19:04:06 2015 +0200, and so "make ChangeLog" dates it 
> 2015-11-02. And yet this commit was merged into master on 2016-12-10, by you, as 
> part of merge commit 2412a1fc05fe9f89b171d0781c2d530923f48adc ("Support 
> concurrency in Emacs Lisp"). So when you say "some people are not always 
> following rules", do you mean that you did this particular merge incorrectly? Or 
> am I not understanding the rules?

Commit 2412a1f has its own log message (something unusual for merge
commits, AFAIK), so IMO this example exactly follows the rules as I
understand them.

Re: CEDET Merge

[David Engster]

Glenn Morris writes:
> Eli Zaretskii wrote:
>
>>> >> I always followed the general rule that the generated ChangeLogs
>>> >> should have the date when the change enters the Emacs repository
>>> >
>>> > Indeed, that is our rule.
>>> 
>>> That was the rule when ChangeLogs were hand-written, but since the
>>> switch to generated ChangeLogs it does not (and cannot) apply.
>>> Git does not record that date.
>>
>> Git obviously does record the commit date, so there's no problem with
>> that rule.
>
> The commit date has no relation to "the date when the change enters the
> Emacs repository" (ie, was pushed to Savannah).
>
> If you want a recent example of this, "make ChangeLog" and look at the
> dates of "recent" concurrency entries. Some are years old.
>
> Eg git log --fuller 0ccc5d8998a
> Both git dates are 2012-08-15, but the correct date would be 2016-12-10:
> http://lists.gnu.org/archive/html/emacs-diffs/2016-12/msg00144.html

Yes, that's a problem with long-living feature branches. It'd be nice if
'make ChangeLog' would use the commit date of the merge commit for all
commits that entered Emacs through a branch merge.

If that isn't easily possible, the person who does the merge could do a
filter-branch before merging, setting GIT_COMMITTER_DATE to the current
date (if 'make ChangeLog' would actually use the committer date, which
AFAICS it currently does not).

-David

Re: CEDET Merge

[Paul Eggert]

David Engster wrote:
> Yes, that's a problem with long-living feature branches. It'd be nice if
> 'make ChangeLog' would use the commit date of the merge commit for all
> commits that entered Emacs through a branch merge.

As I understand it, that's not easy since git does not prefer one branch to the 
other in a merge, so any scheme we come up with will be as likely to redate 
commits already in the master as to redate commits entering through the merge.

> If that isn't easily possible, the person who does the merge could do a
> filter-branch before merging, setting GIT_COMMITTER_DATE to the current
> date

Something like that should work. We aren't doing that now, which causes problems 
like the confusion noted.

>(if 'make ChangeLog' would actually use the committer date, which
> AFAICS it currently does not).

gitlog-to-changelog uses %ct, not %at, for its 'git log' format, so 'make 
ChangeLog' should already be using committer date.

Re: CEDET Merge

[David Engster]

David Engster writes:
> Edward John Steere writes:
>> As I said in my previous email I'll make a start on the tests.
>
> That's great, thanks! I'll push a branch with my progress soon.

I just pushed my first try as scratch/last-cedet-merge.

-David

Re: CEDET Merge

[Edward John Steere]

> I just pushed my first try as scratch/last-cedet-merge.
>
> -David

Just pinging back here.  Making progress.  Will have a first attempt at
the tests up tomorrow night.  Had some other stuff keeping me away from
my PC at home lately.

Re: CEDET Merge

[Edward John Steere]

> Just pinging back here.  Making progress.  Will have a first attempt at
> the tests up tomorrow night.  Had some other stuff keeping me away from
> my PC at home lately.

Having some difficulty pushing up my branch.  This is my first time
pushing up a branch on emacs.git.  My understanding is that team
membership is sufficient for access rights.

I'm getting a "connection reset by peer" error every time I try to push
as follows:

$ git push origin scratch/merge-cedet-tests
Counting objects: 2548, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2336/2336), done.
fatal: sha1 file '<stdout>' write error: Connection reset by peer
fatal: The remote end hung up unexpectedly
error: failed to push some refs to 'git://git.savannah.gnu.org/emacs.git'

After reading a blog post I thought that it might have something to do
with the push being too large so I added the following to ~/.ssh/config
in the hopes that regular null packets would keep the connection alive.

Host git.savannah.gnu.org
  ServerAliveInterval 5

No luck though; so I tried pushing up only three commits and that failed
with the same message as well.

Re: CEDET Merge

[David Engster]

Edward John Steere writes:
>> Just pinging back here.  Making progress.  Will have a first attempt at
>> the tests up tomorrow night.  Had some other stuff keeping me away from
>> my PC at home lately.
>
> Having some difficulty pushing up my branch.  This is my first time
> pushing up a branch on emacs.git.  My understanding is that team
> membership is sufficient for access rights.
>
> I'm getting a "connection reset by peer" error every time I try to push
> as follows:
>
> $ git push origin scratch/merge-cedet-tests
> Counting objects: 2548, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (2336/2336), done.
> fatal: sha1 file '<stdout>' write error: Connection reset by peer
> fatal: The remote end hung up unexpectedly
> error: failed to push some refs to 'git://git.savannah.gnu.org/emacs.git'

You are trying to push with the git protocol, not with ssh. You need to
use <membername>@git.sv.gnu.org:/srv/git/emacs.git. See also

  http://savannah.gnu.org/git/?group=emacs
  https://www.emacswiki.org/emacs/GitQuickStartForEmacsDevs

-David

Re: CEDET Merge

[Edward Steere]

> On 26 Jan 2017, at 11:06 PM, David Engster <deng@randomsample.de> wrote:
> 
> Edward John Steere writes:
>>> Just pinging back here.  Making progress.  Will have a first attempt at
>>> the tests up tomorrow night.  Had some other stuff keeping me away from
>>> my PC at home lately.
>> 
>> Having some difficulty pushing up my branch.  This is my first time
>> pushing up a branch on emacs.git.  My understanding is that team
>> membership is sufficient for access rights.
>> 
>> I'm getting a "connection reset by peer" error every time I try to push
>> as follows:
>> 
>> $ git push origin scratch/merge-cedet-tests
>> Counting objects: 2548, done.
>> Delta compression using up to 8 threads.
>> Compressing objects: 100% (2336/2336), done.
>> fatal: sha1 file '<stdout>' write error: Connection reset by peer
>> fatal: The remote end hung up unexpectedly
>> error: failed to push some refs to 'git://git.savannah.gnu.org/emacs.git'
> 
> You are trying to push with the git protocol, not with ssh. You need to
> use <membername>@git.sv.gnu.org:/srv/git/emacs.git. See also
> 
>  http://savannah.gnu.org/git/?group=emacs
>  https://www.emacswiki.org/emacs/GitQuickStartForEmacsDevs
> 
> -David

Thanks David.  I'll try again tonight.

Re: CEDET Merge

[Edward John Steere]

David Engster <deng@randomsample.de> writes:
>> Edward John Steere writes:
>>> As I said in my previous email I'll make a start on the tests.
>>
>> That's great, thanks! I'll push a branch with my progress soon.
>
> I just pushed my first try as scratch/last-cedet-merge.
>
> -David

I've just pushed up a fairly rough attempt at merging the tests in
scratch/merge-cedet-tests (it looks like tests were only ever merged to
Emacs once.)  I took the following approach:

 * I used git to format patches per test file.
 * changed the destination of the file in each patch to match the Emacs
   manual testing directory;
 * fixed any commit messages which failed the commit hook;
 * added a final commit to cleanup; which included the removal of
   duplicated test files not moved by the patching process and the
   removal of dependencies on language/project support which we're not
   merging

The consequence of this approach is that my branch will add 316 commits.
Many of the commit messages aren't up to scratch (they pass the commit
hook but don't match the requirements outlined in CONTRIBUTE).  I'm
going to have to spend some time fixing the rest of the commits.  I
wanted to ask whether we should consider squashing all 316 commits into
a "cedet-merge" commit since the changes are going to be documented in
the ChangeLog.

Finally; the tests don't run with the CEDET in Emacs.  The first failure
is caused by a missing SRecode template -- which I imagine David will
have added on his branch.  I haven't checked what happens when his and
my changes are merged.

Re: CEDET Merge

[David Engster]

Edward John Steere writes:
> David Engster <deng@randomsample.de> writes:
>>> Edward John Steere writes:
>>>> As I said in my previous email I'll make a start on the tests.
>>>
>>> That's great, thanks! I'll push a branch with my progress soon.
>>
>> I just pushed my first try as scratch/last-cedet-merge.
>>
>> -David
>
> I've just pushed up a fairly rough attempt at merging the tests in
> scratch/merge-cedet-tests

Thank you.

> (it looks like tests were only ever merged to Emacs once.)

Yes.

> I took the following approach:
>
>  * I used git to format patches per test file.
>  * changed the destination of the file in each patch to match the Emacs
>    manual testing directory;
>  * fixed any commit messages which failed the commit hook;
>  * added a final commit to cleanup; which included the removal of
>    duplicated test files not moved by the patching process and the
>    removal of dependencies on language/project support which we're not
>    merging
>
> The consequence of this approach is that my branch will add 316 commits.
> Many of the commit messages aren't up to scratch (they pass the commit
> hook but don't match the requirements outlined in CONTRIBUTE).  I'm
> going to have to spend some time fixing the rest of the commits.  I
> wanted to ask whether we should consider squashing all 316 commits into
> a "cedet-merge" commit since the changes are going to be documented in
> the ChangeLog.

There seems to be a misunderstanding here: The ChangeLog is generated
from the commit log and not written separately anymore.

I don't think it makes sense to fix up all the commits messages. The
commits you've merged go back to the beginning of CEDET, and I don't
think there's any sense it writing proper ChangeLogs for them now. They
are only tests, after all. However, it is very good that we have the
history on your branch, because it makes it much easier to check if all
authors have signed papers (last I asked, authors of non-trivial tests
were also required to have papers signed with the FSF).

In my opinion, once we have decided which tests to keep and fixed them,
we should squash them and commit it as a new test suite.

> Finally; the tests don't run with the CEDET in Emacs.

That's totally expected. I'll take a look at them.

-David

Re: CEDET Merge

[Edward John Steere]

> There seems to be a misunderstanding here: The ChangeLog is generated
> from the commit log and not written separately anymore.

Alright.  Out of interest: is there a command for generating all of the
entries for a commit range?  I'm only aware of C-x 4 a
(add-change-log-entry-other-window) which seems to generate a change log
entry for the current file and only for the latest commit.

> I don't think it makes sense to fix up all the commits messages. The
> commits you've merged go back to the beginning of CEDET, and I don't
> think there's any sense it writing proper ChangeLogs for them now. They
> are only tests, after all. However, it is very good that we have the
> history on your branch, because it makes it much easier to check if all
> authors have signed papers (last I asked, authors of non-trivial tests
> were also required to have papers signed with the FSF).
>
> In my opinion, once we have decided which tests to keep and fixed them,
> we should squash them and commit it as a new test suite.

Agreed.

>> Finally; the tests don't run with the CEDET in Emacs.
>
> That's totally expected. I'll take a look at them.
>
> -David

I've just made some fixes to the tests this morning (I had messed up the
merge of ia-utest.el and missed the whole of the cpproot directory for
utests.)  With that change the tests run with my current Emacs (which
runs the modified CEDET that I created by merging Emacs-CEDET -> CEDET.)

To anyone who has pulled my branch, scratch/merge-cedet-tests, I'd just
ask that you git pull -f because I rewrote that branches history to
correct my mistake.

Re: CEDET Merge

[David Engster]

Edward John Steere writes:
>> There seems to be a misunderstanding here: The ChangeLog is generated
>> from the commit log and not written separately anymore.
>
> Alright.  Out of interest: is there a command for generating all of the
> entries for a commit range?  I'm only aware of C-x 4 a
> (add-change-log-entry-other-window) which seems to generate a change log
> entry for the current file and only for the latest commit.

You can use 'C-x 4 A' in a diff buffer. I usually do this:

. Do 'M-x vc-dir' and choose repository

. Hit 'D' to create a diff for the directory you want to create a
  ChangeLog for

. Hit 'C-X 4 A'


-David

Re: CEDET Merge

[Lars Ingebrigtsen]

David Engster <deng@randomsample.de> writes:

>> Alright.  Out of interest: is there a command for generating all of the
>> entries for a commit range?  I'm only aware of C-x 4 a
>> (add-change-log-entry-other-window) which seems to generate a change log
>> entry for the current file and only for the latest commit.
>
> You can use 'C-x 4 A' in a diff buffer. I usually do this:
>
> . Do 'M-x vc-dir' and choose repository
>
> . Hit 'D' to create a diff for the directory you want to create a
>   ChangeLog for
>
> . Hit 'C-X 4 A'

Oh, nice!  Thanks.  Didn't know about that one...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: CEDET Merge

[Ted Zlatanov]

On Tue, 31 Jan 2017 17:51:42 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> David Engster <deng@randomsample.de> writes:
>>> Alright.  Out of interest: is there a command for generating all of the
>>> entries for a commit range?  I'm only aware of C-x 4 a
>>> (add-change-log-entry-other-window) which seems to generate a change log
>>> entry for the current file and only for the latest commit.
>> 
>> You can use 'C-x 4 A' in a diff buffer. I usually do this:
>> 
>> . Do 'M-x vc-dir' and choose repository
>> 
>> . Hit 'D' to create a diff for the directory you want to create a
>> ChangeLog for
>> 
>> . Hit 'C-X 4 A'

LI> Oh, nice!  Thanks.  Didn't know about that one...

THANK YOU

David, can you add that method to emacs.git/CONTRIBUTE? Right now it
only has the `add-change-log-entry-other-window' way. Or I can do it if
you prefer...

Ted

Re: CEDET Merge

[Edward John Steere]

> That's totally expected. I'll take a look at them.
>
> -David

I've just pushed another update to my branch which fixes another mistake
in ia-utest, adds an include for the unit test root file and adds test
resource files which I missed the first time round.  I've created a
local branch where I merged my branch to yours to see how we're doing.
Here's what I've found after running both the unit and integration
tests:

* Utests in Error

** EDE Security
(error "Corrupt object on disk")

This is an error caused by the changes to how EIEIO objects auto load.
They no longer include their parents as part of the auto load so all
classes and class parents which are read from file must have their
definitions loaded prior to de-serialising (this includes the entire
inheritance hierarchy for the target class).

I added the following requires to the body of `ede-proj-load' to rectify
this (it's a total hack though):

(require 'ede/proj-prog)
(require 'ede/proj-aux)
(require 'ede/proj-elisp)
(require 'ede/proj-scheme)
(require 'ede/proj-misc)
(require 'ede/proj-prog)
(require 'ede/proj-archive)
(require 'ede/proj-shared)
(require 'ede/proj-info)
(require 'semantic/ede-grammar)

Note that I haven't added this change here.

** Project Detection Tests
I think that this also has to do with the changes to how classes are
auto loaded, but I'm not sure.

Running ede: project detection tests ...
ERROR: (wrong-type-argument (or eieio-object class) nil obj)
Running ede: project detect linux extra ...
ERROR: (wrong-type-argument (or eieio-object class) nil obj)

** Test FMT
(error "Cannot open tests/test-fmt.el for format tests")

I debugged this one and it looks like it can't open test-fmt.el because
semantic mode isn't active in Emacs lisp.

** Wisent Calculator
Running wisent calculator ...
ERROR: (void-function wisent-calc-utest)

This function doesn't seem to exist in either repo (?)

** Waiting for Key Press
Running working: wait-for-keypress ...
ERROR: (void-function working-wait-for-keypress)

This function doesn't seem to be in your branch.

** Interactive Test
(error "Invalid face" modeline)

I'm not sure where this face is defined, but it is indeed undefined
during the test.

** C Parser Tests
ERROR: (error "TAG INTERNAL DIFF: :prototype-flag :enum-type")
Running semantic: C parser (ERT) ... 
ERROR: (ert-test-failed ((should (test-c-check-tags-length actual 1)) :form (test-c-check-tags-length nil 1) :value nil :explanation "Wrong number of tags. Expected: 1, actual: 0."))
Running semantic: C preprocessor ... 
ERROR: (error #("Found: >> int EDEPART (int b) << Expected: >>  int C (int b) <<" 10 13 (face font-lock-type-face) 14 21 (face font-lock-function-name-face) 23 26 (face font-lock-type-face) 27 28 (face font-lock-variable-name-face) 47 50 (face font-lock-type-face) 51 52 (face font-lock-function-name-face) 54 57 (face font-lock-type-face) 58 59 (face font-lock-variable-name-face)))

Are the new grammar files being compiled included correctly?

** Analyser Tests
ERROR: (invalid-slot-name "#<semantic-scope-cache semantic-scope-cache>" :name)

Haven't looked any further into this failure.

** SRecode Tests
ERROR: (error "Entry #<srecode-utest-output srecode-utest-output> failed; expected: --[;; An includable  we could use.
Running srecode: fields ... 
ERROR: (error "Calculated size of #<srecode-field srecode-field> was not 5")
Running srecode: project ... 
ERROR: (error "Project template not found when in project")

Haven't looked into this one either.

* Itests
Break at first tag comparison (so they should get further when the
Utests are fixed.)

Re: CEDET Merge

[David Engster]

Stephen Leake writes:
> Edward John Steere <edward.steere@gmail.com> writes:
>
>>> I understand that you've changed your merge strategy, so please tell
>>> if/when this becomes relevant again.
>>>
>>> Thanks for working on this.
>>
>> Correct.  Thanks for your input anyway.  Hopefully it wont take too long
>> before I have something to show for my efforts.
>
> I'd like to help with this. Perhaps doing some of the merge work, or by
> running tests; let me know.

Actually, there's one thing which really didn't get much attention
during all those years: the texi files. I'm not sure how much those
diverged between Emacs and CEDET upstream. It was always messy, since in
the initial merge not all docs were imported from upstream. So if you'd
like to take a look at the texi files, that'd be much appreciated.

-David

Re: CEDET Merge

[Stephen Leake]

David Engster <david@engster.org> writes:

> Stephen Leake writes:
>> Edward John Steere <edward.steere@gmail.com> writes:
>>
>>>> I understand that you've changed your merge strategy, so please tell
>>>> if/when this becomes relevant again.
>>>>
>>>> Thanks for working on this.
>>>
>>> Correct.  Thanks for your input anyway.  Hopefully it wont take too long
>>> before I have something to show for my efforts.
>>
>> I'd like to help with this. Perhaps doing some of the merge work, or by
>> running tests; let me know.
>
> Actually, there's one thing which really didn't get much attention
> during all those years: the texi files. I'm not sure how much those
> diverged between Emacs and CEDET upstream. It was always messy, since in
> the initial merge not all docs were imported from upstream. So if you'd
> like to take a look at the texi files, that'd be much appreciated.

Ok, I'll look at the texi files currently in SourceForge and Emacs
CEDET, and make recommendations.

-- 
-- Stephe

Re: CEDET Merge

[David Engster]

Edward John Steere writes:
> Here are the offenders for the first error (they come from a new module
> in Cedet called cogre):

No, please do not merge Cogre. It is not a new module, was never part of
Emacs and is not really actively developed anymore.

-David

Re: CEDET Merge

[Edward John Steere]

> No, please do not merge Cogre. It is not a new module, was never part of
> Emacs and is not really actively developed anymore.
>
> -David

Sure.

The plan is to start by getting the whole of Cedet compiling and
starting up in core and then taking a more deliberate approach to what
stays and goes.  I'm taking this approach because the alternatives
require a bit more historic knowledge of Cedet than I have.

Are you aware of a better approach?

Re: CEDET Merge

[David Engster]

Edward John Steere writes:
>> No, please do not merge Cogre. It is not a new module, was never part of
>> Emacs and is not really actively developed anymore.
>>
>> -David
>
> Sure.
>
> The plan is to start by getting the whole of Cedet compiling and
> starting up in core and then taking a more deliberate approach to what
> stays and goes.  I'm taking this approach because the alternatives
> require a bit more historic knowledge of Cedet than I have.
>
> Are you aware of a better approach?

The problem with this approach is that you loose lots of history for the
changes that are applied. In Emacs this is especially problematic
because of the copyright issues. So one will need at least a proper
ChangeLog, saying which authors changed which functions, but the Emacs
maintainers will have to say if that would suffice of if we need
authorship information for each line that is applied.

So the "Right Way" would be to apply the upstream commits that happened
since the last CEDET merge to the Emacs repo. I had a package for doing
that, but it was based on Bazaar, so that went they way of the
Dodo. It's called cedet-emacs-merge.el and is in the CEDET repo. I don't
think it makes sense to port it to git, because we actually agreed some
time ago to drop the CEDET repo altogether, so we would "only" need one
final one-way merge. It's been on my TODO list for ages, and I'm really
sorry that it still has not happened yet.

In my opinion, the first thing that should be done is to port the test
suite to Emacs, meaning the unit and integration tests for Semantic and
EDE, ripping out all tests for stuff that is not in Emacs. I already did
that for EIEIO, but for Semantic and EDE a lot is missing. It will make
it much easier to find regressions while doing the merge.

-David

Re: CEDET Merge

[Edward Steere]

Sent from my iPhone
> On 16 Jan 2017, at 11:13 PM, David Engster <deng@randomsample.de> wrote:
> 
> Edward John Steere writes:
>>> No, please do not merge Cogre. It is not a new module, was never part of
>>> Emacs and is not really actively developed anymore.
>>> 
>>> -David
>> 
>> Sure.
>> 
>> The plan is to start by getting the whole of Cedet compiling and
>> starting up in core and then taking a more deliberate approach to what
>> stays and goes.  I'm taking this approach because the alternatives
>> require a bit more historic knowledge of Cedet than I have.
>> 
>> Are you aware of a better approach?
> 
> The problem with this approach is that you loose lots of history for the
> changes that are applied. In Emacs this is especially problematic
> because of the copyright issues. So one will need at least a proper
> ChangeLog, saying which authors changed which functions, but the Emacs
> maintainers will have to say if that would suffice of if we need
> authorship information for each line that is applied.
> 
> So the "Right Way" would be to apply the upstream commits that happened
> since the last CEDET merge to the Emacs repo. I had a package for doing
> that, but it was based on Bazaar, so that went they way of the
> Dodo. It's called cedet-emacs-merge.el and is in the CEDET repo. I don't
> think it makes sense to port it to git, because we actually agreed some
> time ago to drop the CEDET repo altogether, so we would "only" need one
> final one-way merge. It's been on my TODO list for ages, and I'm really
> sorry that it still has not happened yet.
> 
> In my opinion, the first thing that should be done is to port the test
> suite to Emacs, meaning the unit and integration tests for Semantic and
> EDE, ripping out all tests for stuff that is not in Emacs. I already did
> that for EIEIO, but for Semantic and EDE a lot is missing. It will make
> it much easier to find regressions while doing the merge.
> 
> -David

Alright.  It shouldn't be too difficult to merge with the commit history intact and I agree wrt the tests so I'll make a start of porting those tonight.

Wrt the files which are in upstream but not in core do you have any experience with what ought to be merged?  There are newly supported project types and databases which look like they should probably be merged, but there are still more sources.  If not all of it is appropriate for the merge then perhaps we could look at moving future development to one or many ELPA packages.

(Apologies for the formatting, I'm writing this on my phone)

Re: CEDET Merge

[David Engster]

Edward Steere writes:
> Alright.  It shouldn't be too difficult to merge with the commit
> history intact and I agree wrt the tests so I'll make a start of
> porting those tonight.

That's great, thanks. You will need to remove quite some stuff from
there that is not in Emacs, like everything Java related, the Fortran
tests, ede/arduino, cogre...

I did take a look, and the last proper merge was done on Nov 10, 2014. I
think that was right before we switched to git. I also see now that I
did the merges differently than I remembered: I had an 'emacs' branch in
the CEDET repository which mimicked the file system layout from Emacs,
and merged the new CEDET commits there. Then I made one final diff and
committed that to Emacs. So in the end, the Emacs->CEDET merged were
commit-based, but CEDET->Emacs merges were done as one commit, and I
dimly remember that Stefan was OK with that as long as we provided
proper ChangeLogs. So I think it would be OK to do it this way again.

> Wrt the files which are in upstream but not in core do you have any
> experience with what ought to be merged?

Looking at the changes since Nov 10, 2014, there's the new ede/compdb
package. Otherwise, most of the changes are for Semantic and EDE, and
they are mostly by Eric and me, and it is not as much as I feared.

> There are newly supported project types and databases which look like
> they should probably be merged, but there are still more sources.  If
> not all of it is appropriate for the merge then perhaps we could look
> at moving future development to one or many ELPA packages.

For now, new files should be ignored if possible, let's merge the core
files first. Then anybody can look at what else is still upstream and
create ELPA packages for it.

If you work on the test suite, I will try to merge the commits since Nov
2014.

-David

Re: CEDET Merge

[Dmitry Gutov]

On 18.01.2017 00:06, David Engster wrote:

> That's great, thanks. You will need to remove quite some stuff from
> there that is not in Emacs, like everything Java related, the Fortran
> tests, ede/arduino, cogre...

Is that a good idea? If CEDET development is going to proceed inside 
Emacs from now on, why would you remove Java support?

Is it in a really bad shape?

Re: CEDET Merge

[David Engster]

Dmitry Gutov writes:
> On 18.01.2017 00:06, David Engster wrote:
>
>> That's great, thanks. You will need to remove quite some stuff from
>> there that is not in Emacs, like everything Java related, the Fortran
>> tests, ede/arduino, cogre...
>
> Is that a good idea? If CEDET development is going to proceed inside
> Emacs from now on, why would you remove Java support?

CEDET's Java support was never in Emacs, and the CEDET repository will
not vanish, so we're not really removing anything. Anybody can port the
Java support to Emacs or ELPA later.

> Is it in a really bad shape?

To my knowledge, nobody has been working on it for quite some time, so
I'd be surprised if it worked with today's typical Java code.

-David

Re: CEDET Merge

[Lee Hinman]

David Engster <david@engster.org> writes:

> Dmitry Gutov writes:
>> On 18.01.2017 00:06, David Engster wrote:
>>
>>> That's great, thanks. You will need to remove quite some stuff from
>>> there that is not in Emacs, like everything Java related, the Fortran
>>> tests, ede/arduino, cogre...
>>
>> Is that a good idea? If CEDET development is going to proceed inside
>> Emacs from now on, why would you remove Java support?
>
> CEDET's Java support was never in Emacs, and the CEDET repository will
> not vanish, so we're not really removing anything. Anybody can port the
> Java support to Emacs or ELPA later.
>
>> Is it in a really bad shape?
>
> To my knowledge, nobody has been working on it for quite some time, so
> I'd be surprised if it worked with today's typical Java code.

CEDET's Java support works pretty well actually. I use it every day for
my day job. It'd be great if it could be included (eventually if not
part of this) in Emacs-proper.

Of course it could be improved since it's a little out of date, but
it remains useful.

Re: CEDET Merge

[Edward John Steere]

> CEDET's Java support works pretty well actually. I use it every day for
> my day job. It'd be great if it could be included (eventually if not
> part of this) in Emacs-proper.
>
> Of course it could be improved since it's a little out of date, but
> it remains useful.

I can report the same thing: CEDET's Java support although dated in some
places is very good.  I've submitted patches which prevent the parser
from bombing out on diamond syntax and annotations as well as fixing
starry imports, but there are other areas where it's lacking,
e.g. support for static imports.

If we were to bring it up to standard and fix some debilitating
performance issues which crop up on larger projects then it would
compete with many of the projects which try to bring semantic Java
editing to Emacs with server programs.  (You can also work around the
performance problems with some hacks which limit search scope
aggressively but that's obviously not ideal.)

I don't understand what's preventing us from porting this and other
aspects of CEDET right away -- other than scope creep perhaps?  I would
advise against using upstream as a fallback though because:
 a) it's likely to receive even less attention after the merge;
 b) most of it doesn't work with the latest Emacs because of the changes
    to EIEIO in core;

Re: CEDET Merge

[Stephen Leake]

Edward John Steere <edward.steere@gmail.com> writes:

> I don't understand what's preventing us from porting this and other
> aspects of CEDET right away -- other than scope creep perhaps?  

Yes; let's get the current core CEDET merged first.

It would be best if the other useful parts of CEDET were made into ELPA
packages. 


-- 
-- Stephe

Re: CEDET Merge

[David Engster]

Edward John Steere writes:
> I don't understand what's preventing us from porting this and other
> aspects of CEDET right away -- other than scope creep perhaps?  I would
> advise against using upstream as a fallback though because:
>  a) it's likely to receive even less attention after the merge;
>  b) most of it doesn't work with the latest Emacs because of the changes
>     to EIEIO in core;

I'm happy to hear that Java support works for people. Last time I tried
it didn't even parse generics, but I don't code much in Java anymore so
I haven't tried recently.

My worry is indeed feature creep. The CEDET merge fell behind because I
couldn't keep up with the changes in Emacs, most notably the switch to
git and the extensive changes in EIEIO. The code base is very large and
complicated, so I'm against adding more code to Emacs core. Instead, we
should try to make it more modular and put support for certain languages
and project types into separate ELPA projects. This would also make it
easier to share maintainership of CEDET.

-David

Re: CEDET Merge

[Edward John Steere]

> My worry is indeed feature creep. The CEDET merge fell behind because I
> couldn't keep up with the changes in Emacs, most notably the switch to
> git and the extensive changes in EIEIO. The code base is very large and
> complicated, so I'm against adding more code to Emacs core.

Alright.  I'll get to work on porting the tests again and limit the
tests which I merge to those which will be relevant to the components
which will end up in core.

> Instead, we
> should try to make it more modular and put support for certain languages
> and project types into separate ELPA projects. This would also make it
> easier to share maintainership of CEDET.
>
> -David

I couldn't agree more on this point.  I also think that many users are
itching to improve the aspects of CEDET which they use and that a move
like this would make strides in making the project accessible to those
kinds of contributions.  Let's get this merge done so that we can get
cracking on the ELPA projects too! :-)

Re: CEDET Merge

[Lee Hinman]

Edward John Steere <edward.steere@gmail.com> writes:

>> Instead, we should try to make it more modular and put support for
>> certain languages and project types into separate ELPA projects. This
>> would also make it easier to share maintainership of CEDET.
>>
>> -David
>
> I couldn't agree more on this point.  I also think that many users are
> itching to improve the aspects of CEDET which they use and that a move
> like this would make strides in making the project accessible to those
> kinds of contributions.  Let's get this merge done so that we can get
> cracking on the ELPA projects too! :-)

I just sent off my contribution email to the FSF specifically so I could
help with this, so hopefully it moves forward!

Re: CEDET Merge

[John Wiegley]

>>>>> "LH" == Lee Hinman <lee@writequit.org> writes:

>> I couldn't agree more on this point. I also think that many users are
>> itching to improve the aspects of CEDET which they use and that a move like
>> this would make strides in making the project accessible to those kinds of
>> contributions. Let's get this merge done so that we can get cracking on the
>> ELPA projects too! :-)

LH> I just sent off my contribution email to the FSF specifically so I could
LH> help with this, so hopefully it moves forward!

Let's start this month, I can make time for it.

As a first step: What information is needed about CEDET, to correctly inject
it into the distribution tarball? I'm betting it's slightly more than just a
list of files mapped to tarball locations.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: CEDET Merge

[Eric Ludlam]

On 01/18/2017 04:57 PM, David Engster wrote:
> My worry is indeed feature creep. The CEDET merge fell behind because I
> couldn't keep up with the changes in Emacs, most notably the switch to
> git and the extensive changes in EIEIO. The code base is very large and
> complicated, so I'm against adding more code to Emacs core. Instead, we
> should try to make it more modular and put support for certain languages
> and project types into separate ELPA projects. This would also make it
> easier to share maintainership of CEDET.

I agree with David.  Making it easy to create and maintain different 
extensions independent of CEDET core will be a big win.

Eric

Re: CEDET Merge

[Charles A. Roelli]

> From: Edward John Steere <edward.steere@gmail.com>
> Date: Thu, 12 Jan 2017 21:32:36 +0200
> 
> Hello Everyone,
> 
> I've been working on a branch in upstream CEDET which brings it up to
> date with the changes which have been made in Emacs core.  I started
> this work with the intention of simplifying the merge process from CEDET
> upstream into core so that users can benefit from improvements to CEDET
> more easily.  I found that the divergence between the two versions of
> CEDET has grown quite a bit and all of my work has been dedicated to
> getting it to run on Emacs master (26?).
> 
> My branch now passes all of CEDETs tests when built against Emacs
> @512e988.  I'd like to get these changes synchronised with Emacs core
> and have my branch merged to upstream (i.e. CEDET on source forge).
> 
> This could be the first step with the second being a repackaging of
> upstream so that it only contains the parts which are under active
> development and can be installed via ELPA.
> 
> May I contribute my changes to a branch on the Savannah repository for
> review/commentary?  (If yes, then It'll take a little bit of time to
> merge the changes in my branch of CEDET back into Emacs core before I
> actually push them up.)
> 
> Kind regards,
> 
> Edward Steere

Does anyone know if the changes were brought into Emacs?  It looks
like the merge branch got reasonably far:

http://git.savannah.gnu.org/cgit/emacs.git/log/?h=scratch/last-cedet-merge

Re: CEDET Merge

[Edward John Steere]

>> From: Edward John Steere <edward.steere@gmail.com>
>> Date: Thu, 12 Jan 2017 21:32:36 +0200
>> 
>> Hello Everyone,
>> 
>> I've been working on a branch in upstream CEDET which brings it up to
>> date with the changes which have been made in Emacs core.  I started
>> this work with the intention of simplifying the merge process from CEDET
>> upstream into core so that users can benefit from improvements to CEDET
>> more easily.  I found that the divergence between the two versions of
>> CEDET has grown quite a bit and all of my work has been dedicated to
>> getting it to run on Emacs master (26?).
>> 
>> My branch now passes all of CEDETs tests when built against Emacs
>> @512e988.  I'd like to get these changes synchronised with Emacs core
>> and have my branch merged to upstream (i.e. CEDET on source forge).
>> 
>> This could be the first step with the second being a repackaging of
>> upstream so that it only contains the parts which are under active
>> development and can be installed via ELPA.
>> 
>> May I contribute my changes to a branch on the Savannah repository for
>> review/commentary?  (If yes, then It'll take a little bit of time to
>> merge the changes in my branch of CEDET back into Emacs core before I
>> actually push them up.)
>> 
>> Kind regards,
>> 
>> Edward Steere
>
> Does anyone know if the changes were brought into Emacs?  It looks
> like the merge branch got reasonably far:
>
> http://git.savannah.gnu.org/cgit/emacs.git/log/?h=scratch/last-cedet-merge

Hi Charles,

To my knowledge these changes never made it into Emacs.  In fact, a few
things changed since my first email:
 - David Engster got involved (he's been responsible for merges in the
   past if I remember correctly).
 - I was informed that my branch included elements of CEDET which were
   not intended to reach core (COGRE being a good example).
 - We divided up the work of merging tests and merging CEDET and since
   David had experience with this work he went ahead with the core
   elements.

At the same time as we were working on the merge we also started
discussing the possibility of changing the way that CEDET is
distributed.  In particular, we discussed the use of ELPA as a
distribution channel.  I originally argued in favour of this move
because I think that it's widely regarded that upstream CEDET is
difficult to install and setup with Emacs.  I also believe that these
difficulties in installing and setting it up have hampered it's adoption
and development (although this is mostly a suspicion based on various
blog posts which I've read about CEDET and my own experience in getting
started with, and then using it).

There were objections to making CEDET a package.  These related to the
difficulties which the maintainers have experienced in the past with
regards to supporting multiple versions of Emacs.  After some discussion
I deferred to their wisdom.  I agreed to assist with bringing the parts
of CEDET which are currently in Emacs core up to date and with the idea
that remaining pieces should probably live on in ELPA as packages.
However, the discussion continued.  There was renewed talk of developing
CEDET (as well as other larger packages which are distributed with
Emacs) separately to Emacs and that these packages should be brought in
as part of the tarball preparation step during releases (and for what
it's worth I think that this would be a better situation if we could
work through the problems raised.)

I believe that where these developments ended was with David's objection
to eventually pulling CEDET out of core (to be developed in the
aforementioned way) because of the problems which he raised in
developing it separately to Emacs core.

The problem which I face, without the help of those more experienced
than I, is that I don't have enough context on how to resolve some of
the problems which arise as part of doing a partial merge of CEDET into
core.  I'm not an expert wrt to the CEDET project -- I'm a user and an
occasional hacker who has an understanding of the project and wants to
give back, help it grow and enjoy the benefits of this growth and
improvement to Emacs.

I would be happy to discuss possibilities for continuing this
development.

I think that CEDET has more potential than that which has been exploited
thus far.  I know that there are performance problems when working with
larger projects and I know that these aren't intractable, they would
require that we continue to develop it, reconsider some of the
mechanisms by which it operates and make better use of the tools
available to us in Emacs.

Kind regards,

Edward Steere

Re: CEDET Merge

[Charles A. Roelli]

Thanks for your detailed response.

> The problem which I face, without the help of those more experienced
> than I, is that I don't have enough context on how to resolve some of
> the problems which arise as part of doing a partial merge of CEDET into
> core.  I'm not an expert wrt to the CEDET project -- I'm a user and an
> occasional hacker who has an understanding of the project and wants to
> give back, help it grow and enjoy the benefits of this growth and
> improvement to Emacs.

Can you say which parts of the merge caused difficulty?  I'd like to
help move the process along, if it's possible (though I'm also not a
frequent Elisp hacker).

Also, do you know which parts of CEDET were going to be offered as
ELPA packages?  You mentioned COGRE already -- were there any others?

Re: CEDET Merge

[Edward John Steere]

> Thanks for your detailed response.
>
>> The problem which I face, without the help of those more experienced
>> than I, is that I don't have enough context on how to resolve some of
>> the problems which arise as part of doing a partial merge of CEDET into
>> core.  I'm not an expert wrt to the CEDET project -- I'm a user and an
>> occasional hacker who has an understanding of the project and wants to
>> give back, help it grow and enjoy the benefits of this growth and
>> improvement to Emacs.
>
> Can you say which parts of the merge caused difficulty?  I'd like to
> help move the process along, if it's possible (though I'm also not a
> frequent Elisp hacker).

That's great.  I'd be interested in collaborating with you.

I think that the biggest problem which I faced was in untangling the
dependencies which had been created between code in files which exist in
both core and upstream and some of the newer files which only exist in
upstream.  Some of these dependencies don't seem to be correct.  For
example; there is now an indirect link between the parser and java
support and not in the downwards direction but from the parser up to
java support (!?)

Others dependencies appear to be valid but exist between code which
should be merged and which shouldn't.  This made my approach of trying
to preserve history very challenging because I not only had to ensure
that the roots of patches from CEDET matched the correct destination in
their new home, but I also had to resolve conflicts where they diverged
and simultaneously remove dependencies where they were built up between
those parts which were destined for core and those which were not.

Dependency issues caused problems when trying to bootstrap Emacs on my
branch which had the whole of CEDET merged.  I did receive some help
from Eli at that point, but didn't get very far before David got
involved and started to drive that side of things.

Unfortunately, this vague description is the best I can do without
diving in again.

> Also, do you know which parts of CEDET were going to be offered as
> ELPA packages?  You mentioned COGRE already -- were there any others?

What follows is a (possibly non-exhaustive) list of the parts of CEDET
which I don't think were intended to reach core (gathered by diffing
trees and combining that with what I remember).  This is based on the
premise that if it wasn't in core previously then it shouldn't be merged
-- which is what was agreed upon.  Looking at the list though this does
exclude a lot of good stuff.
  - Everything in contrib (since I don't think that any of it is in
    core) including:
    - eassist
    - ede-gnustep
    - semantic-ectag-scala
    - semnatic-tag-folding
    - wisent-csharp
    - wisent-php
    - wisent-ruby
  - cedet-java and related including:
    - java-tags
    - java
    - jvm-base
  - cedet-graphviz
  - Various ede extensions
    - ant
    - maven
    - compdb
    - android
    - java-root
    - arduino
    - lein2
  - parts of db:
    - db-cscope
    - db-mozrepl
    - db-javap
    - db-mk
  - support for ectags:
    - ectags/util
    - ectags/lang2
    - ectags/parse
    - ectags/lang
    - ectags/db
  - more bovine parsers:
    - clang
    - f90
    - erlang
  - canned configs
  - db-search

Re: CEDET merge

[Dmitry Gutov]

Chong Yidong <cyd@gnu.org> writes:
 > I've done the merge, omitting senator and the defadvices as you
 > suggested.

Was removing the "Package-Version" header from eieio.el intentional?
It broke some ELPA packages.

Warning (emacs): Unable to activate package `pcache'.
Required package `eieio-1.3' is unavailable
Warning (emacs): Unable to activate package `logito'.
Required package `eieio-1.3' is unavailable
Warning (emacs): Unable to activate package `gist'.
Required package `eieio-1.3' is unavailable
Warning (emacs): Unable to activate package `gh'.
Required package `eieio-1.3' is unavailable

Re: CEDET merge

[Chong Yidong]

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

Dmitry Gutov <dgutov@yandex.ru> writes:

> Was removing the "Package-Version" header from eieio.el intentional?
> It broke some ELPA packages.
>
> Warning (emacs): Unable to activate package `pcache'.
> Required package `eieio-1.3' is unavailable

Thanks for pointing this out.  I restored the headers.

David, could you restore the Version: headers upstream as well?  (These
headers are needed by ELPA packages which depend on CEDET components;
the ELPA system generates package versions from them.)  Patch attached.


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

=== modified file 'lisp/ChangeLog'
*** lisp/ChangeLog	2012-10-02 03:49:28 +0000
--- lisp/ChangeLog	2012-10-02 05:02:52 +0000
***************
*** 1,3 ****
--- 1,7 ----
+ 2012-10-02  Chong Yidong  <cyd@gnu.org>
+ 
+ 	* emacs-lisp/eieio.el: Restore Version header.
+ 
  2012-10-02  Stefan Monnier  <monnier@iro.umontreal.ca>
  
  	* vc/diff-mode.el (diff--auto-refine-data): New var.

=== modified file 'lisp/cedet/ChangeLog'
*** lisp/cedet/ChangeLog	2012-10-01 18:10:29 +0000
--- lisp/cedet/ChangeLog	2012-10-02 05:02:52 +0000
***************
*** 1,3 ****
--- 1,7 ----
+ 2012-10-02  Chong Yidong  <cyd@gnu.org>
+ 
+ 	* srecode.el, ede.el: Restore Version header.
+ 
  2012-10-01  Chong Yidong  <cyd@gnu.org>
  
  	* semantic/bovine/c-by.el: Regenerate.

=== modified file 'lisp/cedet/ede.el'
*** lisp/cedet/ede.el	2012-10-01 18:10:29 +0000
--- lisp/cedet/ede.el	2012-10-02 05:02:52 +0000
***************
*** 4,9 ****
--- 4,10 ----
  
  ;; Author: Eric M. Ludlam <zappo@gnu.org>
  ;; Keywords: project, make
+ ;; Version: 1.0
  
  ;; This file is part of GNU Emacs.
  

=== modified file 'lisp/cedet/srecode.el'
*** lisp/cedet/srecode.el	2012-10-01 18:10:29 +0000
--- lisp/cedet/srecode.el	2012-10-02 05:02:52 +0000
***************
*** 4,9 ****
--- 4,10 ----
  
  ;; Author: Eric M. Ludlam <zappo@gnu.org>
  ;; Keywords: codegeneration
+ ;; Version: 1.0
  
  ;; This file is part of GNU Emacs.
  

=== modified file 'lisp/emacs-lisp/eieio.el'
*** lisp/emacs-lisp/eieio.el	2012-10-01 18:10:29 +0000
--- lisp/emacs-lisp/eieio.el	2012-10-02 05:02:52 +0000
***************
*** 4,9 ****
--- 4,10 ----
  ;; Copyright (C) 1995-1996, 1998-2012  Free Software Foundation, Inc.
  
  ;; Author: Eric M. Ludlam <zappo@gnu.org>
+ ;; Version: 1.3
  ;; Keywords: OO, lisp
  
  ;; This file is part of GNU Emacs.

Re: CEDET merge

[David Engster]

Chong Yidong writes:
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> Was removing the "Package-Version" header from eieio.el intentional?
>> It broke some ELPA packages.
>>
>> Warning (emacs): Unable to activate package `pcache'.
>> Required package `eieio-1.3' is unavailable
>
> Thanks for pointing this out.  I restored the headers.
>
> David, could you restore the Version: headers upstream as well?

Will do. I didn't know that ELPA depended on them; I thought they were
remnants of the CEDET packaging system.

-David

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

[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

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

CEDET merge

[Chong Yidong]

I have merged most of the CEDET branch into the trunk.  You may need to
bootstrap; please let me know if there are any build failures.

I have done what I can to clean up CEDET to conform to Emacs standards;
if you see anything I missed, please go ahead and make the change.

Currently, the interface to Semantic is via "M-x semantic-mode", and to
EDE via "M-x global-ede-mode"; these should install a "Development" menu
on the menu bar that can be used to enable further features.
Suggestions about improving this interface, and the CEDET integration in
general, are welcome.

(If you want to make bigger changes to the internals of CEDET itself,
please discuss first, because we need to coordinate that kind of change
with upstream.)

Re: CEDET merge

[Ulrich Mueller]

>>>>> On Mon, 28 Sep 2009, Chong Yidong wrote:

> I have merged most of the CEDET branch into the trunk. You may need
> to bootstrap; please let me know if there are any build failures.

I've tried to byte-compile some packages like company-mode [1] and
JDE [2] with the CEDET included in Emacs, and they fail because some
files that they require have a different name now. For example:

   In toplevel form:
   company-semantic.el:21:1:Error: Cannot open load file: semantic-ia

Was this renaming of files really necessary? It breaks backwards
compatibility and imposes additional work on package authors and
distros.

Ulrich

[1] http://nschum.de/src/emacs/company-mode/
[2] http://jdee.sourceforge.net/

Re: CEDET merge

[Chong Yidong]

Ulrich Mueller <ulm@gentoo.org> writes:

> Was this renaming of files really necessary? It breaks backwards
> compatibility and imposes additional work on package authors and
> distros.

No one suggested any other solution to the filename problem.

Maybe we could get around this by adding a `cedet-compat' package that
loads everything everything in CEDET and provides all the old CEDET
feature names; then loading this file will provide everything a
third-party package needs to compile.

Re: CEDET merge

[Ulrich Mueller]

>>>>> On Mon, 28 Sep 2009, Chong Yidong wrote:

>> Was this renaming of files really necessary? It breaks backwards
>> compatibility and imposes additional work on package authors and
>> distros.

> No one suggested any other solution to the filename problem.

The obvious solution is not to support CEDET on platforms with 8+3
filenames ...

> Maybe we could get around this by adding a `cedet-compat' package
> that loads everything everything in CEDET and provides all the old
> CEDET feature names; then loading this file will provide everything
> a third-party package needs to compile.

Not sure if loading everything at once is a good idea. CEDET is huge.
But couldn't at least the old feature names be provided by the single
files? (As it was done for newsticker-*, for example.)

Ulrich

Re: CEDET merge

[Chong Yidong]

Ulrich Mueller <ulm@gentoo.org> writes:

>>>>>> On Mon, 28 Sep 2009, Chong Yidong wrote:
>
>>> Was this renaming of files really necessary? It breaks backwards
>>> compatibility and imposes additional work on package authors and
>>> distros.
>
>> No one suggested any other solution to the filename problem.
>
> The obvious solution is not to support CEDET on platforms with 8+3
> filenames ...

I'm no expert, but according to Eli, having files longer than 8+3 in the
tarball leads to problems unpacking the tarball on DOS, and other
problems on some versions of Windows:

http://lists.gnu.org/archive/html/emacs-devel/2006-02/msg00149.html
http://lists.gnu.org/archive/html/emacs-devel/2005-12/msg01709.html

>> Maybe we could get around this by adding a `cedet-compat' package
>> that loads everything everything in CEDET and provides all the old
>> CEDET feature names; then loading this file will provide everything
>> a third-party package needs to compile.
>
> Not sure if loading everything at once is a good idea. CEDET is huge.
> But couldn't at least the old feature names be provided by the single
> files? (As it was done for newsticker-*, for example.)

We can do that, but how does this solve the problem?  The old `require'
calls still won't find the correct file (unless we implement feature
aliases or something like that).

Re: CEDET merge

[Ulrich Mueller]

>>>>> On Mon, 28 Sep 2009, Chong Yidong wrote:

>> The obvious solution is not to support CEDET on platforms with 8+3
>> filenames ...

> I'm no expert, but according to Eli, having files longer than 8+3
> in the tarball leads to problems unpacking the tarball on DOS, and
> other problems on some versions of Windows:

Supporting such antediluvian platforms is nice as long as it's
possible without too much effort. But if it becomes too much of a
burden one should reconsider if it's worthwhile (IMHO).

The renaming also increases the differences between Emacs and XEmacs
and packages intended for both will have to add further case
distinctions.

>> But couldn't at least the old feature names be provided by the
>> single files? (As it was done for newsticker-*, for example.)

> We can do that, but how does this solve the problem? The old
> `require' calls still won't find the correct file (unless we
> implement feature aliases or something like that).

It wouldn't solve it completely, but once the file is loaded the
feature (with the right name) will be present, and the third-party
package will run.

Ulrich

Re: CEDET merge

[Rupert Swarbrick]

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


Ulrich Mueller <ulm@gentoo.org> writes:
>> I'm no expert, but according to Eli, having files longer than 8+3
>> in the tarball leads to problems unpacking the tarball on DOS, and
>> other problems on some versions of Windows:
>
> Supporting such antediluvian platforms is nice as long as it's
> possible without too much effort. But if it becomes too much of a
> burden one should reconsider if it's worthwhile (IMHO).

antediluvian. Windows. Well, maybe, but on which of the platforms on
which Emacs runs does it have the most users? Come the revolution, we
FOSSers can drop compatibility hacks but until then, comrades, I'm
afraid we'll have to keep making allowances for those still in chains.


Rupert

(Who didn't write that last sentence grinning. Of course not)

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

Re: CEDET merge

[Ulrich Mueller]

>>>>> On Mon, 28 Sep 2009, Rupert Swarbrick wrote:

>>> I'm no expert, but according to Eli, having files longer than 8+3
>>> in the tarball leads to problems unpacking the tarball on DOS, and
>>> other problems on some versions of Windows:
>> 
>> Supporting such antediluvian platforms is nice as long as it's
>> possible without too much effort. But if it becomes too much of a
>> burden one should reconsider if it's worthwhile (IMHO).

> antediluvian. Windows.

;-)

> Well, maybe, but on which of the platforms on which Emacs runs does
> it have the most users? Come the revolution, we FOSSers can drop
> compatibility hacks but until then, comrades, I'm afraid we'll have
> to keep making allowances for those still in chains.

As far as I understand it, the 8+3 limitation is only relevant for
MS-DOS and very old (pre-NT?) MS-Windows versions. So users of recent
Windows should not be affected by it.

Ulrich

Re: CEDET merge

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Mon, 28 Sep 2009 11:31:51 -0400
> 
> I have merged most of the CEDET branch into the trunk.  You may need to
> bootstrap; please let me know if there are any build failures.

Thanks.  I suggest to update ldefs-boot.el.

Re: CEDET merge

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Mon, 28 Sep 2009 11:31:51 -0400
> 
> I have merged most of the CEDET branch into the trunk.  You may need to
> bootstrap; please let me know if there are any build failures.

I see warnings about shadowing libraries, after bootstrapping:

  This site has duplicate Lisp libraries with the same name.
  If a locally-installed Lisp library overrides a library in the Emacs release,
  that can cause trouble, and you should probably remove the locally-installed
  version unless you know what you are doing.

  emacs/lisp/format hides emacs/lisp/cedet/semantic/format
  emacs/lisp/emacs-lisp/debug hides emacs/lisp/cedet/semantic/debug
  emacs/lisp/complete hides emacs/lisp/cedet/semantic/complete
  emacs/lisp/emacs-lisp/chart hides emacs/lisp/cedet/semantic/chart
  emacs/lisp/loaddefs hides emacs/lisp/cedet/semantic/loaddefs
  emacs/lisp/sort hides emacs/lisp/cedet/semantic/sort
  emacs/lisp/cedet/semantic/wisent hides emacs/lisp/cedet/semantic/wisent/wisent
  emacs/lisp/progmodes/grep hides emacs/lisp/cedet/semantic/symref/grep
  emacs/lisp/emacs-lisp/debug hides emacs/lisp/cedet/semantic/bovine/debug
  emacs/lisp/emacs-lisp/debug hides emacs/lisp/cedet/semantic/analyze/debug
  emacs/lisp/complete hides emacs/lisp/cedet/semantic/analyze/complete

  11 Emacs Lisp load-path shadowings were found

Re: CEDET merge

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> I see warnings about shadowing libraries, after bootstrapping:
>
>   This site has duplicate Lisp libraries with the same name.
>   If a locally-installed Lisp library overrides a library in the Emacs release,
>   that can cause trouble, and you should probably remove the locally-installed
>   version unless you know what you are doing.

That's strange.  Does your load path include lisp/cedet/semantic after
bootstrapping, and if so is there a subdirs.el in lisp/cedet for some
reason?  It should not be there; I made a change in Makefile.in
specifically to prevent subdirs.el from being created in that directory.

Re: CEDET merge

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 28 Sep 2009 14:25:48 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I see warnings about shadowing libraries, after bootstrapping:
> >
> >   This site has duplicate Lisp libraries with the same name.
> >   If a locally-installed Lisp library overrides a library in the Emacs release,
> >   that can cause trouble, and you should probably remove the locally-installed
> >   version unless you know what you are doing.
> 
> That's strange.  Does your load path include lisp/cedet/semantic after
> bootstrapping

Yes, it includes cedet, cedet/semantic, cedet/semantic/wisent,
cedet/semantic/symref, cedet/semantic/decorate, cedet/semantic/bovine,
and cedet/semantic/analyze

> and if so is there a subdirs.el in lisp/cedet for some
> reason?

Yes, there is.  It says this:

    (normal-top-level-add-to-load-path '("semantic" ))

There's also subdirs.el in cedet/semantic.

> It should not be there; I made a change in Makefile.in
> specifically to prevent subdirs.el from being created in that directory.
 
What change you made, and in what Makefile.in?

All I can say is that I ran `confugure' and `make -j6 bootstrap'.  And
I have the Bash history to prove that.

[Time passes...]  Ah, I think I see the problem: this subdirs.el is
very old, from 2 weeks ago.  I think it was created when you added the
directories in the CEDET branch, at which time they appeared (as
empty) on HEAD as well, and then make-subdirs created the file.  If I
delete that file, the problem is gone.

So maybe "make bootstrap" should delete all subdirs.el, as cleanup.

Re: CEDET merge

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> [Time passes...]  Ah, I think I see the problem: this subdirs.el is
> very old, from 2 weeks ago.  I think it was created when you added the
> directories in the CEDET branch, at which time they appeared (as
> empty) on HEAD as well, and then make-subdirs created the file.

You should always pass -P to cvs update.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: CEDET merge

[Phil Hagelberg]

Chong Yidong <cyd@stupidchicken.com> writes:

> I have merged most of the CEDET branch into the trunk.  You may need to
> bootstrap; please let me know if there are any build failures.
>
> I have done what I can to clean up CEDET to conform to Emacs standards;
> if you see anything I missed, please go ahead and make the change.

Thanks. I am working on Rudel, a library that requires CEDET, and this
should make the install process much easier.

Rudel uses eieio as well as inversion.el, fame.el, and working.el. The
last three of these are files from CEDET's common/ directory. From what
I can tell, fame.el and working.el were not included in the merge. Was
this intentional? What were the deciding factors in what to include?

Perhaps they could be offered using package.el if we decide to integrate
it into Emacs?

-Phil

Re: CEDET merge

[Chong Yidong]

Phil Hagelberg <phil@hagelb.org> writes:

> Rudel uses eieio as well as inversion.el, fame.el, and working.el. The
> last three of these are files from CEDET's common/ directory. From what
> I can tell, fame.el and working.el were not included in the merge. Was
> this intentional? What were the deciding factors in what to include?

I didn't include working.el (and fame.el, which is only there for
working.el) because I couldn't work out what advantage it brought over
the built-in progress reporter, which is a couple of hundred lines in
subr.el, already documented in the manual, and works fine.  This seems
too big a solution for a problem that's tangentially related to the rest
of CEDET, but maybe you can convince me otherwise.

As for the other omitted stuff, there are a couple of files in Semantic
not written by Eric that we don't have paperwork for yet (the Imenu
support and the Erlang and Python parsers).  Also the Srecode template
files and Semantic grammar files, which I haven't figured out where to
put (maybe a subdirectory in admin; any help with this task would be
appreciated).  And I may have overlooked some other things.

Re: CEDET merge

[Phil Hagelberg]

Chong Yidong <cyd@stupidchicken.com> writes:

> This seems too big a solution for a problem that's tangentially
> related to the rest of CEDET, but maybe you can convince me otherwise.

Not at all, I'd rather remove the working.el dependency from
Rudel itself. Thanks for the explanation.

-Phil

Re: CEDET merge

[Phil Hagelberg]

Chong Yidong <cyd@stupidchicken.com> writes:

> I didn't include working.el (and fame.el, which is only there for
> working.el) because I couldn't work out what advantage it brought over
> the built-in progress reporter, which is a couple of hundred lines in
> subr.el, already documented in the manual, and works fine.

The reason Rudel uses the CEDET one vs the built-in Emacs one is that it
needs a way to indicate that something is happening without knowing the
overall percentage of the task that is actually complete. I believe this
is commonly known as "pulsing" or a "spinner".

We could probably implement this as an addition to the built-in progress
reporter in subr.el; would this be a welcome feature?

-Phil

Re: CEDET merge

[Chong Yidong]

Phil Hagelberg <phil@hagelb.org> writes:

> The reason Rudel uses the CEDET one vs the built-in Emacs one is that it
> needs a way to indicate that something is happening without knowing the
> overall percentage of the task that is actually complete. I believe this
> is commonly known as "pulsing" or a "spinner".
>
> We could probably implement this as an addition to the built-in progress
> reporter in subr.el; would this be a welcome feature?

Yes, and it should be easy to implement too.

Re: CEDET merge

[Phil Hagelberg]

Chong Yidong <cyd@stupidchicken.com> writes:

> Phil Hagelberg <phil@hagelb.org> writes:
>> The reason Rudel uses the CEDET one vs the built-in Emacs one is that it
>> needs a way to indicate that something is happening without knowing the
>> overall percentage of the task that is actually complete. I believe this
>> is commonly known as "pulsing" or a "spinner".
>>
>> We could probably implement this as an addition to the built-in progress
>> reporter in subr.el; would this be a welcome feature?
>
> Yes, and it should be easy to implement too.

Here's what I've come up with:

(defvar progress-pulse-values ["-" "\\" "|" "/"]
  "A vector of characters to use for pulsing progress reporters.")

(defun make-pulsing-progress-reporter (&optional message)
  "Return a pulsing progress reporter that display MESSAGE.
MESSAGE can contain all formatting characters accepted by
`format'. If message is nil, the string \"Working ...\" is
displayed.

Example:
(let ((rep (make-pulsing-progress-reporter \"Connecting\")))
  (dotimes (n 3)
    (sleep-for 0.1)
    (progress-reporter-pulse rep \"Connecting [new]\"))
  (dotimes (n 3)
    (sleep-for 0.1)
    (progress-reporter-pulse rep \"Connecting [synching]\"))
  (dotimes (n 3)
    (sleep-for 0.1)
    (progress-reporter-pulse rep \"Connecting [idle]\"))
  (progress-reporter-pulse rep \"Connecting \")
  (progress-reporter-done rep))"
  (cons nil ; total value is not known
    (vector nil 0 'dummy (or message "Working ... "))))

(defun progress-reporter-pulse (reporter &optional new-message)
  "Advance pulsing indicator of REPORTER. Display NEW-MESSAGE if given."
  (let* ((parameters (cdr reporter))
         (message    (or new-message (aref parameters 3)))
         (index      (aref parameters 1))
         (new-index  (mod (+ index 1) 4)))
    (aset parameters 1 new-index)
    (aset parameters 3 message)
    (let ((message-log-max nil)) ; No logging
      (message "%s %s"
               (aref progress-pulse-values new-index)
               message))))

The example in the docstring should make it clear how this works. It's
fairly close to how the existing progress reporter works, but it's got
nil in a couple places in the data structure due to not knowing the
total progress.

I have my paperwork in. I could submit this as a patch if that's more
convenient, or you could find a place for it in subr.el.

Thanks!

-Phil

Re: CEDET merge

[Chong Yidong]

Phil Hagelberg <phil@hagelb.org> writes:

> (defun make-pulsing-progress-reporter (&optional message)

I think `make-progress-reporter' should do "pulsing" automatically if
min-value and max-value are null, instead of providing a new function.

Re: CEDET merge

[Phil Hagelberg]

Chong Yidong <cyd@stupidchicken.com> writes:

> Phil Hagelberg <phil@hagelb.org> writes:
>
>> (defun make-pulsing-progress-reporter (&optional message)
>
> I think `make-progress-reporter' should do "pulsing" automatically if
> min-value and max-value are null, instead of providing a new function.

Good idea. I will implement that and send a patch.

-Phil

Re: CEDET merge

[Phil Hagelberg]

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

Phil Hagelberg <phil@hagelb.org> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>> Phil Hagelberg <phil@hagelb.org> writes:
>>
>>> (defun make-pulsing-progress-reporter (&optional message)
>>
>> I think `make-progress-reporter' should do "pulsing" automatically if
>> min-value and max-value are null, instead of providing a new function.
>
> Good idea. I will implement that and send a patch.

The attached patch implements this. So make-progress-reporter will make
a pulsing reporter when min-value and max-value are not specified.

I made it so that you must use progress-reporter-pulse to update a
pulsing reporter, but I realized afterwards that it would be easy enough
to have progress-reporter-update check to see if the reporter is a
pulsing one or not and call the correct function underneath without the
caller having to think about it.

If you think this is a good idea I can make the change.

-Phil


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-pulsing-progress-reporter-functionality.patch --]
[-- Type: text/x-diff, Size: 3855 bytes --]

From 91f10af059ab03d50da990a332995b93aa4fcfbc Mon Sep 17 00:00:00 2001
From: Phil Hagelberg <technomancy@gmail.com>
Date: Wed, 30 Sep 2009 22:02:57 -0700
Subject: [PATCH] Add pulsing progress reporter functionality.

---
 lisp/subr.el |   41 ++++++++++++++++++++++++++++++-----------
 1 files changed, 30 insertions(+), 11 deletions(-)

diff --git a/lisp/subr.el b/lisp/subr.el
index a7d3fcd..e26783f 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -3415,9 +3415,8 @@ you call it."
   (when (>= value (car reporter))
     (progress-reporter-do-update reporter value)))
 
-(defun make-progress-reporter (message min-value max-value
-				       &optional current-value
-				       min-change min-time)
+(defun make-progress-reporter (message &optional min-value max-value
+				       current-value min-change min-time)
   "Return progress reporter object to be used with `progress-reporter-update'.
 
 MESSAGE is shown in the echo area.  When at least 1% of operation
@@ -3426,20 +3425,23 @@ MESSAGE.  When you call `progress-reporter-done', word \"done\"
 is printed after the MESSAGE.  You can change MESSAGE of an
 existing progress reporter with `progress-reporter-force-update'.
 
-MIN-VALUE and MAX-VALUE designate starting (0% complete) and
-final (100% complete) states of operation.  The latter should be
-larger; if this is not the case, then simply negate all values.
-Optional CURRENT-VALUE specifies the progress by the moment you
-call this function.  You should omit it or set it to nil in most
-cases since it defaults to MIN-VALUE.
+If provided, MIN-VALUE and MAX-VALUE designate starting (0%
+complete) and final (100% complete) states of operation.  The
+latter should be larger; if this is not the case, then simply
+negate all values.  Optional CURRENT-VALUE specifies the progress
+by the moment you call this function.  You should omit it or set
+it to nil in most cases since it defaults to MIN-VALUE.
 
 Optional MIN-CHANGE determines the minimal change in percents to
 report (default is 1%.)  Optional MIN-TIME specifies the minimal
 time before echo area updates (default is 0.2 seconds.)  If
 `float-time' function is not present, then time is not tracked
 at all.  If OS is not capable of measuring fractions of seconds,
-then this parameter is effectively rounded up."
+then this parameter is effectively rounded up.
 
+If MIN-VALUE and MAX-VALUE are unknown, they may be omitted to
+return a \"pulsing\" progress reporter. This should be updated
+using the `progress-reporter-pulse' function instead."
   (unless min-time
     (setq min-time 0.2))
   (let ((reporter
@@ -3447,7 +3449,7 @@ then this parameter is effectively rounded up."
 	       (vector (if (and (fboundp 'float-time)
 				(>= min-time 0.02))
 			   (float-time) nil)
-		       min-value
+		       (or min-value 0)
 		       max-value
 		       message
 		       (if min-change (max (min min-change 50) 1) 1)
@@ -3505,6 +3507,23 @@ change the displayed message."
 	  (message "%s%d%%" (aref parameters 3) percentage)
 	(message "%s" (aref parameters 3))))))
 
+(defvar progress-pulse-values ["-" "\\" "|" "/"]
+  "Characters to use for pulsing progress reporters.")
+
+(defun progress-reporter-pulse (reporter &optional new-message)
+  "Advance pulsing indicator of REPORTER. Display NEW-MESSAGE if given."
+  (let* ((parameters (cdr reporter))
+	 (message    (or new-message
+			 (aref parameters 3)))
+	 (index      (aref parameters 1))
+	 (new-index  (mod (+ index 1) 4)))
+    (aset parameters 1 new-index)
+    (aset parameters 3 message)
+    (let ((message-log-max nil)) ; No logging
+      (message "%s %s"
+	       (aref progress-pulse-values new-index)
+	       message))))
+
 (defun progress-reporter-done (reporter)
   "Print reporter's message followed by word \"done\" in echo area."
   (message "%sdone" (aref (cdr reporter) 3)))
-- 
1.6.0.4

Re: CEDET merge

[Stefan Monnier]

> I made it so that you must use progress-reporter-pulse to update a
> pulsing reporter, but I realized afterwards that it would be easy enough
> to have progress-reporter-update check to see if the reporter is a
> pulsing one or not and call the correct function underneath without the
> caller having to think about it.

> If you think this is a good idea I can make the change.

Yes, that would be even better, thank you,


        Stefan

Re: CEDET merge

[Phil Hagelberg]

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

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I made it so that you must use progress-reporter-pulse to update a
>> pulsing reporter, but I realized afterwards that it would be easy enough
>> to have progress-reporter-update check to see if the reporter is a
>> pulsing one or not and call the correct function underneath without the
>> caller having to think about it.
>
>> If you think this is a good idea I can make the change.
>
> Yes, that would be even better, thank you,

I've attached the patches that implement this. Pulsing reporters can use
progress-reporter-update like normal ones and can have their messages
changed using progress-reporter-force-update.

thanks!
Phil


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-pulsing-progress-reporter-functionality.patch --]
[-- Type: text/x-diff, Size: 3855 bytes --]

From 91f10af059ab03d50da990a332995b93aa4fcfbc Mon Sep 17 00:00:00 2001
From: Phil Hagelberg <technomancy@gmail.com>
Date: Wed, 30 Sep 2009 22:02:57 -0700
Subject: [PATCH] Add pulsing progress reporter functionality.

---
 lisp/subr.el |   41 ++++++++++++++++++++++++++++++-----------
 1 files changed, 30 insertions(+), 11 deletions(-)

diff --git a/lisp/subr.el b/lisp/subr.el
index a7d3fcd..e26783f 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -3415,9 +3415,8 @@ you call it."
   (when (>= value (car reporter))
     (progress-reporter-do-update reporter value)))
 
-(defun make-progress-reporter (message min-value max-value
-				       &optional current-value
-				       min-change min-time)
+(defun make-progress-reporter (message &optional min-value max-value
+				       current-value min-change min-time)
   "Return progress reporter object to be used with `progress-reporter-update'.
 
 MESSAGE is shown in the echo area.  When at least 1% of operation
@@ -3426,20 +3425,23 @@ MESSAGE.  When you call `progress-reporter-done', word \"done\"
 is printed after the MESSAGE.  You can change MESSAGE of an
 existing progress reporter with `progress-reporter-force-update'.
 
-MIN-VALUE and MAX-VALUE designate starting (0% complete) and
-final (100% complete) states of operation.  The latter should be
-larger; if this is not the case, then simply negate all values.
-Optional CURRENT-VALUE specifies the progress by the moment you
-call this function.  You should omit it or set it to nil in most
-cases since it defaults to MIN-VALUE.
+If provided, MIN-VALUE and MAX-VALUE designate starting (0%
+complete) and final (100% complete) states of operation.  The
+latter should be larger; if this is not the case, then simply
+negate all values.  Optional CURRENT-VALUE specifies the progress
+by the moment you call this function.  You should omit it or set
+it to nil in most cases since it defaults to MIN-VALUE.
 
 Optional MIN-CHANGE determines the minimal change in percents to
 report (default is 1%.)  Optional MIN-TIME specifies the minimal
 time before echo area updates (default is 0.2 seconds.)  If
 `float-time' function is not present, then time is not tracked
 at all.  If OS is not capable of measuring fractions of seconds,
-then this parameter is effectively rounded up."
+then this parameter is effectively rounded up.
 
+If MIN-VALUE and MAX-VALUE are unknown, they may be omitted to
+return a \"pulsing\" progress reporter. This should be updated
+using the `progress-reporter-pulse' function instead."
   (unless min-time
     (setq min-time 0.2))
   (let ((reporter
@@ -3447,7 +3449,7 @@ then this parameter is effectively rounded up."
 	       (vector (if (and (fboundp 'float-time)
 				(>= min-time 0.02))
 			   (float-time) nil)
-		       min-value
+		       (or min-value 0)
 		       max-value
 		       message
 		       (if min-change (max (min min-change 50) 1) 1)
@@ -3505,6 +3507,23 @@ change the displayed message."
 	  (message "%s%d%%" (aref parameters 3) percentage)
 	(message "%s" (aref parameters 3))))))
 
+(defvar progress-pulse-values ["-" "\\" "|" "/"]
+  "Characters to use for pulsing progress reporters.")
+
+(defun progress-reporter-pulse (reporter &optional new-message)
+  "Advance pulsing indicator of REPORTER. Display NEW-MESSAGE if given."
+  (let* ((parameters (cdr reporter))
+	 (message    (or new-message
+			 (aref parameters 3)))
+	 (index      (aref parameters 1))
+	 (new-index  (mod (+ index 1) 4)))
+    (aset parameters 1 new-index)
+    (aset parameters 3 message)
+    (let ((message-log-max nil)) ; No logging
+      (message "%s %s"
+	       (aref progress-pulse-values new-index)
+	       message))))
+
 (defun progress-reporter-done (reporter)
   "Print reporter's message followed by word \"done\" in echo area."
   (message "%sdone" (aref (cdr reporter) 3)))
-- 
1.6.0.4


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Update-pulsing-reporters-to-work-with-regular-report.patch --]
[-- Type: text/x-diff, Size: 4320 bytes --]

From 89616487ab6f10fb5ec2d6369bddaf58745a40b3 Mon Sep 17 00:00:00 2001
From: Phil Hagelberg <technomancy@gmail.com>
Date: Fri, 2 Oct 2009 10:44:07 -0700
Subject: [PATCH] Update pulsing reporters to work with regular reporter functions.

Use progress-reporter-update for updating and
progress-reporter-force-update to update message. Remove
message-changing from progress-reporter-pulse.
---
 lisp/subr.el |   51 ++++++++++++++++++++++++++++-----------------------
 1 files changed, 28 insertions(+), 23 deletions(-)

diff --git a/lisp/subr.el b/lisp/subr.el
index e26783f..bbf2051 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -3399,21 +3399,25 @@ The properties used on SYMBOL are `composefunc', `sendfunc',
 ;; digits of precision, it doesn't really matter here.  On the other
 ;; hand, it greatly simplifies the code.
 
-(defsubst progress-reporter-update (reporter value)
+(defsubst progress-reporter-update (reporter &optional value)
   "Report progress of an operation in the echo area.
+
+The first parameter, REPORTER, should be the result of a call to
+`make-progress-reporter'. For reporters for which the max value
+is known, the second argument determines the actual progress of
+operation; it must be between MIN-VALUE and MAX-VALUE as passed
+to `make-progress-reporter'.
+
 However, if the change since last echo area update is too small
 or not enough time has passed, then do nothing (see
 `make-progress-reporter' for details).
 
-First parameter, REPORTER, should be the result of a call to
-`make-progress-reporter'.  Second, VALUE, determines the actual
-progress of operation; it must be between MIN-VALUE and MAX-VALUE
-as passed to `make-progress-reporter'.
-
-This function is very inexpensive, you may not bother how often
-you call it."
-  (when (>= value (car reporter))
-    (progress-reporter-do-update reporter value)))
+In this case, this function is very inexpensive, you need not
+care how often you call it."
+  (if (progress-reporter-pulsing-p reporter)
+      (progress-reporter-pulse reporter)
+    (when (>= value (car reporter))
+      (progress-reporter-do-update reporter value))))
 
 (defun make-progress-reporter (message &optional min-value max-value
 				       current-value min-change min-time)
@@ -3440,8 +3444,7 @@ at all.  If OS is not capable of measuring fractions of seconds,
 then this parameter is effectively rounded up.
 
 If MIN-VALUE and MAX-VALUE are unknown, they may be omitted to
-return a \"pulsing\" progress reporter. This should be updated
-using the `progress-reporter-pulse' function instead."
+return a \"pulsing\" progress reporter."
   (unless min-time
     (setq min-time 0.2))
   (let ((reporter
@@ -3468,7 +3471,9 @@ change the displayed message."
       (aset parameters 3 new-message))
     (when (aref parameters 0)
       (aset parameters 0 (float-time)))
-    (progress-reporter-do-update reporter value)))
+    (if (progress-reporter-pulsing-p reporter)
+        (progress-reporter-pulse reporter)
+      (progress-reporter-do-update reporter value))))
 
 (defun progress-reporter-do-update (reporter value)
   (let* ((parameters   (cdr reporter))
@@ -3510,19 +3515,19 @@ change the displayed message."
 (defvar progress-pulse-values ["-" "\\" "|" "/"]
   "Characters to use for pulsing progress reporters.")
 
-(defun progress-reporter-pulse (reporter &optional new-message)
-  "Advance pulsing indicator of REPORTER. Display NEW-MESSAGE if given."
+(defun progress-reporter-pulsing-p (reporter)
+  "Return t if REPORTER has an unknown max value."
+  (null (aref (cdr reporter) 2)))
+
+(defun progress-reporter-pulse (reporter)
+  "Advance pulsing indicator of REPORTER."
   (let* ((parameters (cdr reporter))
-	 (message    (or new-message
-			 (aref parameters 3)))
-	 (index      (aref parameters 1))
-	 (new-index  (mod (+ index 1) 4)))
-    (aset parameters 1 new-index)
-    (aset parameters 3 message)
+	 (index      (+ (aref parameters 1) 1)))
+    (aset parameters 1 index)
     (let ((message-log-max nil)) ; No logging
       (message "%s %s"
-	       (aref progress-pulse-values new-index)
-	       message))))
+	       (aref progress-pulse-values (mod index 4))
+	       (aref parameters 3)))))
 
 (defun progress-reporter-done (reporter)
   "Print reporter's message followed by word \"done\" in echo area."
-- 
1.6.0.4

Re: CEDET merge

[Andreas Schwab]

Chong Yidong <cyd@stupidchicken.com> writes:

> I have merged most of the CEDET branch into the trunk.  You may need to
> bootstrap; please let me know if there are any build failures.

Compiling /home/andreas/src/emacs/emacs/lisp/cedet/semantic.el

In toplevel form:
../../emacs/lisp/cedet/semantic.el:33:1:Error: Given parent class semantic-symref-tool-baseclass is not a class
make[3]: *** [compile-last] Error 1

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: CEDET merge

[Andreas Schwab]

> Compiling /home/andreas/src/emacs/emacs/lisp/cedet/semantic.el
>
> In toplevel form:
> ../../emacs/lisp/cedet/semantic.el:33:1:Error: Given parent class semantic-symref-tool-baseclass is not a class
> make[3]: *** [compile-last] Error 1

That was due to a broken loaddefs file.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: CEDET merge

[Alan Mackenzie]

Hi, there!

On Mon, Sep 28, 2009 at 11:31:51AM -0400, Chong Yidong wrote:
> I have merged most of the CEDET branch into the trunk.  You may need to
> bootstrap; please let me know if there are any build failures.

Without the bootstrap, it failed to compile the cedet sources.  With a
make bootstrap, it just worked, out of the box.  :-)

> I have done what I can to clean up CEDET to conform to Emacs standards;
> if you see anything I missed, please go ahead and make the change.

> Currently, the interface to Semantic is via "M-x semantic-mode", and to
> EDE via "M-x global-ede-mode"; these should install a "Development" menu
> on the menu bar that can be used to enable further features.
> Suggestions about improving this interface, and the CEDET integration in
> general, are welcome.

> (If you want to make bigger changes to the internals of CEDET itself,
> please discuss first, because we need to coordinate that kind of change
> with upstream.)

Quick question.  Are there any CEDET manuals in this build?  I didn't
see any.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: CEDET merge

[Chong Yidong]

Alan Mackenzie <acm@muc.de> writes:

> Quick question.  Are there any CEDET manuals in this build?  I didn't
> see any.

They need to go in doc/misc, but I haven't done that yet.  (They
probably need to be checked too.)

I'll do this over the next few days, unless someone would like to do it
for me (they can be found in the CEDET upstream repository).

Re: CEDET merge

[Glenn Morris]

Chong Yidong wrote:

> I have merged most of the CEDET branch into the trunk.

It seems you did not merge semantic/adebug.el, was this deliberate?

semantic/db-find.el claims that data-debug-insert-tag-list is defined
in data-debug.el, but it is not, it is defined in adebug.el, which is
not present in the trunk.

Re: CEDET merge

[Eric M. Ludlam]

On Tue, 2009-09-29 at 00:28 -0400, Glenn Morris wrote:
> Chong Yidong wrote:
> 
> > I have merged most of the CEDET branch into the trunk.
> 
> It seems you did not merge semantic/adebug.el, was this deliberate?
> 
> semantic/db-find.el claims that data-debug-insert-tag-list is defined
> in data-debug.el, but it is not, it is defined in adebug.el, which is
> not present in the trunk.
> 

Your email has reminded me that I've wanted to rename semantic-adebug.el
to something more descriptive.  It was originally a semantic specific
tool which I generalized as a data-debug.el for most things in Emacs.

Not that I have a fabulous name in mind though.  "a" was just a vowel to
go along with "e" debug which is a bit lame.  It should probably be
semantic-datadebug.el to match up with eieio-datadebug.el.  (Using the
parlance of the CEDET suite on sourceforge.  For Emacs I guess it would
be semantic/datadebug.el.)

Eric

Re: CEDET merge

[Juanma Barranquero]

On Mon, Sep 28, 2009 at 17:31, Chong Yidong <cyd@stupidchicken.com> wrote:

> I have merged most of the CEDET branch into the trunk.  You may need to
> bootstrap; please let me know if there are any build failures.

semantic/cedet/wisent/javat-wy.el has coding issues, because of this line:

     ("char" summary "Integral primitive type ('^@' to '\357\227\227')
(0 to 65535)")

so on Windows it is decoded as "=(Unix)" (i.e., no-conversion, LF),
and does not compile:

In toplevel form:
javat-wy.el:680:36:Error: End of file during parsing

    Juanma

Re: CEDET merge

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 30 Sep 2009 11:32:25 +0200
> Cc: emacs-devel@gnu.org
> 
> semantic/cedet/wisent/javat-wy.el has coding issues, because of this line:
> 
>      ("char" summary "Integral primitive type ('^@' to '\357\227\227')
> (0 to 65535)")
> 
> so on Windows it is decoded as "=(Unix)" (i.e., no-conversion, LF),

The same happens on Unix, because the null byte forces the file to be
treated as binary.

> and does not compile:
> 
> In toplevel form:
> javat-wy.el:680:36:Error: End of file during parsing

Why, because the lines actually have CRLF Windows-style EOLs on your
machine?  Or for some other reason?  IOW, I don't see why
no-conversion should cause the file not to compile, and only on
Windows.  What am I missing?

Anyway, 2 ideas to work around this:

  . Replace the null byte with \000

  . Put "inhibit-null-byte-detection: t" in file-local variables.

Re: CEDET merge

[Juanma Barranquero]

On Wed, Sep 30, 2009 at 20:38, Eli Zaretskii <eliz@gnu.org> wrote:

>> and does not compile:
>>
>> In toplevel form:
>> javat-wy.el:680:36:Error: End of file during parsing
>
> Why, because the lines actually have CRLF Windows-style EOLs on your
> machine?

Checking it out with CVS, yes, it has CRLF EOLs. In fact, editing it
all lines end with ^M.

> IOW, I don't see why
> no-conversion should cause the file not to compile, and only on
> Windows.  What am I missing?

The CRs, apparently.

> Anyway, 2 ideas to work around this:
>
>  . Replace the null byte with \000

That works.

    Juanma

Re: CEDET merge

[Sascha Wilde]

Chong Yidong <cyd@stupidchicken.com> wrote:

> I have merged most of the CEDET branch into the trunk.  You may need to
> bootstrap; please let me know if there are any build failures.

Thanks a lot I'm very curious about this new features.

Giving the ede part a quick try[0] I stumbled upon a bunch of problems:

- After enabling global-ede-mode mode first observation was, that the
  new Development-menu was not accessible when using the pseudo menu on
  an tty (haven't tested an graphical interface yet): <F10> shows
  `---Development' among the menu items, which cant be selected.

- After creating a new project of the type `automake' (ede-new) and
  adding a new target with one source file (plain hello world in c) I
  tried `ede-compile-target' which reviled an error in one provide form.
  This patch fixes it:

diff -r d4a1d308c9fe lisp/cedet/ede/srecode.el
--- a/lisp/cedet/ede/srecode.el	Wed Sep 30 11:07:53 2009 +0200
+++ b/lisp/cedet/ede/srecode.el	Wed Sep 30 12:08:48 2009 +0200
@@ -101,6 +101,6 @@
 
     ))
 
-(provide 'ede-srecode)
+(provide 'ede/srecode)
 
 ;;; ede-srecode.el ends here

- But after that fix compiling still fails.  Now with:
  eieio-generic-call-primary-only: Method srecode-template-get-table called on nil

Any ideas?

cheers
sascha

[0] Disclaimer: I have never used CEDET before, so if some of my reports
    don't make any sense, please tell me so...
-- 
Sascha Wilde
Life's too short to read boring signatures

Re: CEDET merge

[Sascha Wilde]

Sascha Wilde <wilde@sha-bang.de> wrote:
> -(provide 'ede-srecode)
> +(provide 'ede/srecode)

This was fixed in current CVS, thanks.

> - But after that fix compiling still fails.  Now with:
>   eieio-generic-call-primary-only: Method srecode-template-get-table called on nil

This problem is still there.  A question to all CEDET/EDE experts: is
this an bug or am I missing something?

(and FWIW the development menu is still broken in tty mode, on X11/gtk
it works well).
-- 
Sascha Wilde
Nothing is fool-proof to a sufficiently talented fool.

Re: CEDET merge

[Eric M. Ludlam]

On Thu, 2009-10-01 at 12:58 +0200, Sascha Wilde wrote:
> Sascha Wilde <wilde@sha-bang.de> wrote:
> > -(provide 'ede-srecode)
> > +(provide 'ede/srecode)
> 
> This was fixed in current CVS, thanks.
> 
> > - But after that fix compiling still fails.  Now with:
> >   eieio-generic-call-primary-only: Method srecode-template-get-table called on nil
> 
> This problem is still there.  A question to all CEDET/EDE experts: is
> this an bug or am I missing something?

Chong Yidong said he hadn't figured out where to put the SRecode
templates.  Since EDE uses Srecode to templates to create Makefiles,
that is likely the problem.  The way SRecode looks up template files may
also not be compatible with where the templates will eventually live in
Emacs, so that would need to be updated.

Short term, you could get the templates from CEDET CVS in
cedet/srecode/templates and cedet/ede/templates and place them in
equivalent locations just under srecode.el and ede.el to get past this
until there is a home for SRecode Templates in Emacs.

Eric

Re: CEDET merge

[Sascha Wilde]

"Eric M. Ludlam" <eric@siege-engine.com> wrote:
> On Thu, 2009-10-01 at 12:58 +0200, Sascha Wilde wrote:
>> Sascha Wilde <wilde@sha-bang.de> wrote:
>> > - But after that fix compiling still fails.  Now with:
>> >   eieio-generic-call-primary-only: Method srecode-template-get-table called on nil
>> This problem is still there.  A question to all CEDET/EDE experts: is
>> this an bug or am I missing something?
>
> Chong Yidong said he hadn't figured out where to put the SRecode
> templates.  Since EDE uses Srecode to templates to create Makefiles,
> that is likely the problem.

Thanks for your explanation.

> Short term, you could get the templates from CEDET CVS in
> cedet/srecode/templates and cedet/ede/templates and place them in
> equivalent locations just under srecode.el and ede.el to get past this
> until there is a home for SRecode Templates in Emacs.

I'll give it a try...

cheers
sascha
-- 
>++++++[<+++++++++++>-]<+.>+++[<++++++>-]<.---.---------.++++++.++++.---------
-.+++++++++++.+++++.>+++++++[<-------->-]<-.>++++++[<+++++++>-]<+.--.+++..----
---.-.>++++++[<------>-]<.>++++[<+++++++++++++>-]<.------------.---.>++++++[<-
----->-]<-.>+++++[<+++++++>-]<.--.>+++[<++++++>-]<+.>++++++++[<--------->-]<--.

Re: CEDET merge

[Sascha Wilde]

Sascha Wilde <wilde@sha-bang.de> wrote:
> "Eric M. Ludlam" <eric@siege-engine.com> wrote:
>> On Thu, 2009-10-01 at 12:58 +0200, Sascha Wilde wrote:
>>> Sascha Wilde <wilde@sha-bang.de> wrote:
>>> > - But after that fix compiling still fails.  Now with:
>>> >   eieio-generic-call-primary-only: Method srecode-template-get-table called on nil
[...]
>> Short term, you could get the templates from CEDET CVS in
>> cedet/srecode/templates and cedet/ede/templates and place them in
>> equivalent locations just under srecode.el and ede.el to get past this
>> until there is a home for SRecode Templates in Emacs.
>
> I'll give it a try...

hmm, didn't work -- or maybe I haven't fully understood what to do.
Here is what I tried:
- I checked out the current cedet head from CVS
- I copied the directory cedet/ede/templates to
  /usr/share/emacs/23.1.50/lisp/cedet/ede/templates and
  cedet/srecode/templates to
  /usr/share/emacs/23.1.50/lisp/cedet/srecode/templates

That didn't work, so I tried puting all *.srt files from
cedet/ede/templates directly under
/usr/share/emacs/23.1.50/lisp/cedet/ede/ (and same for
/usr/share/emacs/23.1.50/lisp/cedet/srecode/) but this didn't work
either....

What am I missing?

sascha
-- 
Sascha Wilde

Programmer - A red-eyed, mumbling mammal capable of conversing with
             inanimate objects.

Re: CEDET merge

[Eric M. Ludlam]

On Thu, 2009-10-01 at 18:28 +0200, Sascha Wilde wrote:
> Sascha Wilde <wilde@sha-bang.de> wrote:
> > "Eric M. Ludlam" <eric@siege-engine.com> wrote:
> >> On Thu, 2009-10-01 at 12:58 +0200, Sascha Wilde wrote:
> >>> Sascha Wilde <wilde@sha-bang.de> wrote:
> >>> > - But after that fix compiling still fails.  Now with:
> >>> >   eieio-generic-call-primary-only: Method srecode-template-get-table called on nil
> [...]
> >> Short term, you could get the templates from CEDET CVS in
> >> cedet/srecode/templates and cedet/ede/templates and place them in
> >> equivalent locations just under srecode.el and ede.el to get past this
> >> until there is a home for SRecode Templates in Emacs.
> >
> > I'll give it a try...
> 
> hmm, didn't work -- or maybe I haven't fully understood what to do.
> Here is what I tried:
> - I checked out the current cedet head from CVS
> - I copied the directory cedet/ede/templates to
>   /usr/share/emacs/23.1.50/lisp/cedet/ede/templates and
>   cedet/srecode/templates to
>   /usr/share/emacs/23.1.50/lisp/cedet/srecode/templates
> 
> That didn't work, so I tried puting all *.srt files from
> cedet/ede/templates directly under
> /usr/share/emacs/23.1.50/lisp/cedet/ede/ (and same for
> /usr/share/emacs/23.1.50/lisp/cedet/srecode/) but this didn't work
> either....
> 

I must apologize for not actually trying out the Emacs integration.  It
is pumpkin throwing season which keeps me busy.  (see
www.punkinchunkin.com for the sport, or www.siege-engine.com for my
team.)

Anyway, the template directory is set up like this for EDE:

  (let* ((lib (locate-library "ede.el" t))
	 (ededir (file-name-directory lib))
	 (tmpdir (file-name-as-directory
		  (expand-file-name "templates" ededir))))
    (when (not tmpdir)
      (error "Unable to location EDE Templates directory"))

    (require 'srecode-map)
    (add-to-list 'srecode-map-load-path tmpdir)
    (srecode-map-update-map t)


but you could just do this in your basic setup by specifying a load path
for srecode directly, as in the code above reveals.

Eric

Re: CEDET merge

[Sascha Wilde]

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

"Eric M. Ludlam" <eric@siege-engine.com> wrote:
[...]
> I must apologize for not actually trying out the Emacs integration.  It
> is pumpkin throwing season which keeps me busy.  (see
> www.punkinchunkin.com for the sport, or www.siege-engine.com for my
> team.)

Thanks for your reply.  I have to admit, that I hardly read any more
convincing (and judging from the pictures: more impressive) excuse for
being less responsive than that...  ;-)

> Anyway, the template directory is set up like this for EDE:
>
>   (let* ((lib (locate-library "ede.el" t))
> 	 (ededir (file-name-directory lib))
> 	 (tmpdir (file-name-as-directory
> 		  (expand-file-name "templates" ededir))))
>     (when (not tmpdir)
>       (error "Unable to location EDE Templates directory"))
>
>     (require 'srecode-map)

FWIW: 'srecode/map with the Emacs integration.

>     (add-to-list 'srecode-map-load-path tmpdir)
>     (srecode-map-update-map t)

This (and some digging in the content of srecode-map-load-path) brought
me a step further.  I copied all ede and srecode templates from the
cedet CVS to ~/.srecode/ which was in my srecode-map-load-path.

Now I get an different error on any attempt to rebuild a projects
makefile (which afaiu is also a part of compiling).  From *Messages*:

Replace EDE Makefile
Compiling template default.srt...
0 templates compiled for nil
srecode-compile-templates: You must specify a MODE for your templates

Is more information needed than that provided during ede-new and
ede-new-target?

cheers
sascha
-- 
Sascha Wilde
"Structure is _nothing_ if it is all you got.  Skeletons _spook_ people if
 thwy try to walk around on their own.  I really wonder why XML does
 not."            -- Erik Naggum <erik@naggum.net> in comp.lang.lisp

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

Re: CEDET merge

[Sascha Wilde]

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

Sascha Wilde <wilde@sha-bang.de> wrote:
> Now I get an different error on any attempt to rebuild a projects
> makefile (which afaiu is also a part of compiling).  From *Messages*:
>
> Replace EDE Makefile
> Compiling template default.srt...
> 0 templates compiled for nil
> srecode-compile-templates: You must specify a MODE for your templates

With the latest changes to the CEDET integration this problem vanished,
too.  Now Makefile generation by EDE basically works.

However I still witness a bunch problems with my simple test cases.

Is it useful to report them here or should I wait for the CEDET
integration process to become more complete?

cheers
sascha
-- 
Sascha Wilde : "Ist es nicht schon schlimm genug, dass ICH hier rumtrolle?"
             : (Henning Leise in d.o.c.)

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

Re: CEDET merge

[Chong Yidong]

Sascha Wilde <wilde@sha-bang.de> writes:

> With the latest changes to the CEDET integration this problem vanished,
> too.  Now Makefile generation by EDE basically works.
>
> However I still witness a bunch problems with my simple test cases.
>
> Is it useful to report them here or should I wait for the CEDET
> integration process to become more complete?

Please, report them here.

Re: CEDET merge

[Chong Yidong]

"Eric M. Ludlam" <eric@siege-engine.com> writes:

> Short term, you could get the templates from CEDET CVS in
> cedet/srecode/templates and cedet/ede/templates and place them in
> equivalent locations just under srecode.el and ede.el to get past this
> until there is a home for SRecode Templates in Emacs.

I've added the SRecode templates to etc/srecode.

Building in EDE should now work---provided Semantic is enabled from the
start.  We still need to provide a way for SRecode to call Semantic to
parse the template buffer, when Semantic is not currently enabled (this
functionality will be useful for other parts of Emacs too).

Re: CEDET merge

[Eric M. Ludlam]

On Sat, 2009-10-03 at 16:10 -0400, Chong Yidong wrote:
> "Eric M. Ludlam" <eric@siege-engine.com> writes:
> 
> > Short term, you could get the templates from CEDET CVS in
> > cedet/srecode/templates and cedet/ede/templates and place them in
> > equivalent locations just under srecode.el and ede.el to get past this
> > until there is a home for SRecode Templates in Emacs.
> 
> I've added the SRecode templates to etc/srecode.
> 
> Building in EDE should now work---provided Semantic is enabled from the
> start.  We still need to provide a way for SRecode to call Semantic to
> parse the template buffer, when Semantic is not currently enabled (this
> functionality will be useful for other parts of Emacs too).

Semantic can parse files even if all the other related utilities are
never enabled.  As long as srecode-template-mode sets up the parser info
itself, and not in the new "semantic-mode", then it can use the Semantic
API to parse buffers during template compilation without interfering
with someones desire to not enable Semantic parsing and utilities in
other files, like C++ mode.

Eric

Re: CEDET merge

[Chong Yidong]

"Eric M. Ludlam" <eric@siege-engine.com> writes:

>> Building in EDE should now work---provided Semantic is enabled from the
>> start.  We still need to provide a way for SRecode to call Semantic to
>> parse the template buffer, when Semantic is not currently enabled (this
>> functionality will be useful for other parts of Emacs too).
>
> Semantic can parse files even if all the other related utilities are
> never enabled.  As long as srecode-template-mode sets up the parser info
> itself, and not in the new "semantic-mode", then it can use the Semantic
> API to parse buffers during template compilation without interfering
> with someones desire to not enable Semantic parsing and utilities in
> other files, like C++ mode.

How about this:

In the Emacs-integrated version of Semantic, we semantic-new-buffer-fcn
so that it runs the mode-dependent parser setup functions before doing
anything else.  This is as opposed to running the parser setup functions
from the mode-hooks, as your upstream code does, or in the body of
semantic-mode, as the Emacs version currently does.  So, when srecode
calls semantic-new-buffer-fcn, the right setup will take place.

What do you think?

Re: CEDET merge

[Eric M. Ludlam]

On Sat, 2009-10-03 at 21:44 -0400, Chong Yidong wrote:
> "Eric M. Ludlam" <eric@siege-engine.com> writes:
> 
> >> Building in EDE should now work---provided Semantic is enabled from the
> >> start.  We still need to provide a way for SRecode to call Semantic to
> >> parse the template buffer, when Semantic is not currently enabled (this
> >> functionality will be useful for other parts of Emacs too).
> >
> > Semantic can parse files even if all the other related utilities are
> > never enabled.  As long as srecode-template-mode sets up the parser info
> > itself, and not in the new "semantic-mode", then it can use the Semantic
> > API to parse buffers during template compilation without interfering
> > with someones desire to not enable Semantic parsing and utilities in
> > other files, like C++ mode.
> 
> How about this:
> 
> In the Emacs-integrated version of Semantic, we semantic-new-buffer-fcn
> so that it runs the mode-dependent parser setup functions before doing
> anything else.  This is as opposed to running the parser setup functions
> from the mode-hooks, as your upstream code does, or in the body of
> semantic-mode, as the Emacs version currently does.  So, when srecode
> calls semantic-new-buffer-fcn, the right setup will take place.
> 
> What do you think?

I think I have failed to understand the above.

Does the Emacs integrated CEDET no longer use mode-local to call
semantic-new-buffer-fcn?  That could be good news.  The hooks available
in Emacs to detect a change in major mode for mode-local.el have been
challenging to get right, and I think they can still sometimes not work
right.

I did fail to explain in my paragraph above that mode-local.el would
need to be active for any files to be parse-able.  I was referring to
semanticdb, and semantic-idle features do not need to be enabled for
SRecode to be able to parse/compile template files.  As you point out,
the semantic-new-buffer-fcn does need to run, and the mode-local
settings need to be active for semantic to parse stuff.

Is there a desire to have srecode parse/compile template files while
leaving mode-local inactive?  Does mode-local get activated with
semantic-mode?  Perhaps I should check out a fresh copy of 
Emacs to better understand.  I've been worried of doing so because I
know I'll then need to also figure out how to enable my CEDET distro
shadowing the Emacs version, and I don't really want to do that work.

Eric

Re: CEDET merge

[Chong Yidong]

"Eric M. Ludlam" <eric@siege-engine.com> writes:

> Does the Emacs integrated CEDET no longer use mode-local to call
> semantic-new-buffer-fcn?  That could be good news.  The hooks available
> in Emacs to detect a change in major mode for mode-local.el have been
> challenging to get right, and I think they can still sometimes not work
> right.

No, semantic-new-buffer-fcn is still called from mode-local.  I was
proposing to move the parser setup functions from the mode hooks into
semantic-new-buffer-fcn.  That way, we can parse an existing buffer
(e.g., a buffer that already exists by the time Semantic is enabled, or
a buffer that Srecode wants to parse without enabling Semantic
globally), simply by calling semantic-new-buffer-fcn.

Re: CEDET merge

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
> Currently, the interface to Semantic is via "M-x semantic-mode", and to
> EDE via "M-x global-ede-mode"; these should install a "Development" menu
> on the menu bar that can be used to enable further features.
> Suggestions about improving this interface, and the CEDET integration in
> general, are welcome.

(1)
"M-x semantic-mode" works, but if I do "M-x global-ede-mode", I get the
following error:

   Cannot open load file: ede/makefile-edit

If there are already source-file buffers when I do M-x global-ede-mode,
then I the error immediately, otherwise, it happens when I visit a
source file or directory.

I tried "make bootstrap" etc, with no improvement.

(2)
I get the following error with semantic-mode:

   (a) visit the following source file:

---- cut here ----
#include <stdio.h>

int main ()
{
  printf ("hello world\n");
  return 0;
}
---- cut here ----

   (b) do M-x semantic-mode

   (c) position point after "printf"

   (d) use the command: "C-c , j"
       (I don't even know what that command does, but it gets an error...)

   (e) I get the following error/backtrace:

Debugger entered--Lisp error: (wrong-type-argument syntax-table-p nil)          
  set-syntax-table(nil)                                                         
  semantic-ctxt-current-symbol-default(nil)                                     
  semantic-ctxt-current-symbol()                                                
  semantic-ctxt-current-thing()                                                 
  semantic-complete-default-to-tag(nil)                                         
  semantic-complete-read-tag-engine([object semantic-collector-buffer-deep "Sym$
  semantic-complete-read-tag-buffer-deep("Symbol: ")                            
  semantic-complete-jump-local()                                                
  call-interactively(semantic-complete-jump-local nil nil)                      

-miles

-- 
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

Re: CEDET merge

[Eric M. Ludlam]

On Thu, 2009-10-01 at 12:58 +0900, Miles Bader wrote:
> Chong Yidong <cyd@stupidchicken.com> writes:
> (2)
> I get the following error with semantic-mode:
> 
>    (a) visit the following source file:
> 
> ---- cut here ----
> #include <stdio.h>
> 
> int main ()
> {
>   printf ("hello world\n");
>   return 0;
> }
> ---- cut here ----
> 
>    (b) do M-x semantic-mode
> 
>    (c) position point after "printf"
> 
>    (d) use the command: "C-c , j"
>        (I don't even know what that command does, but it gets an error...)
> 
>    (e) I get the following error/backtrace:
> 
> Debugger entered--Lisp error: (wrong-type-argument syntax-table-p nil)          
>   set-syntax-table(nil)                                                         
>   semantic-ctxt-current-symbol-default(nil)                                     
>   semantic-ctxt-current-symbol()                                                
>   semantic-ctxt-current-thing()                                                 
>   semantic-complete-default-to-tag(nil)                                         
>   semantic-complete-read-tag-engine([object semantic-collector-buffer-deep "Sym$
>   semantic-complete-read-tag-buffer-deep("Symbol: ")                            
>   semantic-complete-jump-local()                                                
>   call-interactively(semantic-complete-jump-local nil nil)                      

I haven't had the opportunity to use the Emacs/CEDET merged version, but
I can provide some help here.  The Semantic configuration was setup to
be done in a .emacs file, or very early on, and all the necessary setup
is done in mode hooks after that.  If you load in a C file, then turn on
Semantic, then your current buffer will not have the right variables
setup.  In this case, it is a variable that tweaks the syntax table.

I think the right order would be

M-x semantic-mode

;; create the file

continue with above script.

I would guess that the new semantic-mode should either warn on
pre-existing buffers, or find a way to apply itself to pre-existing
buffers.  The standalone CEDET install works around this by the file
that loads CEDET doing these installs in your .emacs file.  The
assumption being that if you installed CEDET, you want this stuff on,
which is not the case for Emacs.

Eric

Re: CEDET merge

[Chong Yidong]

"Eric M. Ludlam" <eric@siege-engine.com> writes:

> I would guess that the new semantic-mode should either warn on
> pre-existing buffers, or find a way to apply itself to pre-existing
> buffers.

This should be easy to implement, but I have not had time to do it yet.

Re: CEDET merge

[Phil Hagelberg]

Chong Yidong <cyd@stupidchicken.com> writes:

> I have merged most of the CEDET branch into the trunk.  You may need to
> bootstrap; please let me know if there are any build failures.
>
> I have done what I can to clean up CEDET to conform to Emacs standards;
> if you see anything I missed, please go ahead and make the change.

The doc header at the top of pulse.el mentions the function
pulse-enable-integration-advice, which has been removed presumably to
conform to Emacs "no advice in core" standard. But the comment has not
been updated.

The patch below fixes this.

-Phil

diff --git a/lisp/cedet/pulse.el b/lisp/cedet/pulse.el
index c7ece45..7977104 100644
--- a/lisp/cedet/pulse.el
+++ b/lisp/cedet/pulse.el
@@ -27,11 +27,6 @@
 ;; highlighted briefly.  This adds a gentle pulsing style to the text
 ;; decorated this way.
 ;;
-;; Useful user functions:
-;;
-;; `pulse-enable-integration-advice' - Turn on advice to make various
-;;      Emacs commands pulse, such as `goto-line', or `find-tag'.
-;;
 ;; The following are useful entry points:
 ;;
 ;; `pulse' - Cause `pulse-highlight-face' to shift toward background color.

Re: CEDET merge

[Chong Yidong]

> The doc header at the top of pulse.el mentions the function
> pulse-enable-integration-advice, which has been removed presumably to
> conform to Emacs "no advice in core" standard. But the comment has not
> been updated.
>
> The patch below fixes this.

Thanks, applied.

Re: CEDET merge

[Eric M. Ludlam]

On Wed, 2009-10-07 at 01:37 -0400, Chong Yidong wrote:
> > The doc header at the top of pulse.el mentions the function
> > pulse-enable-integration-advice, which has been removed presumably to
> > conform to Emacs "no advice in core" standard. But the comment has not
> > been updated.
> >
> > The patch below fixes this.
> 
> Thanks, applied.
> 

While the feature specified which allows fcns such as goto-line to do a
pulse after the line has been gone to is certainly superfluous (I don't
use them), what would be he recommended way to make it possible to make
such changes w/out using advice?

I recognize that `beginning-of-defun' and friends discussed earlier
would be the model, but I can't imagine adding such replacement features
into every user facing command just in case.

For the pulse case, is there an interest in snazzing up the original
function list with pulsing, or is it too gratuitous to even contemplate?

Eric