Question about suitability of a problem to package development


#1

Hi,

I work with certain type of binary files, which are not human-readable, but a human-readable representation can be created using command-line tools provided by a number of third-party libraries (there is a command-line binaries, and there is a python package for that). I often need to examine that human-readable representation, search for certain components and such. Up to now, I’ve been doing this by parsing the files in the terminal and scrolling/grepping in the terminal.

Is this the kind of problem that justifies development of an Atom package?

Is it possible to have a package that provides a read-only “view” representation of a document?

Is it possible to run command-line preprocessors and route the output?

Is it possible to write packages in python, or use functionality implemented in python?

Is there a package with functionality similar to what I am thinking to do so I can learn?

Looking forward to your replies!

AF


#2

To answer your questions:

  1. In my opinion, yes. Others may disagree, though doubtful.
  2. Yes. For example, see: hex and markdown-preview, among others.
  3. Yes. See the documentation on the BufferedProcess class.
  4. Multi-part question:
    1. No. Or at least not without herculean effort.
    2. Yes. See the answer to #3 above.
  5. See the answer to #2 above.

#3

Very cool, thanks a lot! Good luck to me then! :wink:


#4

Yea I think that’s a prime example for a useful Atom package, even though it’s not strictly an Editor problem you’re trying to fix (unless you plan on doing any operations on those files?).

Next to the Markdown Preview package, there is also the more ambitious and generalized Preview package that does the same for a lot more file formats.


#5

I have found several uses of Atom that aren’t actually editing. Viewing large-files read-only, browsing the web, etc. I find it nice to have them integrated and also to be customizable to my heart’s content. Atom is almost a platform or OS, like chrome in a chromebook.


#6

One issue I see with the hex example is that the view is not searchable.

Is this just a missing feature, or these static views cannot be searched period? This is a very important feature for me.


#7

Yes, but the search will have to be coded in the package. Should be easy.


#8

Well, yes, it would be cool if I could edit the human-readable form and write back into binary, but that’s sometime down the road, with a big maybe, because I think it is a lot more work.

Thanks for all the replies! It is very encouraging to see that the community is active and supportive! Another reason to give this experiment a try.


#9

I finally got down to this and made some progress! Yes, starting from hex package it was not too difficult, main issues were related to confusion about coffescript notation.

I have few more follow up questions, as I develop this further (please let me know if I should post in a separate thread):

  1. my package is using a command line executable that needs to be installed on the system; what is the recommended way to configure my package by the user to point to the location of that executable?
  2. is it possible to automatically on file open check if the file is of certain kind, and if yes - prompt the user to apply my package?
  3. the “views” generated by my package would benefit from folding of the nested structures; where do I start from to get an idea how to do folding?

#10

Personally, I like an explanation in the README.md, preferably with a download link or simple install instructions to get the executable installed. A simple setting with a recap in the description field should then be sufficient to point the user in the right direction. I do the following with a simple LaTeX package:

You can subscribe to the setting and store the value for example in @command. Simply pass @command to the BufferedProcess to run your executable. Example code:

packageName: require('../package.json').name

activate: ->
  @disposables = new CompositeDisposable
  ...
  @disposables.add atom.config.observe "#{@packageName}.command", =>
    @command = atom.config.get "#{@packageName}.command"
  ...

You can subscribe to any future text editor and check the grammar. If it has the correct grammar kick off your package, otherwise do nothing. Example code:

activate: ->
  ...
  @disposables.add = atom.workspace.observeTextEditors (editor) ->
    if editor.getGrammar() is atom.grammars.myGrammar
      # kick off my package that does something for `myGrammar`
  ...

Can’t answer your views question, hopefully someone else can fill you in there.


#11

@Alchiadus thanks a lot for your response! This looks (I have not tried these things yet) very helpful.


#12

Just wanted to let everyone who helped me here that I’ve just published this package

Thanks all for the help and encouragements! You made this possible :+1:

I will be asking more questions as I develop this further and add new features, but probably in separate threads.