Implement all builtin filters

[LilyFoote]

We need to support every filter in https://docs.djangoproject.com/en/5.1/ref/templates/builtins/#ref-templates-builtins-filters. They can be added as variants to the Filter enum in src/parse.rs.

• add
• addslashes
• capfirst
•  center
•  cut
•  date
• default
•  default_if_none
•  dictsort
•  dictsortreversed
•  divisibleby
•  escape
•  escapejs
•  escapeseq
•  filesizeformat
•  first
•  floatformat
•  force_escape
•  get_digit
•  iriencode
•  join
•  json_script
•  last
•  length
•  linebreaks
•  linebreaksbr
•  linenumbers
•  ljust
• lower
•  make_list
•  phone2numeric
•  pluralize
•  pprint
•  random
•  rjust
•  safe
•  safeseq
•  slice
•  slugify
•  stringformat
•  striptags
•  time
•  timesince
•  timeuntil
•  title
•  truncatechars
•  truncatechars_html
•  truncatewords
•  truncatewords_html
•  unordered_list
•  upper
•  urlencode
•  urlize
•  urlizetrunc
•  wordcount
•  wordwrap
•  yesno

[jonathan-s]

Making an attempt at addslashes.

[jonathan-s]

I've been thinking about filters and how they are structured. In parse.rs we get the filter type. Then we implement render for filter, and thus match it on filter type, and returning the correct behaviour there. We get a very long match statement there, and it has a tendency to get a bit unwieldy.

An idea that could perhaps work would be to use unitstructs in FilterType.

pub struct AddSlashesFilter;

pub enum Filtertype {
  AddSlashes(AddSlashesFilter)
  ..
}

Given we can then implement a trait apply for filter, and each filter would implement that. I think that could possibly be a pretty nice way of decoupling and breaking up that big match statement.

[LilyFoote]

I think that's a great idea, go for it!

I've also been wondering defining a macro (or two) to abstract away the repetitive error handling in the big match in parse.rs.