I'm opening this issue to gauge the community's interest in a Atom plugin with advanced features that may include the following:
The more developers that are interested will help us make a stronger case for investing in this functionality.
Related issues:
(I'll open a similar Github issue for Sublime Text and Visual Studio Code)
I've created a few prototypes:
Having a separate core project allows use to centralized set of layout templates for ui components, and later, entire projects. The core is generic and doesn't contain any logic related to atom, but contains the templates (see example here) and the logic needed to copy them to any destination path.
The atom project contains all the logic needed to surface the proper menu items, etc, and has the core project as a dependency (not implemented yet, need to npm publish).
Curious what everyone thinks of this approach, I think the core library starts to allow us to branch into other frameworks like yeoman, sublime, etc.
Hey @BryceEWatson, thanks for working on the generator/scaffolding functionality. I like the setup, but I think we need to offer more flexibility and possibly provide the ability for the developer to provide their own "component template directories". As an example, not every developer is going to use .less. Also, I think we can simplify the code if we just provide a way to copy a directory tree while doing variable replacement (in files and in filenames, and possibly supporting conditional files as well).
As much as I dislike Yeoman, it might be worth providing Yeoman generators and piggy backing off atom-yeoman.
Another option is to build a new, generic "Generator" plugin for Atom (independent of Yeoman) and there also be "Generator Provider" plugins. We could then provide a Generator Provider plugin for Marko, but other developers could publish their own. It's possible that something like this already exists, but I haven't seen it.
Thoughts?
@patrick-steele-idem Good points. I agree that the prototype is too rigid in enforcing .less, etc. Maybe we could add an option (to both core & atom projects?) to save a new template directory. The option could be surfaced in the atom in the right click menu, allowing the user to right click a module and select "Save as template". I'm not sure how simple this would be in practice, as dynamic data for module name would need to be included.
Also, yes I avoided yeoman this time. The last time we went down the yeoman path it became very tightly coupled to the framework. It's worth exploring a generic solution that uses atom-yeoman instead of ejs.
I also like the generic Generator option. This goes beyond simple marko support, and might overlap with some existing solutions. Will need to research this further.
Thanks for the feedback!
I think it would be nice to make something like https://github.com/dsandstrom/atom-double-tag and highlight of closing tags for marko.
@Eldar-X I took on the challenge and we now have support for tag matching and synchronized editing of opening and closing tags in Atom: https://github.com/marko-js/atom-language-marko#tag-matching
There was some learning along the way, but it was a much more difficult task than expected (lots of edge cases), but I am very happy with the end result. You owe me a beer :)
As a side note, we have merged all of the Atom plugins (atom-language-marko, atom-autocomplete-marko and atom-hyperclick-marko) into the main atom-language-marko package. The other packages are now deprecated and they were made into no-ops (feel free to uninstall autocomplete-marko and `hyperclick-marko).
Please let us know if you see any issues.
@patrick-steele-idem thank very much now i am happy like a child :) for this features even vodka is not enough! Also i see some colors in syntax highlighting are changed for example < > and now it's much better. Good job!
Didn't find such issue for Visual Studio Code, do you have any plans for it?
@tinovyatkin, Patrick and I are not planning on picking up a VS Code plugin in the near future, but @pcanella mentioned he might be interested in working on one.
@tinovyatkin I did take a look into what it would support autocomplete with VS Code and it wasn't too bad. The main difference between VS Code and Atom is that the autocomplete functionality is required to be provided as a separate process. But as @mlrawlings said, we don't plan on working that in the near future. At the moment we are busy preparing for the next major release of marko (development is happening on master).
@mlrawlings oh no what did I commit to ;)
Closing this as most features have been implemented. Moving forward, we'd like to explore a Language Server (#859).
Most helpful comment
@Eldar-X I took on the challenge and we now have support for tag matching and synchronized editing of opening and closing tags in Atom: https://github.com/marko-js/atom-language-marko#tag-matching
There was some learning along the way, but it was a much more difficult task than expected (lots of edge cases), but I am very happy with the end result. You owe me a beer :)
As a side note, we have merged all of the Atom plugins (atom-language-marko, atom-autocomplete-marko and atom-hyperclick-marko) into the main atom-language-marko package. The other packages are now deprecated and they were made into no-ops (feel free to uninstall
autocomplete-markoand `hyperclick-marko).Please let us know if you see any issues.