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
I think this would be a good thing to change. I don't think the hash serves much purpose in filenames (except ensuring uniqueness, and that can be achieve better in other ways, e.g. with a suffix or by adding the time-added).
When it comes to concrete proposals I think adding the year in would be nice (e.g. author-year-title). Would data[author] include the whole author? That could be veeery long. It would be nice to just use surnames, but those might not be available? And it would also be nice to fall back to editor if author isn't available, but I don't think this can be achieved with the default formatter. We'd also need to handle missing fields in some sensible manner.
EDIT: If we added jinja2 as normal dependency, we could supply sophisticated/flexible defaults. Especially once we sort out #711, this could be quite a neat solution.
I currently use something like this {doc[author_list][0][family]}{doc[year]}__{doc[papis_id]} where the id solely serves to ensure uniqueness. Of course it is very long for that purpose. An optional suffix (a-z) would be great instead. One that gets appended only if the resulting string is not unique.
The editor-if-no-author option sounds great as well!
Right now,
add-folder-name
defaults to an empty string. This makes it fallback to a hash-based name that looks likeA value based on the document data would be friendlier, e.g.
{data[author]}-{data[title:.5S]}
(authors + first 5 words of the title).xref: @jghauser suggested a nicer jinja2 format in #842 (comment)
The text was updated successfully, but these errors were encountered: