search

asciidoctor / atom-language-asciidoc

⚛ AsciiDoc language package for the Atom editor.
https://atom.io/packages/language-asciidoc
MIT License
42 stars 20 forks source link

feat: migrate autocomplete #137

Closed ldez closed 8 years ago

ldez commented 8 years ago

Fix #133, #44

Fix asciidoctor/atom-asciidoc-preview#130 Fix asciidoctor/atom-asciidoc-preview#131

nicorikken commented 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.

ldez commented 8 years ago

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:

wdyt?

nicorikken commented 8 years ago

@ldez two remarks on your proposal:

  1. We then need to have scope names coordinated across repo's/packages.
  2. Would you consider snippets to be part of the 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?

mojavelinux commented 8 years ago

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.

ldez commented 8 years ago

'autocomplete' is the convention for Atom package.

I can create a system to auto-download packages.

ldez commented 8 years ago

I thought about and atom-asciidoc-assistant is a good name :+1:

nicorikken commented 8 years ago

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.

ldez commented 8 years ago

I agree with @nicorikken and I propose:

wdyt?

ldez commented 8 years ago

I'm ready! I have created (in local) the autocomplete-asciidoc package.

@mojavelinux @nicorikken Tell me what I should do?

mojavelinux commented 8 years ago

@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).

mojavelinux commented 8 years ago

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.

ldez commented 8 years ago

The naming standards already exists:

Create a custom naming standards seems to not be necessary.

mojavelinux commented 8 years ago

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.

ldez commented 8 years ago

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?

mojavelinux commented 8 years ago

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.

ldez commented 8 years ago

I transferred my repository but I don't have admin access...

capture du 2016-05-24 10-21-01

And the 'atom-package-committers' team doesn't have access.

@mojavelinux can you help me?

mojavelinux commented 8 years ago

Here I come to save the day!!

giphy

mojavelinux commented 8 years ago

All set!