Ability to add custom providers

[dan-weaver]

I realize narrow isn't supposed to an "open anything type of framework" but it seems reasonable that given any result set containing text and line number / file data I should be able to "plug" it in to narrow. Is there anything like that available (like an api / service). If not is that something you would consider?

[t9md]

I once intentionally stopped to provide service to plug custom-provider. The reason is I want change narrow freely, rapidly. but now I'm thinking to open service for custom-provider, providing it is easy, so will come soon. Why I changed my mind is narrow's architectual design getting to be setttled, and I want to remove some of built-in provider I wont use, so give a chance to recover that removed provider via custom-provider if they want. Providers such as linter, bookmarks, git-diff(not git-diff-all) is what will be removed in future.

Btw next version of narrow:search, you can edit search term as first query of narrow-editor like scan provider. It's great, you can send cursor word to existing narrow-edito's query area wich trigger refresh items with sent new query.

[t9md]

Humm, I have two different feeling to support this.

• Part of me saying, yes support external provider via narrow service.
• Part of me saying, stop I keep narrow change freely without concerning breaking external provider.

Currently I'm inclining to later(stop) feeling.

[dan-weaver]

I Haven't done a super in depth investigation of how narrow works. But I thought a simple API (perhaps even 1 method) which returns an array of results in a narrow-friendly format would suffice right? The narrow-friendly format needing to be changed I suppose is the area of risk your trying to avoid.

I find narrow so useful in it's current form but let me explain the use case I am after that prompted this to begin with. I mostly use the fuzzy-grep package to explore the projects when looking for specific key words instead of narrow.. Too me narrow is more about working with the results once you have them. I suspect other packages out there may produce similarly useful results. Of course, fuzzy-grep doesn't expose any public API yet either, as I point out here: https://github.com/geksilla/atom-fuzzy-grep/issues/42, but seems like narrow could be cautiously opened to a plethora of use cases given certain constraints on what it's "allowed" to receive as a result set. Anyway, just my two cents.. Still will be a happy narrow user without this feature for now :).

[lettertwo]

I recently investigated creating a custom provider from nuclide diagnostics to narrow (similar in spirit to the existing linter provider). I'd love to see support for custom providers!

[t9md]

Ok, will try soon. Want to see how narroe can be used for othe usecase.

[t9md]

did some experiment

Here is example

https://github.com/t9md/atom-narrow-example-provider https://github.com/t9md/atom-narrow-git-ls

• There is lots of boilerplate code, I took quicker/easy path.
• User can not extend via init.coffee, need dedicated atom-package since it's need dedicated atom.config.
• I myself don't need extensibility, and won't encourage to create custom-provider.
• This is just experiment to see what user want to do with custom-provider. Will remove whenever I want.

[t9md]

Released. Will keep open this issue. To collect feedback.

[dan-weaver]

yesss! thanks!

[dan-weaver]

Testing this out asap

[dan-weaver]

This is working nicely for my original use case.. Funny enough, I hadn't realized that narrow-search had been reimplemented the way stated here: https://github.com/t9md/atom-narrow/issues/184. So my original use case is sort of obsolete now :). I'm sure this will be a useful feature for others and for me in the future though. Happy to help you document this having gone through the effort of using it now.

[lettertwo]

@t9md thanks for releasing this! I've scraped a proof-of-concept together for a diagnostics provider: https://github.com/lettertwo/atom-narrow-provider-diagnostics. Your git-ls example was very helpful, thanks!

[t9md]

@lettertwo I checked it, really amazed by that, it's a bit like advanced provider(I mean not simple and easy one). Well done!!

Nuclide diagnostics have similar purpose to linter right? Then, diagnostics should have it's own UI and shortcut to navigate next/previous warning/error. In that case is narrow navigation is sill useful or superior to native diagnostics navigation?(I haven't tried either of nuclide-diagnostics nor your provider).

[t9md]

@dan-weaver

So my original use case is sort of obsolete now :). I'm sure this will be a useful feature for others and for me in the future though. Happy to help you document this having gone through the effort of using it now.

Let me clarify Are you saying previous behavior of search was good than latest one. CHANGELOG generally have detailed information for this update btw.

[lettertwo]

@t9md

Well done!!

wow, thanks! 😊

Nuclide diagnostics have similar purpose to linter right?

Yeah, this is true, though diagnostics has a more general scope than the linter does, as its providers can represent all sorts of things. Right now, it's just linting and flow type errors, but in the future there could be providers for other things, like failing tests, merge conflicts... (just dreaming about these 😄 ).

Then, diagnostics should have it's own UI and shortcut to navigate next/previous warning/error.

Diagnostics does have it's own (very nice) UI, but it's a bit more 'read-only' than narrow. There are also commands to cycle through diagnostic messages, like "go to next diagnostic", etc.

In that case is narrow navigation is sill useful or superior to native diagnostics navigation?

Narrow gives the ability and potential to see more context around errors, and also to quickly focus in on particular errors or locations through filtering and keyboard navigation. Maybe in the future, it will even help with quickly fixing errors!

Thanks for checking out the provider, and for filing an issue! If you don't mind, i have some questions for you, which i'll put on that issue.

[dan-weaver]

@t9md yes I'm saying the narrow search functionality is superior to my hacked solution. I'm positive I will find other uses for this though. THanks again!

[dan-weaver]

@t9md sorry maybe the above is confusing.. the narrow search in the latest release is great and made my attempt at integrating fuzzy grep with narrow unneeded :)

[t9md]

OK!, yes I actually a bit confused, but now clear. Thanks for clarification and appreciation ❤️

[t9md]

I'm now rewriting this project from coffee to js #220. The purpose is just to learn JavaScript. I learned CoffeeScript before writing JavaScript, so I wanted to learn js properly. Manually rewriting to Js is good exercise to let me teach modern JavaScript.

One big impact for this is, ES6's class is not extendable by CoffeeScript's class. Current way to write custom-provider is by extending ProviderBase by custom class. So what this coffee to ES6 change means, custom-provider also must be defined by ES6's class(can not define custom-provider by CoffeeScript).

class ProviderBase {
}

class Child extends ProviderBase
# TypeError: Class constructor ProviderBase cannot be invoked without 'new'

This writing is no benefit for user, but custom-provider is still experimental, no custom-provider is written in coffeescript(except mine) so I'll go this direction.

[t9md]

@lettertwo In case your diagnostics narrow provider based on my git-ls example, consuming / awaiting narrow part can be greatly simplified. This is not related to coffee to js conversion, just refactoring I did on example. Check example provider if you want.

[dan-weaver]

@t9md Not sure if this is actionable any more, but it occurs to me this service may have been done backwards. For instance it should (possibly) be consuming services provided by narrow providers. see autocomplete for example https://github.com/atom/autocomplete-plus/blob/master/package.json#L29. Not sure what the advantages are to either approach, but thought i'd mention this if you were in the process of rewriting it. I'd love to help with the es6 rewrite if I can let me know!

[t9md]

Thanks, I,ve rewritten all code to ES6 already except test-spec.

I haven't do heavy work to support service, just quick and easy hack. So I think it worth to evaluate different approach you mentioned. Let custome-provider provideNarrowProvider rather than custom-provider consumeNarrow and register itself to narrow.

[slavaGanzin]

@dan-weaver Would you release your "open-anything" plugin?

[dan-weaver]

hey @slavaGanzin not sure what you're referring to.. I had started an integration between atom-fuzzy-grep and narrow, until I realized that a more recent update to the narrow search provider did exactly what I needed. Not much to release, but I was able to get the 2 packages "communicating". Are you interested in seeing that?

It's a pretty hacked up solution that includes forking fuzzy grep as well.

[dan-weaver]

You can see my changes to atom-fuzzy-grep here: https://github.com/dan-weaver/atom-fuzzy-grep/commit/f4a8e18bbb03f4e8c3d78ee6332359a75eea8f3d

and here's my attempt at integrating them in a narrow consumer: https://github.com/dan-weaver/fuzzy-grep-narrow/blob/master/lib/fuzzy-grep-narrow.js

disclaimer: I stopped when I proved to myself that I could get the results and put them into narrow, so there's some polish needed. Again, narrow search fulfills my needs in this case better than this integration would have, so I stopped, also just a warning since narrow was rewritten recently, not sure any of this works any more :)

[slavaGanzin]

@dan-weaver Thanks for sharing code.

[t9md]

272 will be big breaking change on how-to-write-custom-provider.

Anyone use your own custom provider? If so, want you to share a repository link.

[t9md]

This repo is example provider updated to work with latest narrow.

https://github.com/t9md/atom-narrow-git-ls