Display in index buffer when field is not present
Closed this issue · 3 comments
Current behaviour: if a field is listed in ebib-index-columns, has no corresponding entry in ebib-field-transformation-functions and is not present in a given entry, that entry instead displays (format "(No %s)" (capitalize field)).
Problem: I tried adding ("Chapter" 2 t) to ebib-index-columns. Most of my entries have no chapter number, so (since (format "(No %s)" (capitalize "Chapter")) is more than 2 characters) I got a lot of what was basically screen clutter ((...).
I can override this by writing a function which just checks if there is a chapter number and if not, returns an empty string, then adding it to ebib-field-transformation-functions, but this seems like a lot of configuration to get something to not show up!
Possible solutions: for me, it seems obvious that the default behaviour when there is no field value is to display nothing (i.e. print the corresponding number of spaces). One solution is to just change the code to do this.
However, clearly the current behaviour seemed equally obvious to someone else a while ago. Perhaps we could leave it up to users with a configuration option somehow, governing the default behaviour for when a field is undefined? Of course, this too would be overridden by ebib-field-transformation-functions.
Or maybe this is just too persnickety and I should just keep the function? 😅
Problem: I tried adding
("Chapter" 2 t)toebib-index-columns. Most of my entries have no chapter number, so (since(format "(No %s)" (capitalize "Chapter"))is more than 2 characters) I got a lot of what was basically screen clutter ((...).
Hmmm, yes, I can see how that would be annoying and pointless.
However, clearly the current behaviour seemed equally obvious to someone else a while ago.
Yeah, that someone else would be me. 😄
The problem with just displaying nothing is that the function is also used in a few other places, notably to create Org links and to create descriptions for completion, and I'm not so sure how well it would work in those cases to display nothing. So I decided it would be better to always return some string.
That being said, the index buffer is different from those other uses, because strings are truncated if they're too long. So one option would be to add an optional argument to ebib--get-field-value-for-display to tell it to return an empty string rather than "(No FIELD)" and use that in ebib--get-tabulated-data.
Alternatively, we could say that if a column is too narrow for truncation to be useful, we don't display anything if the string is too long. (This would have to be implemented in ebib-display-entry-key). So in your example, chapter numbers would be displayed because they don't exceed the column width, but the string "(No CHAPTER)" would not, because a column width of 2 is too narrow for truncation.
In that case, we'd have to think about what "too narrow" means: either too narrow to display the ellipsis symbol (truncate-string-ellipsis), or smaller than some fixed value, on the assumption that whatever is left of the elided string is too little to provide any valuable information anyway. (I think I'd prefer the second option, BTW.)
Perhaps we could leave it up to users with a configuration option somehow, governing the default behaviour for when a field is undefined? Of course, this too would be overridden by
ebib-field-transformation-functions.Or maybe this is just too persnickety and I should just keep the function? 😅
I'd say it's too persnickety (didn't know that word 😄) for a configuration option, but other than that, certainly worth improving.
If you are interested in implementing either of the options I suggested, or if you have a better idea, feel free to create a PR. Personally, given how little time I have to work on Ebib ATM, I'd just implement the first suggestion, as it seems reasonable to me and the quickest to implement.
As it turns out, implementing the idea to not show truncated strings at all if the column is very narrow wasn't so difficult after all, so I went with that solution. (I decided to hard-code the limit; basically a string is not displayed if it's too wide for its column and fewer than five characters of the string would remain visible after truncation.)
Thanks! Just tested and it works perfectly for me!