Closed MikeTheGreat closed 5 years ago
My thinking with this one is that it's better to just define a new segment -- the customization is larger than the actual segment is, and I consider the ability to create your own segments to be the most "native" way of customizing telephone-line.
I know, I've gone with a whole bunch of different methods for different segments, but that's mostly when it comes to cross-segment support (e.g. the evil colors). While customize does provide categorization and hierarchy, I still think this makes it more opaque -- once you know how to create your own segment type, you can extend that out to any sort of customization, rather than thinking "this built-in segment is nice, but does it have (this one particular customization I want)?"
Thank you for the feedback! What you said totally makes sense. I was actually kinda thinking that myself when I wrote it up ("Gee, there's more customize-ation than actual code, here"). (I went the customize route mostly because I felt like if I was sharing something with other people that I should make it easier for them to tweak it without looking at code.)
While I want to be clear that this isn't a hill I'm going to die on, I would like to try again with a much simpler approach. I'll submit a separate PR for it. (Plus, it's good practice for me for using git - I think I should have made a branch off your master to hold just this one change, so I'm gonna try to get that to work out - wish me luck! :) )
I loved the buffer-modified-segment, and I
This PR does that.
What can I do to help with this process?
telephone-line-buffer-modified-segment, now with customize-able strings to display when the buffer is (un)modified. Also supports customize-able faces for when the buffer is (un)modified. Note that the face will only display correctly when the lhs/rhs is configured with a nil face pair.