proposal: Entry deletion about atuin HOT 11 CLOSED

It would be awesome to be able to delete entries from history from the interactive search UI by selecting an entry with the up/down arrows then pressing the delete key.

from atuin.

Addendum: bash has a mode where if a command starts with a space, it is not saved to history. Supporting that (or something similar) to prevent entries being written (and possibly synced) in the first place would also help.

from atuin.

@ellie You said that this is in the works, are you still working toward this? I could take a look if you want, but if you're in the midst of a larger change then it can wait. I'm not clear on the scope of this give that there's a server component too, but i could still take a look.

I am! Just very slowly, life has been busy lately. I'll have much more time for this now that summer (in the UK) is over though!

tl;dr for the plan, which I'd like to break down a bit more and HOPEFULLY get in for a v12 release. Or at least partly!

Deleting things, finally, as everyone has been asking me for it

(cue brain dump)

1. Switch to event log sync

I started on this here: #390

The difficulty here is that actually deleting the entire row will change the count of rows. Syncing two append-only logs is much much easier and simpler than syncing two arbitrary length sets of data, especially when each installation of atuin is both read and write (so technically multi-master).

The premise with this solution is that instead of syncing up history items, as we do at the moment, we sync up events. I'm proposing two kinds of event. A CREATE event, and a DELETE event. For backwards compatibility, we'd want to add a CREATE event for every currently-existing item of history.

To delete an item of history, we push up a DELETE event to the log. This is still only an append, so we can retain our simple sync logic + keep things nice and easy.

If we replay the log on a fresh client, the history item will end up being created + then deleted. Mostly there, and mostly achieves the use case of "I don't want this thing showing up in my history".

Once that works, we could expand it to also blank out the data section of a CREATE event when a DELETE event has been created, though that would cause limitations in future sync methods (I was conisdering something based on merkle trees).

2. Implement UI for deletion

I'd like this to be smooth, obvious, and not some arbitrary key combination. But also not easy to do by accident! We may also want the option to delete a single occurence of a command, but not delete all historical occurances of it (and vice-versa).

To allow for this, it would be good to be able to open a "context menu" on a single item of history. I'd suggest using the tab character for this.

Scroll back to the item you wish to delete. Hit tab, and we switch to the menu item for that history. As well as showing extra information about it (directory executed in, some other context, etc), we can have an option for deleting it!

Might want some kind of UI hint to make it obvious that tab does stuff

3. done...?

Probably not, I imagine some things will break. I'd like to roll this out gradually, as we need to maintain backwards compatibility. Will probably save old style history rows and event rows side-by-side, and start by just syncing CREATE events up and not even implementing DELETE until the next version.

from atuin.

Thanks for that @bvergnaud! Really nice workaround

None of this is as neat as a proper handling of commands prepended by space(s), nor does it solve the use case of "oops I already inserted my sensitive command in the history", but I hope it helps in the meantime.

I totally agree there - I think if we get the space issue sorted + released very imminently (won't be at all tricky) then the deletion issue can be sorted right after that ☺️

This + supporting fish are probably the highest priorities for me at the moment

from atuin.

Working on it, but it involves some larger changes around how sync works :)

from atuin.

I have the same need. In my workflow, I sometimes happen to need what essentially amounts to an incognito shell, for a little while. I have a helper function for that, which I extended with the following lines:

add-zsh-hook -d precmd _atuin_precmd
add-zsh-hook -d preexec _atuin_preexec

In effect, those two lines unregister the calls to atuin history start and atuin history end for the current shell, until such a time it is closed or the precmd / preexec functions are reinjected somehow.

Reverting is as simple as running these:

add-zsh-hook preexec _atuin_preexec
add-zsh-hook precmd _atuin_precmd

For bash people, disabling would probably look like this (untested, and assuming you're not running an ancient bash version):

preexec_functions=("${preexec_functions[@]/_atuin_preexec}")
precmd_functions=("${precmd_functions[@]/_atuin_precmd}")

And re-enabling should be:

preexec_functions+=(_atuin_preexec)
precmd_functions+=(_atuin_precmd)

Note as well that since Atuin does not prevent the shell's usual history mechanisms, you might want to disable that too. In ZSH I unset HISTFILE, in bash you can set +o history, or in both shells, and if your shell is properly configured, prepending your secret command with a space, are all viable solution.

None of this is as neat as a proper handling of commands prepended by space(s), nor does it solve the use case of "oops I already inserted my sensitive command in the history", but I hope it helps in the meantime.

from atuin.

Something like what @dcarosone could be done pretty easily and would make a good workaround

Supporting actual + proper deletion might prove a little more tricky. The issue lies in the fact that each database is basically just an append-only log, which is pushed between devices. An item of history could be deleted from device A, deleted from the server, but then still reside on device B, and later be pushed back up.

So perhaps we could also maintain a list of IDs that have been deleted, and clients could periodically fetch this. Items could be removed from local history if the item is a member of the list

from atuin.

Any progress on this issue? Fish support has landed already AFAICT :-)

PS: Great tool, but not being able to just get rid of some careless mistyping is very unfortunate.

from atuin.

I kind of suspected that sync would be the problem:-) But great to know that you are on it!

from atuin.

Just to comment on how histdb does this, you just use the switch --forget and you can remove all entries that match the given argument (see below). I'm sure this could be expended to accept time based arguments too if that's desirable. I like this approach since its natural for someone coming from histdb.

mbp16 undef :: ~  » histdb --forget ping 
time   ses   dir                                       cmd
07/03  3592  ~/source/rust                             ping 8.8.8.8
07/03  3592  ~/source/rust                             ping -v 8.8.8.8
04/04  3772  ~                                         ping google.com
24/05  4132  ~                                         ping 8.8.8.8
Forget all these results? [y/n]

@ellie You said that this is in the works, are you still working toward this? I could take a look if you want, but if you're in the midst of a larger change then it can wait. I'm not clear on the scope of this give that there's a server component too, but i could still take a look.

from atuin.

I'm closing this in favour of #592!

from atuin.