Re: EDE documentation

Eric Ludlam <[email protected]> writes:

> On 08/08/2015 05:59 PM, Stephen Leake wrote:
>
> I finally got an emacs 25 going, and noticed the same problem when you
> first posted about it.  My intent is to make Emacs core more like what
> is in Source Forge.

Ok, that makes sense.

>
> Yes.  EIEIO changed a lot in Emacs 25, and David and I seemed to both
> be busy around the same time and couldn't keep up.  ;)

Ok. I can help; let me know what would be best to work on.

It definitely makes sense to improve EDE, rather than re-implementing a
lot of the same stuff in project-*.

>>      In addition, there's a problem with the Arduino auto-detect on
>>      Windows; the sketchbook directory has \ in preferences.txt, but it
>>      is compared to buffer-file-name, which has /. So ede/auto.el
>>      ede-do-dirmatch needs an 'expand-file-name' in (setq matchstring
>>      ...). I didn't actually edit the code and test, because I'm not sure
>>      that change is ok in general.
>
> Expanding the file seams reasonable since most tests are just
> (file-exists-p) which is vaguely similar.
>
> I did this and it passed all my tests on Linux.

Ok. I'll see if I can run tests on Windows.

How do you run the tests?

'make test' in cedet/Makefile says "no target test". Same for "tests".
There are a couple utest-* and several itest-*; do you just run each?

Ah; there's a tests/Makefile with an 'all' target. That gives an error
for recursive require for speedbar. Maybe I need to pull.

>>      It would be good if there were a menu item that displayed a list of
>>      the project types currently auto-detected. That is simple to extract
>>      from ede-project-class-files.
>>
>>      Then this section can say:
>>
>>      "To see the list of supported generic projects, invoke the menu
>>      Development | Project Options | Show auto-detects"
>>
>>      I don't have examples of all of the project types listed, so I
>>      couldn't test all of them.
>
> You can do:
>
> C-h v ede-project-class-files RET
>
> but i get your meaning.  Lisp struct dump isn't so helpful.  

And finding a menu item is far easier than finding the name of that
variable. 

> Here's a
> handy way to explore:
>
> (defun ede-show-supported-projects ()
>   "Display all the project types registered with EDE."
>   (interactive)
>   (data-debug-new-buffer (concat "*EDE Autodetect*"))
>   (data-debug-insert-stuff-list ede-project-class-files "* "))

That dies with "Symbol's function definition is void:
semanticdb-find-results-p". Apparently there's a missing autoload somewhere.

>>      When I restarted Emacs (I had some edebug stuff that just broke),
>>      the new project was not automatically recognized. I think I know
>>      why, but the info did not say anything about that. So I tried
>>      Development | Load Project, and Emacs crashed.
>>
>>      More later, after I debug that crash.
>
> I didn't updated these sections, and it seems like some of the
> workflow is a bit broken.   I pushed a ton of workflow testing into
> CEDET's interactive test suite, so I know it works, but that tests
> commands, not the menus.  It seems like some interactive
> testing/debugging is needed.

Yes. Testing a GUI is a pain. I have tried to automate that on other
projects (non-Emacs), and it's still a pain :).

>> - 10 Misc
>>
>>      ede-find-file does not do completion on the file name. I looked at
>>      the code; it looks complicated, because of the locate objects. Emacs
>>      has very nice file name completion now, so it would be good to
>>      improve this. The Emacs filename completion takes a flat list of
>>      directories (like load-path or compilation-search-path), so we'd
>>      have to construct that out of all the locate objects. I'll look into
>>      it more.
>
> The location system is pretty old and it delegates to external tools.
> Newer systems like what you suggest I'm sure would be better.
>
> All the objects do is abstract away the different tools so EDE can ask
> where some file is.  Most usage of this is not related to users asking
> to visit a file, but for a tool to move to a file based on a
> short-name reference, so completion was never a priority for me.

So do you plan on rewriting the location stuff, or should I work on
extracting a completion path?

If there are external tools involved, they must have their own notion of
source-path, so we might need a new query to ask for that, rather than
expanded file names.

I assume it's ok to add completion to this, or perhaps add a similar
function that does completion.

> Thanks for all the feedback.

You're welcome

-- 
-- Stephe

------------------------------------------------------------------------------