search

laochailan / barely

Yet another notmuch frontend
MIT License
7 stars 0 forks source link

Columnar searchbuffer #1

Open bbenne10 opened 8 years ago

bbenne10 commented 8 years ago

Firstly: this is an awesome project. Seems a much simpler codebase than alot, which I GREATLY appreciate. It's been really REALLY easy to hack on locally. The project seems to inherit some shortcomings I see in alot, however. Namely the lack of a column oriented view and a complete lack of threading (see mutt's threaded view for an example of what I would like to see)

I'm opening this to see if you'd be interested in some basic work I've done that introduces some VERY basic columns into the searchbuffer. It's probably not utf-8 safe (it doesn't address character pairs at all and will truncate in between them if the truncation point happens to fall between them). If there's no interest in this feature, I will simply fork and maintain some small feature set in the fork, but I wanted to talk about this before doing so (I have very little time to maintain a fork at the moment :P)

laochailan commented 8 years ago

It is nice to know someone else is using this client and thanks for the compliments. :D

Columns sound like a nice addition. I’m open for new features as long as they don’t introduce too much bloat in the code/ui.

Personally, I have e-mail conversations with very long threads with hundreds of big mails and I’m only ever interested in the most recent mail. A tree structure is very unhandy for this, so I have not implemented it yet. However, if this is optional in some way (e.g. like :msearch and :search allow you to display different searches in different styles) I’m not against it.

bbenne10 commented 8 years ago

I have a similar problem with long threads, but I find that removing irrelevant messages from view (specifically my inbox tag) helps a lot with this while allowing me some context when I'm reading over new messages.

I'll put together a pull request and we can discuss the column view further there.

bbenne10 commented 8 years ago

Sorry for the delay. OpenBSD, which I run at home, apparently doesn't ship a new enough zlib to build notmuch. I'm working on this, but I'm also away from home all week on vacation, so it's taking longer than necessary. It doesn't look as if this will be difficult to handle, but I need to figure out what to do about the possibility of truncating the tags list.,

If implemented improperly, we could truncate in between a highlight character and a reset character. This is easy to fix - just truncate before the highlighting is applied, since the highlighting won't contribute to width anyway. However, this brings up the question of "what do we do if we truncate during a tag"? We should probably still highlight the tag, even if it's not fully printed. I'm trying to figure out how to do that relatively efficiently.

laochailan commented 8 years ago

Termbox already handles all the terminal color sequences internally for us. There is a color buffer containing the foreground and background color for every character on the screen and termbox will worry about the best combination of sequences to make it look that way.

So truncating in between color and reset sequences cannot happen.