Be more explicit with (potential) breaking changes

[hans-d]

Eg, with the status section now changed it impacted my current small customisation of the nano-modeline- faces.

Also, the switch from status to prefix is quite hefty. A 'deprecation' notice would have been nice.

PS: the main readme still mentions status, while the code is referring to status.

[aaronjensen]

For what it's worth, I think the status change took things in the wrong direction. From a UX perspective, we now have the thing that draws the most attention visually contain information that I don't personally find very useful. I almost never wonder "what kind of file is this?", and I wonder how many people actually do. The file name and the contents communicate that to me at a glance.

Now, not only is it visually heavy, but it also varies in size impacts my ability to quickly find the most important piece of information in the header line -- the name of the file/buffer.

I don't necessarily think that the file being RW is that important either, but modification status is, and that's the thing that I reserve the brightest color for in my theme.

[hans-d]

agree. With #27 already a quick fix to get the more important info up front. Still want to check on the colors.

[hans-d]

The colors seem to be coming from nano-theme (at least in my case), local adjustment of the face is the way to go.

[aaronjensen]

@hans-d I tried something like #27 and I wouldn't want to use it. I don't think it's right either. What it was before was ok for me, a small thing that indicated whether or not the buffer had changes.

[hans-d]

Doing some experiments....

top: active buffer changed bottom: inactive buffer changed middle: readonly

[hans-d]

@aaronjensen fix now included status

[rougier]

You're right, I should have warned about the change. I tend to agree with the comments and I think we can go back to the previous version (RO/RW/**) using the new render modeline function. Then I'll think about a way to give user the possibility to customize the modeline.