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

Ignore selection based on pattern #64

Closed
fdw opened this issue Sep 18, 2017 · 8 comments
Closed

Ignore selection based on pattern #64

fdw opened this issue Sep 18, 2017 · 8 comments

Comments

@fdw
Copy link

fdw commented Sep 18, 2017

I'm using clipster with rofi and loving it so far. So, thank you very much for your work :)

I recently noticed that I have a lot of entries that follow a certain pattern and that I don't want to save. However, I cannot find a configuration value to ignore a selection change based on a pattern. Have I overlooked something? Would it be possible to implement something like this?

Thanks again!

@mrichar1 mrichar1 reopened this Dec 15, 2017
@mrichar1
Copy link
Owner

mrichar1 commented Dec 15, 2017

Hi - sorry for the delay in looking at this!

I've added an ignore_patterns option - if this is enabled, then regular expression patterns will be read from data_dir/ignore_patterns (usually .local/share/clipster/ignore_patterns) one-per-line.

So for example:

politic
^cat(s)?$

Will ignore all selections containing the string politic and cat or cats (but not catches or scat).

Let me know if this is enough to solve your issue, or if you encounter any problems with this change. Thanks!

@fdw
Copy link
Author

fdw commented Dec 15, 2017

Hi @mrichar1,
I haven't tested it yet, but it looks perfect! Thank you very much! 😊

Do you think it would be a good idea to make the path/filename of the ignore-file configurable? You could even fold that into the ignore_patterns option - if ignore_patterns_from is set, load the patterns from the option's parameter. If it is not set, no patterns are ignored.

@mrichar1
Copy link
Owner

clipster follows the Freedesktop XDG specifications: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

Thus the history, patterns (for extract_patterns) and now ignore_patterns files are all stored in either $XDG_DATA_HOME/clipster (or ~/.local/share/clipster if this is unset).

So you can override the data directory by setting the $XDG_DATA_HOME environment variable when launching the clipster daemon to provide a different directory for these files.

I'd probably only consider changing how this works if there was a good reason to split the locations for the pattern and history files.

@fdw
Copy link
Author

fdw commented Dec 15, 2017

This was exactly my reason for asking: In my opinion, these patterns should be in $XDG_CONFIG_HOME (seeing as they're config files) rather than $XDG_DATA_HOME. However, I can live with both 😊

@mrichar1
Copy link
Owner

You're right actually - I'm not sure why they're in $XDG_DATA_HOME when they're config, unlike history socket pid etc which are created by the daemon.

I'll open a new issue for this. Thanks!

@mrichar1
Copy link
Owner

Following on from #65 - in refactoring conf_dir I decided after all to add *_file config options for extract_patterns and ignore_patterns (with sensible defaults) to match history, socket etc. I decided to keep the enabling and file paths options separate, to make setting defaults and toggling state easier without having to remove files etc. The default paths are now under conf_dir which in turn inherits from$XDG_CONFIG_HOME, as you correctly pointed out.

Let me know whether this refactored version solves your original issue, and lets you override the config as requested (comments here or in #65 as appropriate). Thanks!

@fdw
Copy link
Author

fdw commented Dec 16, 2017

Thank you so much, it works perfectly!

I now have the ignore_patterns file in .config/clipster, so I couldn't be happier. :)

@mrichar1
Copy link
Owner

Thanks for the suggestions and for testing!

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

No branches or pull requests

2 participants