Show HN: Posce, a note-taking toolkit for your command-line | Hacker News Reader

Show HN: Posce, a note-taking toolkit for your command-line

github.com

54 pointsswidi30 comments

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 :)

Thanks!

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.

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.

If you use much *nix style software on Windows, you may already have a XDG_CONFIG_HOME directory. It defaults to ~/.config

Even on my relatively clean Windows system, that directory contains config files generated by NPM and Scoop.

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.

Yes, sorry I got it backwards.

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.

"If hidden files didn't exist" doesn't matter because they do exist...

I actually also prefer putting config files in HOME. I don't feel strongly enough to argue about it, I just prefer it.

I don't really like hidden files myself, but my point was more to get you to see the lack of clean hierarchy in just dumping things in $HOME.

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?

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.

Can you give me a concrete example? I'd like to implement this capability, but I'm not sure what you're asking.

a search term or a regexp only matches on a single line. i think what op is asking is the ability to match multiple terms across multiple lines.

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

I don't see what the point of this is. Every single command can be mapped to an existing Unix tool.

I wrote about that in the FAQ: https://github.com/posce/posce#why-use-this-instead-of-lsgre...

## 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.

I still don't see the point. I can just "cd ~/notes" and use normal commands in there.

Not convinced your code is more stable than POSIX tools. :) Maybe more uniform.

Is anyone else getting a "Error 401 UNAUTHORIZED" on this github repo?

not anymore.

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.

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.

If someone calls it a "command line" I usually ignore them. If they call it a "shell" I am more inclined to take note . . .

Okay, well I'll keep calling it a command line to avoid snobs like you. Thanks for the tip!

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.

Reply on news.ycombinator.com