Move history tree to a separate repository

[Ambrevar]

Or shall we move it to cl-containers? If the latter, then we'd need to adapt the library to reuse the generic functions of cl-containers. It's a bit more work, but this saves the community of an extra lib.

[jmercouris]

I'm not sure history tree is a good candidate for a library. Can you think of some other projects and how they might use it?

[Ambrevar]

The future Common Lisp file manager, Lem, etc.

[jmercouris]

OK, great :-)

[Ambrevar]

So cl-containers or separate repo?

[jmercouris]

cl-containers is my vote

[Ambrevar]

Now that the history-tree has turned into a much larger, more specialized and yet more general library, it won't fit into cl-containers.

I'll move this to a separate repo at https://github.com/atlas-engineer soon.

Shell we stick to history-tree or shall we use the "global" prefix somewhere in the name? @aartaka ?

[aadcg]

nhist-trees?

[aartaka]

I'd say no to global one, as globality (in the sense of supra-tab scope) is only the property on Nyxt history enabled by this library.

history- doesn't necessarily make sense either. It's too general to be locked to history, maybe.

So we're left with the mere properties of the structure: owned, deduplicating/space-efficient, pure-lisp, arbitrary children number. Owned-ness is the most distinctive property, I'd say. owned-tree?

But then, we have a nice convention of n-prefixed names, as @aadcg highlights. And we also have a nice htree nickname already. How about dyslexically merging those into an ntree? Seems general enough, while being reasonably recognizeable.

[Ambrevar]

ntrees then?

[aartaka]

Why plural?

[Ambrevar]

Because nhooks and nfiles are plural...

[aartaka]

But then it's because both files and hooks usually go in packs, isn't it? This is not true about ntree, as it's mostly intended to be used as a single instance of a tree per several owners.

[aartaka]

And the convention is (alex:symbolicate 'n word), not necessarily (alex:symbolicate 'n word 's) :)

[Ambrevar]

Well that's still up for us to decide :)

I like to mention "history" because while the data structure does not explicitly mention it, it does carry the notion of forward / backward and children in the context of histories.

[aartaka]

A neologism: nhistree — sounds much like n-history, while being spelled as a tree :D

[jmercouris]

ntrees is my vote. For whatever it is worth. Artyom does make some really good arguments though...!

[Ambrevar]

I'd like to argue why this is about "histories" and not just "trees". The raison d'être of the library (and its main difference with trees) is that we add a "forward child" slot (which has a huge impact on the design).

The notion of "forward child" is exactly about this: history navigation.

Someone working on a file manager looking for such a library is likely to lookup "history" (e.g. with quicksearch). "Tree" is too generic a term to be helpful here.

---

Other points:

• The "n"-prefix rule makes sense for library which would otherwise have a too common name: nfiles, nhooks, nclasses, nkeymaps... It helps disambiguate. However, if the name is unique enough already, do we really need this rule? Maybe it's fine to have a legible, meaningful name on its own.
• The current name history-tree is a good one in my opinion. Renaming it is more work (we need to rename quite a bunch of symbols in the code base), so why bother? :)

[aartaka]

That's a sound reasoning, yes!

[jmercouris]

In any case, as long as it is released under the atlas-engineer organization, I am OK!