As someone who still uses a `birthdays.txt` file in their home directory... i fail to see any advantage to this setup. And a significant disadvantage would be losing the ability to tab-complete the note names.
I use a single notes directory and I prefer disambiguation to tab-completion, which I why I built it this way. I guess its advantages aren't universal, but then again what is?
Posce is one app using one system on one directory. It's a very focused app, and that focus gives it a level of stability and uniformity I enjoy. Also, by using a single notes directory, you can use disambiguated names and get incredible brevity when entering commands.
I don't agree with the assumptions baked into the tool (eg env vars over config, new vs edit, no deletion), yet I like it being opinionated. Keep coding :)
i like the 'no deletion' attitude. so much can go wrong when writing custom code to delete stuff. as deletion here is trivial to do yourself using whatever preferred method and policy (like moving stuff to trash) you have to delete stuff, i do appreciate the decision to stay away from that.
for the env vars, i hope there are defaults that make even setting the env vars optional and not needed unless i want to change the defaults.
Funny, I started seeing 401 errors intermittently when trying to download some releases some hours ago, but it went away after a couple of minutes. Seems GitHub is starting to have some issues today but https://www.githubstatus.com/ shows nothing, maybe they haven't noticed yet.
A shell is a software construct that implements a level of abstraction over a lower system.
A command line is a particular type of shell, gui's are often implemented as a shell too.
The last thing you or I need is another configuration file clogging up our home directories.
This is why the XDG spec exists. Use XDG_CONFIG_HOME, not HOME.
I don't feel strongly about config file vs env var for just 2 settings, but seems worth noting. Dropping a dotfile right into your home directory is old school and needs to go away.
I'm a Windows user, which means dotfiles are even uglier for me. For an app that just needs two tiny variables, environs are the much cleaner solution.
To me filling HOME with dotfiles doesn't feel much tidier than filling XDG_CONFIG_HOME with stuff, but I'll take everyone's word for it (even though most people can't seem to explain why they prefer it, can you?).
I'm assuming that you accidentally got that statement backwards, because otherwise it doesn't make sense to me.
Would you still feel like dropping things in HOME was tidy if hidden files weren't a thing? You can also back up XDG_CONFIG_HOME without grabbing garbage like cache data.
I don't look at my HOME directory often, I usually start from a subdirectory of HOME that has what I'm looking for. Is that why people prefer XDG_CONFIG_HOME, because they look at HOME a lot? I guess I can understand that.
Yes, I usually start my shell sessions in $HOME. I also have shell aliases set up so I always see hidden files, and it would drive me crazy if I weren't able to tuck most config files into another directory.
I think Emacs has been shielding me from dotfiles. I usually start a shell in the directory of the file I'm looking at. I hardly ever see $HOME. I also have dired (Emacs' built-in file explorer) show me hidden files by default, but there aren't that many (basically just .git and .gitignore) outside of $HOME.
Since you use a text editor anyway, why not use a text editor and a text file to, uh, take notes? Your tool runs in an interpreter and needs a dependency maintenance workflow.
This isn't one note, it's dozens at least. I wanted a centralised way to organise them, and I wanted to try making something myself. Working on all these files by hand would be tedious and error-prone.
I actually want something like this. currently I just use Gnome Evolution for this since it syncs with my corporate EWS automatically.
However, one thing I think must be required from such a tool is a full text search engine. The find subcommand appears to only use substrings or regular expressions which can be very limiting when trying to find that note you made about server xyz and some service abc on it. A regex that would sufficiently find that escapes me, if it's even possible.
31 comments
[ 3.2 ms ] story [ 87.1 ms ] thread## Why use this instead of ls/grep/wget/etc?
Posce is one app using one system on one directory. It's a very focused app, and that focus gives it a level of stability and uniformity I enjoy. Also, by using a single notes directory, you can use disambiguated names and get incredible brevity when entering commands.
for the env vars, i hope there are defaults that make even setting the env vars optional and not needed unless i want to change the defaults.
This is why the XDG spec exists. Use XDG_CONFIG_HOME, not HOME.
I don't feel strongly about config file vs env var for just 2 settings, but seems worth noting. Dropping a dotfile right into your home directory is old school and needs to go away.
Even on my relatively clean Windows system, that directory contains config files generated by NPM and Scoop.
Would you still feel like dropping things in HOME was tidy if hidden files weren't a thing? You can also back up XDG_CONFIG_HOME without grabbing garbage like cache data.
I don't look at my HOME directory often, I usually start from a subdirectory of HOME that has what I'm looking for. Is that why people prefer XDG_CONFIG_HOME, because they look at HOME a lot? I guess I can understand that.
I actually also prefer putting config files in HOME. I don't feel strongly enough to argue about it, I just prefer it.
However, one thing I think must be required from such a tool is a full text search engine. The find subcommand appears to only use substrings or regular expressions which can be very limiting when trying to find that note you made about server xyz and some service abc on it. A regex that would sufficiently find that escapes me, if it's even possible.
eg. i want to find all notes that contain the terms "linux" and "webserver" in any order anywhere in the note.
it may be possible to write a multiline regexp to do that, but it's not trivial, and this would be a common use case