in the correct timezone, with smaller milis
According to the spec, this should work because:
> The timestamp of the breadcrumb. Recommended. A timestamp representing when
> the breadcrumb occurred. The format is either a string as defined in [RFC
> 3339](https://tools.ietf.org/html/rfc3339) or a numeric (integer or float)
> value representing the number of seconds that have elapsed since the [Unix
> epoch](https://en.wikipedia.org/wiki/Unix_time). Breadcrumbs are most useful
> when they include a timestamp, as it creates a timeline leading up to an
> event.
* The "collapse" etc. buttons get shown below the search box and < << >> > from
a certain width downwards.
* similar stacking for the date/type/value and the buttons at an even smaller width.
See #120
* in 1abc30a760 the hardcoding of ="dark" (during development)
was accidentally checked in; it never should have been.
* in e14b3eaaa6 I mixed up the bare*base templates. It's actually
bare_base.html that's for 404/500 etc; barest_base is more bare
visually (it's the box-based layout for login etc), but it doesn't
need to be so careful not to use variables.
See #40
my chatbot tells me it felt ugly because
> bg-yellow-900 [..] is a very saturated, reddish mustard — almost
> brown-orange. That’s why it feels so jarring in dark mode: it's too warm,
> too saturated, and clashes with a cool-dark UI. [..] Try bg-amber-800
> instead. Tailwind's amber palette is warmer and more muted than yellow,
> designed to fit better in dark UIs.
No idea if the reasoning is sound, but it "looks good" so I'm pushing ahead.
Implement delete functionality with confirmation modals for users. Ensure
proper authorization checks are in place before deletion. Add corresponding
JavaScript files to handle modal interactions and form submissions.
Based on #84
Signed-off-by: Animesh Agrawal <animesh@flick2know.com>
Other than fixing syntax higlighting for my favorite language, this has
the advantage of actually being a _deterministic_ solution (the previous
solution would do first-match) which makes the extra complexity worth-while.
the idea: guess on filename first, and on code second.
prompted by: getting a Django Template Parser to work.
however, this won't fly, because lexer.analyse_text is basically useless
(the parts that are implemented __at all__ are often based on some initial
bytes in the file, which is useless in our context of code snippets)
As discussed in #11, there are scenarios (e.g. misconfiguration) where snappea
does not pick up the tasks. Events not showing up in Bugsink, w/o further
indication why that may be, leaves people confused. Better to warn explicitly
in that case.
prompted by the LHS going awry, esp. the part where the 'Show all' etc buttons
git commit -m "'Issue Key Info'; show on xl, not lg. (while recording a video
at 1080px width)
in the lists; this is easier to read than a strikethrough.
I experimented with text-decoration-style and text-decoration-style but that
didn't make it better.
Our big brother doesn't bother to reveal the resolvedness of issues in lists
_at all_, btw. Surprising!
according to spec, this is possible (though I did not yet observe it in the data).
the need for this was exposed when introducing fastjsonschema, which (by default)
fills in all keys with their default values (None for pre_context/post_context)
