cmp-natdat[0] is an nvim-cmp[1] source that autocompletes natural language dates (e.g. `@tomorrow`) and turns them into ISO dates (e.g. `2023-10-14`).

I built it because I missed this feature after moving from Notion to Obsidian[2] and writing my notes in Neovim.

Repository link: https://github.com/Gelio/cmp-natdat/

## Examples

* `@now` -> `2023-10-13 12:38`

* `@tomorrow` -> `2023-10-14`

* `@last Friday 2pm` -> `2023-10-06 14:00`

* `@Oct 8 2021` -> `2021-10-08`

* `@today 14:20` -> `2023-10-13 14:20`

## Features

* autocomplete for partially typed month names, relative dates

* supported formats:

   * `now`

   * `yesterday`, `today`, `tomorrow` with optional time

   * days of week (Monday -> Sunday), with optional `last`/`next` modifier and time

   * full dates: month, day, optional year, optional time

   * time: am/pm, or 24h format

## Installation and setup

Described in the README[3].

---

[0]: https://github.com/Gelio/cmp-natdat

[1]: https://github.com/hrsh7th/nvim-cmp

[2]: https://obsidian.md/

[3]: https://github.com/Gelio/cmp-natdat/#setup

All the software engineering roles on your careers page say the role is US-based. This is contradictory to what you said, unfortunately.

At Splitgraph we integrated tree-sitter [0] (in WASM) into our Console query editor [1] to introspect the pgSQL query and display the referenced tables in the sidebar for easier comprehension. We have written an article detailing how we got it done, where we evaluated a few existing pgSQL parsers, and talked about the parser features that are vital when using it in a code editor.

I was the lead engineer working on this feature and I'm here to talk more about this feature and answer any related questions you may have.

[0]: https://tree-sitter.github.io/tree-sitter/ [1]: https://www.splitgraph.com/query?sqlQuery=SELECT%0A++++%22Em...

While working on the Splitgraph Console [0], I have done a deep-dive on the ways to keep the Apollo Cache up-to-date after running GraphQL mutations.

This article summarizes my findings and suggests optimal which approach to use based on the type of mutation.

[0]: https://www.splitgraph.com/splitgraph/congress_tweets/-/cons...

Hey everyone! In the article [0] I share my approach to using `Either` and `Option` fp-ts containers in React code. I focus on the risks associated with using these values in hook dependency arrays and present workarounds.

I'm curious to learn if/how you use fp-ts in your React code

[0]: https://www.gregroz.me/article/use-fp-ts-hooks

The problems and inconsistencies of `async`/`await` in JavaScript.

Inspired by the discussion on a previous article: https://news.ycombinator.com/item?id=33309685

The convenience of `promise.then` behaving both like monad's `chain` and `map` comes at a cost of ambiguity in some cases.

Stop using .then wherever possible.

(and also avoid using .map for side effects! Prefer foreach for!)

How would using async/await help here? It has the same issue of implicitly awaiting the Promise that is returned from an `async` function.

In fact, your comment inspired me to go into more depth regarding the problems of `async`/`await` syntax: https://news.ycombinator.com/item?id=33322184

As for `.map`, I was referring the monadic `.map`, not `Array.prototype.map`. Either way, I agree `.map` is not for side-effects. The article says nothing about side-effects, so I'm not sure where this remark is coming from.