You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Annotate candidates when listing music items (tracks, albums, etc.), such as in `consult-emms-library).
I want the annotation to be configurable, vertically aligned, and to have annotations in similar spirit for different categories (i.e. a track's and an album's playing time) aligned to each other.
I think the way to do this is to have:
a list variable for the different fields to display, and how long they should be (similar to how ebib handles index-item formatting). Perhaps this could also include fall-backs for if the field is undefined.
a generic function for each field
an implementation of each such function for each category (track, album, etc.). If the field is inappropriate, then return nil, or an empty string or something.
To solve the truncate issue mentioned here, I think the functions for gettng candidate lists will just have to include the ability to truncate? Maybe look into how citar handles this problem. Because of that issue (unless I want to have a long excursion into implementing proper affixation for consult-multi), annotation will have to come after the string. This is something I can live with.
The text was updated successfully, but these errors were encountered:
It would also be possible to implement prefix annotation using display properties. This would be a bit of a hack, and vertical alignment would be reliant on the annotations themselves being the same length. Perhaps we should just expose the interface such the user (me!) can set this up if they want to?
Annotate candidates when listing music items (tracks, albums, etc.), such as in `consult-emms-library).
I want the annotation to be configurable, vertically aligned, and to have annotations in similar spirit for different categories (i.e. a track's and an album's playing time) aligned to each other.
I think the way to do this is to have:
To solve the truncate issue mentioned here, I think the functions for gettng candidate lists will just have to include the ability to truncate? Maybe look into how citar handles this problem. Because of that issue (unless I want to have a long excursion into implementing proper affixation for consult-multi), annotation will have to come after the string. This is something I can live with.
The text was updated successfully, but these errors were encountered: