Atom message panel


#1

I have done some lint plugins for Atom now, and all of them has a repot panel at the bottom of the view. I was tired of every time I had a UI change I had to update all my lint plugins with the same code.

So now I have created a npm module with a simple API to handle all the UI for all of my plugins.

I Have made this repo public so if any1 of you like this idea of having the same message panel for all the plugins (in my view that will make a better user experience if all message panels look a like) you can just use it as an dependency or even contribute to the project so it can be made better for all of us!

Take a look at it on GitHub: tcarlsen/atom-message-panel


How can we help you write packages?
Atom-message-panel (a look back)
Creating a "header bar" view
#2

This is awesome. Absolutely something I would use.

A question; how do you feel about passing views into the .message() method? That would allow some customisation over the contents of each line without having to expand the API with a lot of methods.


#3

sound like a good idea. at the moment atom-message-panel only provide what I was in need of :stuck_out_tongue: and had in JSLint before.

I’m open to every good idea, and the more effective we can make this module the better


#4

I was actually looking into doing a general lint module (although I’m going through learning how node works and getting used to coffeescript atm).

While I like the idea of just a message box in the bottom and that you can jump to the line, have you considered something like Syntastic for VIM[0]?

The idea would be to highlight the line that there is an error/warning on, and then when the cursor is on that line, the message box would appear in the bottom with the lint info. The line highlighting could be done somewhat like how the git diff[1] plugin does, although in a way that differentiates it from that.

[0] https://github.com/scrooloose/syntastic

[1] https://github.com/atom/git-diff


#5

Personally I like to have the box showed all the time, and don’t have to “find” the line with the error and then highlight it to get the error. Maybe something in between. Had an idea of replacing the close button with a minimize button.

Then minimized it will so the first error or the error on that line you are at… What du you think of that?

PS. I am going to add a error indicator next to the line number. for sure!


#6

That actually sounds like a very good approach :slight_smile:


#7

Glad you like it :blush:


#8

I quite like how Xcode does both; it shows errors/warnings inline against each line and also in an secondary panel.


#9

This is a great idea, but shouldn’t it be extending an Atom View?


#10

what do you mean exactly? Its using atoms css classes and DOM structure, as described in Atom Styleguide.


#11

just added the ability to add css classes to the line numbers

append.lineIndicators(lines, className)

#12

Sorry I didn’t explain myself clearly. This is a great package, and I can see it getting widespread adoption because it fulfills a function that Atom is clearly lacking. As you said, it does successfully use Atom classes and structure, but the code and usage don’t.

Atom already has a well defined way to create DOM elements in the editor, through Views. Custom views that inherit an Atom View inherit some useful functions, but more importantly they follow the code standard defined the Atom docs. This means that it is easier for users down the line to quickly understand your code, and makes it far easier to customize and extend it for their own purposes.


#13

referring to this, I’m still not sure. You want me to rewrite it using SpacePen ??

I am using atom.workspaceView.prependToBottom()to inserting my panel and reusing the Atom classes available. If I’m still way of, please give me an example, wanna do this the right way. :smile:


#14

Yeah that’s basically what I mean.

I actually tried to convert it to coffee last night, here a gist. https://gist.github.com/nickclaw/9538654 It’s a little behind where your package is at now, but you can see what it would look like.

Now if you wanted to create the message panel you could do

var MessageView = require('atom-message-panel')

var panel = new MessageView({title: 'title'})
panel.attach()

#15

@Tehnix Just added the fold/unfold feature in version 0.3.0


#16

Oh hey, that’s similar to what’s in atom-script right now. Maybe we should just use yours as a dependency!


#17

I’ve done some changes in the way that the message-pane is structured, such that I think it’s more easily extended.
I’ve built on top of nickclaw’s CoffeeScript “port” and just changed each message-type to be it’s own View that can then be appended to the body.
The changed code can be found at https://gist.github.com/fangel/9553390

Example:

{MessagePaneView, PlainMessageView, LineMessageView} = require 'atom-message-pane'
messages = new MessagePaneView()
messages.attach()

messages.add(new PlainMessageView('a message'))
messages.add(new LineMessageView(1, 2, 'a line message', 'with a preview'))

I have added folding like in 0.3.0 of tcarlsen’s code, but it doesn’t automatically do summaries of the errors when collapsed.


#18

That is what I do in my plugins like jslint

Use it, and see if you miss some stuff so we can add it and be even better :slight_smile:


#19

Not sure if i’m going the coffee way yet.

I know my code ain’t the prettiest to look at, at the moment like the functions fold and unfold that basicly foes the same thing.
But I have focussed on features for now and the rewrite for better readability and contribute friendly will come later. And maybe then I will take a look at coffee.

Dont want to debat coffee vs js here, where is already a long tread about that in the forum :smile:


#20

I agree with CS/JS. I would have preferred JS as well, but I choose to keep it in CS since apparently that’s the direction Atom wants to go.

But it’s more the concept of using separate View classes for the message-types that I believe is the interesting change. It allows much easier extension by projects that relies on it - and it gets rid of the $('<div />') by moving to the more Atom-centric contents-DSL. This is easily done in JS as well - and I can change it over if you would want to use it that way.