Closed ldez closed 8 years ago
Nice work 👍 What was I thinking, expecting you to do a simple copy-and-paste 😉
I haven't really used the auto-completion with intent, but the copy looks good and feature-complete. If I understand correctly the suggestions are now bound to attribute-reference {...}
. Moving to CSON parser, and introducing better scoping looks good.
Now that I have working on this feature, I think it's probably a better idea to make a specific package for auto-complete like others languages.
Possible package name:
atom-asciidoc-autocomplete
(my favorite)atom-asciidoc-writer
atom-asciidoc-assist
wdyt?
@ldez two remarks on your proposal:
language
or the autocomplete
package?To me this ultimately seems to be a matter of preference between many small or few large packages. What I like about introducing many small packages in this specific case, that the backing of the Asciidoctor 'brand' will help to enforce packages working together nicely. So in this case I do agree that a multi-package strategy can be pulled off. Apart from subjective preference, introducing smaller packages eases the reuse of other packages, say from Markdown. Multiple ways to solve the same problem can be explored, and there is lower risk that imported packages will have to be restructured to fit into already existing (then larger) Asciidoctor packages. For example the image helper would have to be adjusted to fit into the language package. @mojavelinux Any project-wide guidance here?
I do like the idea of packages that do one thing and do it well (the Unix philosophy). Given that we're working under the same umbrella, I'm not too concerned about having to coordinate between them. What I am concerned about is that it makes life more complicated for the novice user who has to install each one individually.
Another idea for a combined autocomplete / snippets package name would be:
We could also use this as a root package name:
(but maybe that's going too far)
To me, "autocomplete" is not descriptive enough, esp for writers. We know what it means because that's the term we use in the code, but to a less technical person, it doesn't mean much.
'autocomplete' is the convention for Atom package.
I can create a system to auto-download packages.
I thought about and atom-asciidoc-assistant
is a good name :+1:
Autocomplete is indeed adhering to the current Atom universe. I prefer that option for the specific auto-completion options, with a very explanatory one-liner description of course. But I can see having a namespace for a generic package. In terms of implementation, maybe the ide-haskell package can of an example. It clearly states the underlying package requirements to function properly, but no dependency resolving unfortunately.
I agree with @nicorikken and I propose:
autocomplete-asciidoc
package with some snippets and auto-completeasciidoc-assistant
package to related all AsciiDoc toolswdyt?
I'm ready! I have created (in local) the autocomplete-asciidoc
package.
@mojavelinux @nicorikken Tell me what I should do?
@ldez You should now be able to move a repository into the Asciidoctor organization. I'll then add it to the atom-package-maintainers team and that will grant you admin privileges. As admin, you should also be able to manage the CI job. (I'm looking forward to the day when the same is true for AppVeyor jobs).
I wonder if the preview package should be renamed to atom-preview-asciidoc (or the autocomplete should be atom-asciidoc-autocomplete). We should probably decide on naming standards so that we end up with consistent package names.
The naming standards already exists:
Create a custom naming standards seems to not be necessary.
I would say that a standard exists from those results. What I see is a lack of a standard. Specifically, I'm talking about the ordering (not the terminology). When does asciidoc come first and when does it come second. We should decide on a pattern and try to stick with it as we grow the number of packages.
We can use packages provided by Atom's team as standard?
I understand the ordering problem (if you see my initial message the ordering of the package name is different). :wink:
Rename a package (asciidoc-preview
) implies that users can have the same package 2 times. :-1:
I think we can defined naming standards for the next packages.
I propose asciidoc-xxxxx
wdyt?
When the package plugs into another framework, then I think we should use the following pattern:
atom-%framework%-asciidoc
When the package is adding new, original behavior, then we should use:
atom-asciidoc-%behavior%
I know that we end up with two different orderings, but at least it's for a well-specified reason.
I transferred my repository but I don't have admin access...
And the 'atom-package-committers' team doesn't have access.
@mojavelinux can you help me?
Here I come to save the day!!
All set!
fs-plus
andJSON.parse
loadCompletions
become asynclodash
instead ofunderscore-plus
Fix #133, #44
Fix asciidoctor/atom-asciidoc-preview#130 Fix asciidoctor/atom-asciidoc-preview#131