Not sure where you got that quote from, but FLWOR is not something JSONiq invented.

- https://en.wikipedia.org/wiki/FLWOR

- https://www.w3.org/TR/xquery-30/#id-flwor-expressions

FLWOR is pronounced 'flower'.

It does not really seem to be maintained anymore. Is there any downside because of that?

Looks to me like it had commits in June and August of this year. Or do you wonder whether they'll add features like pushing from within vimagit?

I did see the commits, but the last release was almost three years ago. That is not necessarily bad. I was just wondering whether it still works well or there are any quirks.

Many Vim plugins abandoned the release model since most Vim and NeoVim package managers focus on fetching latest git HEAD for every installed plugin.

Yes, good explanation. Case in point: Neogit has never tagged a release: https://github.com/TimUntersberger/neogit/tags

neogit is "magit for neovim". It is written in Lua. Did you already know the answer to your question? ;)

https://github.com/TimUntersberger/neogit

Similar Git tooling can be found in https://github.com/frontaid/git-cli-tools

bit (https://github.com/chriswalz/bit) is a somewhat similar CLI tool for this. It shows command completion alongside a description.

PS: We maintain a list of helpful Git CLI tools on https://github.com/frontaid/git-cli-tools

Formatting (without "arbitrary format specifications") has been available for years:

- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

- https://caniuse.com/mdn-javascript_builtins_intl_datetimefor...

Parsing, however, is an entirely different topic. I assume the Temporal proposal authors learned from the Date.parse fiasco. To this day, there are browser inconsistiencies that make it largely unusable for anything else than the full-length ISO date format. Hence, it might be better to use a userland library that works consistently regardless of the browser (version). There are also some notes about parsing in https://tc39.es/proposal-temporal/docs/parse-draft.html:

> Temporal's approach to most operations—including parsing—is to encourage strong typing, e.g. Temporal.Instant.from vs. Temporal.PlainDateTime.from. A type-spanning "parse anything" API goes against that strongly-typed model.

Yes, it's always been possible to get some kind of string from datetimes, but I specifically care about specifying what string, same with parsing. "Just use a locale's default" might work if you're making a web app for clients who aren't picky, but using JS as a "serious" language it's a really big hole. There's plenty of formats that demand non-ISO date formats and I currently need to use a third-party library. I've gotten used to than in JS, but I was hoping a new take on dates will sort this out. Oh well, I'll have to just hope it makes it to v2: https://github.com/js-temporal/proposal-temporal-v2.

All good points. I completely agree.

Does using a JS backend like Node or whatever help ease this pain?

I've yet to dabble in that realm much, but I've always hated working with dates in JS and C# because of how each language handles dates differently. It's not the most annoying thing by any means, but it does slow me down on the occasion.

> As a side note, what do people think about JSON schema? I find it quite verbose and cumbersome

Agreed. But if you want to have validation and autocompletion in most editors, it is still the way to go. We use it to validate JSON content files for a CMS [1]. It is a little repetitive in our case (e.g. the `:name`/`:description` keys are repeated), but not that bad. Newer versions of JSON Schema [2] have improved in that respect, but most editors (or plugins) and tooling in general is still based on older versions. So we have to stick with those for a while.

[1] https://github.com/frontaid/schema/blob/master/frontaid-sche...

[2] https://json-schema.org/specification.html

If you have to deal with JSON a lot, you might want to checkout https://www.schemastore.org/json/ which has schemas for a large number of file types.

That page broke tabbing through interactive elements by using nested focussable elements like this:

    <div tabindex="0"><input ...></div>

Because of that, it is sometimes necessary to tab twice to focus the next element. Not sure whether that is a problem of DaisyUI in general or just their website. But it is definitely annoying.

Both of these examples are well-known (and not unexpected) behaviours. I assume you already know why it behaves like that. If not, I can explain it.

> [1, 2, 3] + [4, 5, 6] // -> "1,2,34,5,6"

What would you expect instead?

> [,,,].length // -> 3

Is there any use case where you would want to deal with sparse arrays?

[1,2,3] + [4,5,6]

An addition operation over two numerical vectors of length 3.

I would expect the result to match its inputs and provide a numerical vector of length 3.

Thus: [5, 7, 9]

The issue there is that arrays aren't first class types in JS, they're just objects with numeric property names.

So if applying an operator to arrays spread the operation across all the elements that way, it would imply that the same should happen generally for all object properties, with whatever weird implications that would entail.

    a.foo = 1
    b.foo = 'there'
    a + b // { foo: '1there' } ?

What language has this behavior by default?

Fortran :)

> [1, 2, 3] + [4, 5, 6] // -> "1,2,34,5,6"

> What would you expect instead?

If I let my first instinct speak:

[1,2,3,4,5,6]

And then if I think a little more, then maybe:

[5,7,9] //with obvious caveats

In no way do I expect what GP actually provided.

I understand where you are coming from. But the addition operator simply does not have any special handling of arrays. The specification [1] clearly defines what it should be used for: "The addition operator either performs string concatenation or numeric addition." As JavaScript is weakly typed, it is the programmer's responsibility to use proper value types with these operators. That limitation (or advantage?) is also well-known and applies to all weakly-typed languages.

[1] https://tc39.es/ecma262/multipage/ecmascript-language-expres...

It seems that by "expected", you mean "expected, by anyone who read the spec" which I don't think is a fair use of that word. Obviously, most JS developers have not and will not read the spec.

I am very happy with JS and TS and I think the coercion rules are easily worked around with linter rules and policies, but they are definitely weird and I think the language would be better if it simply threw exceptions instead. But then, such an issue shoud not be surprising for a language that was designed in 10 days.

No, I meant "expected by anyone who learned the language". Knowing the addition operator including its limitations is quite basic. I'm not saying you need to be able to solve all this "JavaScript is weird" puzzles as they are mostly non-sense. But you definetely have to know what you can us `+` for.

If someone does not like the ECMAScript specification, that is fine. But at least use a proper unofficial documentation like MDN.

well I guess the question is then not just what would you expect instead but at what familiarity with the language should one be asking people what they expect of it?

If you ask experts it is because you want to get an actual correct answer, but if you ask neophytes it is because you want to get an answer that might be obvious even if not correct.

Perl would give you 9 for the equivalent expression of (1,2,3)+(4,5,6) :)

> Is there any use case where you would want to deal with sparse arrays?

Not really. Now explain why [,,,].map((e,i) => i) is [,,,] instead of [1,2,3] please ;)

(assuming you're really asking) It's because JS has a notion of array elements being "empty", and the map operation skips empty elements. Basically "empty" means the element has never had a value assigned to it, but its index is less than the array's length property.

    Array(4)               // [empty × 4]
    a=[]; a.length=4; a    // [empty × 4]
    Array(4).map(n => n)   // [empty × 4]
    [,,1,,].map(n => n)    // [empty × 2, 1, empty]

My go-to way of avoiding this annoyance is "Array.from(Array(N))":

    Array.from(Array(4)).map((n,i) => i)  // [0, 1, 2, 3]

Alternately there's a recent "fill" method, that assigns all elements (including empty ones) to a given value:

    Array(4).fill(1)      // [1, 1, 1, 1]

> I wish for the day where I can really just write clean semantic html and then add the CSS afterwards on top of it.

What exactly is stopping you from doing just that today?

For certain layouts and CSS features to work you need to add structure for it AKA additional tags, typically divs and spans because they have no meaning in terms of your document.

So your document becomes a mix of semantic structure and then wrappers, containers, pushers, purely visual areas and so on. Also you're going to have things that are specifically redundant for your use-case, but you still add them for consistency and re-usability.

CSS would have to be quite a bit more powerful to achieve a clean separation of document structure and layout. It would need things like purely visual grouping mechanisms, reactive or backtracking selectors and HTML itself would probably need to be either a relational or graph structure instead of a tree to actually convey the semantics correctly and consistently.

Thoughts on HTMX?

So far: sounds interesting and I want to know more about it.

One example is to "inherit" class styles.

E.g. let's say I have some html like <p class="warning">be very careful<p> and there is some 3rd party CSS that already has nice styling for a warning paragraph. But it uses .warn as a class, not .warning.

I don't want to change my HTML and I also don't want to copy the style. I want to tell CSS that my own .warning should inherit the style of .warn (and maybe adjust it slightly if necessary)

That is (to my knowledge) currently not possible.

Only semi-relevant, but this is possible with SASS’s @extend: https://sass-lang.com/documentation/at-rules/extend

Because the output is still CSS, this would lead to a lengthened (redundant) selector though. Also, AFAIK it would be impossible with a class that is not part of your SCSS tree. If you are able to import the library CSS in to your own SCSS, OK, no problem. But that would introduce unneeded complexity. If using a bundler and one output file, copying the library CSS rules and applying them to your own could maybe even lead to the same output as @extend - a combined selector

.warn, warning

(you already kind of addressed all of that already in your "semi-relevant" disclaimer)

> (you already kind of addressed all of that already in your "semi-relevant" disclaimer)

You make some good points, and I wish I could still edit it to "kind of possible" ;)

Nesting is not possible in vanilla CSS. However, there is an Editor's Draft about it which has gained some momentum recently.

https://linkedlist.ch/ref/25/