dbordak / telephone-line

A new implementation of Powerline for Emacs
GNU General Public License v3.0
555 stars 50 forks source link

Responsive Modeline #8

Open Kethku opened 9 years ago

Kethku commented 9 years ago

I have no idea if this is in the scope of this library, but I had in vim some library (can't remember which, maybe it was built into powerline?) which would remove sections of the mode line when a window got smaller. This way if you partitioned up a frame too much the mode line would still look good instead of just pushing important sections off of the screen. As far as I know current powerline implementations on emacs don't have this, and in my opinion it would be an awesome addition.

dbordak commented 9 years ago

This is definitely something I want. It's a difficult problem, though, and I'm not sure how to do it efficiently. Yet.

Kethku commented 9 years ago

Is the difficulty with implementing the code in an efficient manner or is it with writing an effective interface for the feature? I don't really have much to contribute either way, I'm just curious.

dbordak commented 9 years ago

Figuring out how large a segment is requires rendering it. In order to figure out whether to collapse a given segment, you'd need to find out how big every other segment is. So, this would require doubling the amount of rendering going on.

...However, it's not as bad as it sounds, since empty segment detection already involves duplicated rendering. There's still logic on top of that, though...

Kethku commented 9 years ago

I wonder if you could take a page from css and just give pixel minimums. Leave it up to the user to specify at which point each section gets removed from the mode line. I would be happy to just add an integer to each section which is minimum width in pixels or some such. I don't think it's necessary to over engineer the problem. That's just my two cents though.

dbordak commented 9 years ago

Do you mean a maximum width?

Pixel count is actually really difficult to do. Luckily we're dealing in fixed-width fonts, though, so we can do character count. It'd be trivial to add truncation past a certain max, but that isn't really intelligent.

EDIT: Oh, do you mean a minimum amount of space you'd need to render the segment? So if there's not enough room, just skip it? This is what I was originally thinking of.

Kethku commented 9 years ago

Haha words suck. What I was thinking is to add a number associated with each section which is the width, probably in characters sounds like, at which point for any width of the window smaller than that width, the section will not render.

Said differently, it is the minimum width of the window that a given section will display in. In many ways this might be sufficient for the majority of sections because they often have a constant width. Even more interesting would be to let the user specify a function which returns the width of the section. I would guess that usually the width could be known ahead of time without having to render the whole thing. Then taking that information it would be trivial to add a priority for what sections are more important to be included than others.

I could be completely mistaken though, as I haven't had the time to dig in to the code :smile:.

dbordak commented 9 years ago

Yeah, the rub is still that to find out how much space you have available, you need to check all the other ones... For some cases, true, you can easily figure out what it'll be. For others, it's highly variable (e.g. minor modes).

My original thought would be to attach a number for priority -- if there's not enough room to fit the whole thing, the segment with the lowest priority is booted first.

mattfidler commented 8 years ago

Smart mode line does something like this.

https://github.com/Malabarba/smart-mode-line