Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request: remove or configure opt-out for including CWD/hostname from query #268

Closed
chelmertz opened this issue Dec 14, 2024 · 3 comments · Fixed by #274
Closed

Request: remove or configure opt-out for including CWD/hostname from query #268

chelmertz opened this issue Dec 14, 2024 · 3 comments · Fixed by #274

Comments

@chelmertz
Copy link

chelmertz commented Dec 14, 2024

Hello, thanks for a neat program!

I am frequently launching vscode in a terminal, with variants of: code ~/code/my/project

Searching for that history entry, competes with all other entries made with "code/my/project" and I never get that suggestion, when I search for "code". To work around this, I played around with:

chelmertz@2e7e027

Bonus question: I tried running tests after changing this in my "fork", but the tests worked with the actual ~/.zsh_history et al. files, so I quickly abandoned that. It would be nicer to have a developer guide for installing things without going through the python script -> releases -> figure out what each release contains, just when trying out a small change; but I can imagine the current flow suits your flow of development :)

@roland-5
Copy link

Removing this feature would kill the point of using hishtory for me. I have several machines, but they do different things and without CWD and hostname I would have a problem comparing results and data.

@chelmertz
Copy link
Author

@roland-5 could you explain more? I'm neither suggesting "don't show CWD/hostname in search window" (there's config for that) nor "don't store CWD/hostname with history data".

I'm suggesting "don't match on CWD/hostname by default, without any way of opt-ing out". There is already a way to opt-in for the behavior, quoting hishtory help query:

Example queries:
'hishtory query apt-get'  		# Find shell commands containing 'apt-get'
'hishtory query apt-get install'  	# Find shell commands containing 'apt-get' and 'install'
'hishtory query curl cwd:/tmp/'  	# Find shell commands containing 'curl' run in '/tmp/'
'hishtory query curl user:david'	# Find shell commands containing 'curl' run by 'david'
'hishtory query curl host:x1'		# Find shell commands containing 'curl' run on 'x1'
'hishtory query exit_code:1'		# Find shell commands that exited with status code 1
'hishtory query before:2022-02-01'	# Find shell commands run before 2022-02-01

See the line with cwd:/tmp/.


Are you aware of any way for me to resolve my use case?

ddworken added a commit that referenced this issue Dec 31, 2024
@ddworken
Copy link
Owner

Thank you for all the detailed thoughts and feedback @chelmertz! Your use case makes sense to me, though I'll say I do often find myself searching based on the cwd such that I do like having it included in the query by default. But making this configurable makes perfect sense to me. I can work on a PR for this and will tag you on it.

Though if you are motivated to make the change yourself in the meantime (2e7e027 seems like it is on the right track for that), check out the contributing docs for info on how to run tests.

ddworken added a commit that referenced this issue Jan 18, 2025
* Implement restrictions on default column searching for #268

* Add better docs for config-set excluded-default-search-columns

* Enable debugging

* Clean up server binaries to avoid wasting disk space

* Add tests

* Swap from configuring excluded columns to configuring included columns, to prep for future changes where we may add support for other default columns

* Reduce gotestsum re-runs since tests are less flaky nowadays

* Fix bug in lib.where(...) function that failed to trim the args list and caused DB query correctness issues

* Disable tmate debugging

* Update goldens
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants