clemos
commented
10 years ago Hi Sven,
I took some time to test your changes. Haxelib features are great, though I think it would be better to display things like library info in a separate panel (like documentation, currently)
Unfortunately, the project stuff doesn't work on my end, and I get :
> check for existing project session on window
> no active project found in the window
>>> New haxe project reporting in
> find possible project files
> Did we find a single project to use?
> NO, no discernable project, here
Traceback (most recent call last):
File "/opt/sublime_text/sublime_plugin.py", line 303, in on_activated
callback.on_activated(v)
File "/home/clemos/.config/sublime-text-3/Packages/Haxe/HaxeComplete.py", line 735, in on_activated
return self.on_open_file( view )
File "/home/clemos/.config/sublime-text-3/Packages/Haxe/HaxeComplete.py", line 749, in on_open_file
HaxeProjects.determine_type()
File "/home/clemos/.config/sublime-text-3/Packages/Haxe/HaxeProjects.py", line 154, in determine_type
project = HaxeProjects.active_project()
File "/home/clemos/.config/sublime-text-3/Packages/Haxe/HaxeProjects.py", line 112, in active_project
sublime_proj["project"] = project.selected_project
AttributeError: 'NoneType' object has no attribute 'selected_project'I also fixed a typo : https://github.com/clemos/haxe-sublime-bundle/tree/sven
I must say IMHO HaxeProjects code already has some serious issues :
- too much Dictionaries... I think it's better, when possible, to use plain classes, so you know which 'keys' make sense
- I'm not sure at all about mixing 'our' settings logic with sublime's... I mean : if we need to describe different types of projects, I think it would be better to use our own format and extension (maybe plain json, actually) rather than .sublime-settings. When I said I thought it was a good idea to rely on ST settings, I meant for something like
'haxe_custom_build_command' : 'haxelib run nme project.nmml'or things like that, but not for storing bundle-specific data / config. Do you see what I mean ? - Generally, I think it's already too complex for what it's meant to do. I really believe we should try to start small, by cleaning / refactoring the existing feature (project/build selection, etc) and then eventually add the custom settings file on top of it.
- Lines like these
sublime_proj["project"] = project.selected_projectreally feel... bad.
I'm sorry of it sounds harsh or picky, but I believe you wanted me to be direct and to share thoughts, so I do. It's essential to me that the bundle remains as 'minimalistic' and comprehensible as possible. I'm not the king of good practices or of clean code, but I already feel really uncomfortable with the new project feature, so I prefer to tell you right away.
If you want, I think I can try to extract / isolate the current project / build selection routine from the current bundle, and refactor it a bit so you have something clean and working you can start playing with ? What do you think ?
...ctive from Sublime.