search

l3kn / org-el-cache

Persistent cache for data derived from org-elements
GNU General Public License v3.0
9 stars 0 forks source link

Using find makes org-el-cache exclusive to Unix environments #6

Open jethrokuan opened 4 years ago

jethrokuan commented 4 years ago

https://github.com/l3kn/org-el-cache/blob/6fc71563f05baa50c6120d5da37b9197e6f85327/org-el-cache.el#L230

l3kn commented 4 years ago

I think we can use something like sha1sum directory/**.org instead, I'll try that later today.

l3kn commented 4 years ago

It seems like shasum instead of sha1sum should work on both macOS and unix systems.

Not sure if something similar would be possible for windows systems.

jethrokuan commented 4 years ago

I think OS compatibility is important for a low-level library like this. I want to start using this in org-roam, but that would mean windows users can no longer use org-roam ):

That includes utilities like sha1sum, awk etc.

l3kn commented 4 years ago

With the Windows Subsystem for Linux, a **.org style glob with shasum should work, however I don't have a way to test this at the moment.

An alternative would be to provide a slow polyfill that uses directory-files-recursively and Emacs' buffer hashing.

jethrokuan commented 4 years ago

Looks like dired also assumes that Windows users install replacement find utilities, but in their case find is not crucial to the operation of the buffer. A fallback option would be nice, given that this is only really important for the initial cache building.

l3kn commented 4 years ago

The most flexible solution might be moving the "given these folders, calculate the hashes for all files in them" logic to a small bash script and call that from emacs. Then someone could write a powershell version of that.

An alternative fallback would be to disable cache persistence altogether, so caches are re-created each time emacs is started.

With asynchronous cache creation / updating, this wouldn't even affect the startup time.