Thanks for looking into that. Chong Y. was investigating if it was time
to merge from the CEDET branch into Emacs, as the Emacs code is from a
pre-CEDET-1.0 release of our code so it is quite out of date. It may be
that the merge will bring a fix over into Emacs.
I don't know what the timeline for when that would be though. The exact
mechanics of how to merge were being discussed last week. Is such a
merge something you would want to help with?
On 06/10/2012 11:46 PM, Pierre Lorenzon wrote:
> OK Eric,
> I made an interesting test i.e. running cedet-1.1 (downloaded
> from sourceforge version of apr 15,) with emacs 24.1.50. The
> depth limitation for directories seems to disappear in this
> case. So it seems clear to me that the problem lies in the
> cedet code embedded in emaccs 24.1.50. If I can discover where
> exactely these two code are different (I don't speak about
> organisation of the code in various files but the code itself
> !) I will probably be able to fix this bug.
> From: "Eric M. Ludlam"<ericludlam@...>
> Subject: Re: [CEDET-devel] project not loaded
> Date: Sun, 10 Jun 2012 11:25:23 -0400
>> Hi Pierre,
>> Are you using the EDE that comes with Emacs, or have you used
>> the latest version from CEDET? The version numbers you list
>> makes me think the former.
>> Emacs changed EDE to account for a security issue, and it may
>> be the checks it is making is causing the problem. For
>> example, if you set:
>> (setq ede-project-directories t)
>> does it magically work?
>> For EDE in the CEDET repository, the CEDET project itself is 3
>> levels deep, so it is working here.
>> The existing EDE automated tests only digs down 2 levels in its
>> test suite. When I go to work on this bug, I will probably
>> start by updating the test suite first, and as such it may be a
>> while before I get to it.
>> On 06/07/2012 05:57 AM, Pierre Lorenzon wrote:
>>> I am currently testing emacs 220.127.116.11 and in particular ede. I
>>> encounter following problem : project is not loaded if
>>> subdirectory is deeper than 2.
>>> Creating directory ~/A in it a file ~/A/A.el invoking ede-new
>>> at this stage create a project and C-c . T allows to add A.el
>>> to an arbitrary target. When invoking ede-customize-project
>>> customize buffer is displayed and everything work well.
>>> So I create a directory ~/A/B/ a file B.el in it and all
>>> operations described above can be performed successfully.
>>> I create ~/A/B/C/ directory and a file C.el in it. I can create
>>> a project in ~/A/B/C/ directory by issuing ede-new. I get the
>>> message saying that project has been created and that I can now
>>> create targets but IN FACT I CANNOT ! When issuing C-c . T in
>>> file C.el I enter Bactrace. When trying to customize the
>>> project,I get following Backtrace buffer :
>>>>>> -- Backtrace
>>> Debugger entered--Lisp error: (wrong-type-argument (or
>>> eieio-object-p class-p) nil)
>>> signal(wrong-type-argument ((or eieio-object-p class-p) nil))
>>> eieio-oref(nil local-variables)
>>> call-interactively(ede-customize-project record nil)
>>> command-execute(ede-customize-project record)
>>> execute-extended-command(nil "ede-customize-project")
>>> call-interactively(execute-extended-command nil nil)
>>>>>> -- End Backtrace
>>> I did not encounter this problem with emacs 18.104.22.168 but
>>> already with 24..0.95. I noticed that implementation of
>>> ede-minor-mode is different in 22.214.171.124 and 126.96.36.199 but I
>>> could not determine where the problem comes from.
>>> Should I report this also as emacs bug with the M-x
>>> report-emacs-bug ?
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security
>>> threat landscape has changed and how IT managers can
>>> respond. Discussions
>>> will include endpoint security, mobile security and the latest
>>> in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> Cedet-devel mailing list