-
Notifications
You must be signed in to change notification settings - Fork 713
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
ENH: Allow to customize what can be before / inside / after +project and @context #271
Merged
karbassi
merged 7 commits into
todotxt:master
from
inkarkat:enh-configurable-sigil-patterns
Mar 30, 2020
Merged
ENH: Allow to customize what can be before / inside / after +project and @context #271
karbassi
merged 7 commits into
todotxt:master
from
inkarkat:enh-configurable-sigil-patterns
Mar 30, 2020
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…and @context I noticed that todo.sh mistakenly picks up some random stuff as projects and contexts. The todo.txt specification is very lenient in what makes those (allowing any length of non-whitespace characters), but in practice, every user has its own idea of the set of used words. This change allows (expert) users to tweak the pattern (via TODOTXT_SIGIL_VALID_PATTERN), to be able to reduce the amount of "false positives" that listproj and listcon show. Additionally, there's a (mainly unspecified) extension mechanism in the form of key:value, which often is used to implement custom "markers", like w:something to make a task blocked and waiting for "something". It would be nice to be able to refer to @contexts (and maybe also +projects), but the default syntax (which requires whitespace around those) doesn't allow it, and these context then don't show up in searches, which is unfortunate. The added TODOTXT_SIGIL_BEFORE_PATTERN and TODOTXT_SIGIL_AFTER_PATTERN allow to tweak the syntax to accommodate this. The implementation just exchanges grep with a corresponding sed pipeline step, which shouldn't negatively affect the performance at all (as sed is one of the main commands used thoughout the script), but which allows for the additional matching flexibility.
inkarkat
force-pushed
the
enh-configurable-sigil-patterns
branch
from
September 14, 2019 19:57
6bc5b60
to
fcc083f
Compare
@inkarkat it failed the test on macOS. Take a look. |
Use the POSIX \{0,1\} instead.
Concatenate both alternatives as optional matches; this is only an approximation but satisfies the test case here. It would probably be better if the entire sed code used extended regular expression syntax (-E) instead of basic ones (-e), but that change would also affect all add-ons. As this is an optional customization feature, uses who really need this either also have to work around, or supply a GNU sed port on MacOS.
Use the POSIX \{1,\} instead.
@karbassi Again those pesky compatibility problems. Fixed. |
karbassi
approved these changes
Mar 30, 2020
wwalker
pushed a commit
to wwalker/todo.txt-cli
that referenced
this pull request
Sep 19, 2021
…and @context (todotxt#271) * ENH: Allow to customize what can be before / inside / after +project and @context I noticed that todo.sh mistakenly picks up some random stuff as projects and contexts. The todo.txt specification is very lenient in what makes those (allowing any length of non-whitespace characters), but in practice, every user has its own idea of the set of used words. This change allows (expert) users to tweak the pattern (via TODOTXT_SIGIL_VALID_PATTERN), to be able to reduce the amount of "false positives" that listproj and listcon show. Additionally, there's a (mainly unspecified) extension mechanism in the form of key:value, which often is used to implement custom "markers", like w:something to make a task blocked and waiting for "something". It would be nice to be able to refer to @contexts (and maybe also +projects), but the default syntax (which requires whitespace around those) doesn't allow it, and these context then don't show up in searches, which is unfortunate. The added TODOTXT_SIGIL_BEFORE_PATTERN and TODOTXT_SIGIL_AFTER_PATTERN allow to tweak the syntax to accommodate this. The implementation just exchanges grep with a corresponding sed pipeline step, which shouldn't negatively affect the performance at all (as sed is one of the main commands used thoughout the script), but which allows for the additional matching flexibility. * FIX: Compatibility: sed \? multi not supported on MacOS Use the POSIX \{0,1\} instead. * FIX: Compatibility: sed \| multi not supported on MacOS Concatenate both alternatives as optional matches; this is only an approximation but satisfies the test case here. It would probably be better if the entire sed code used extended regular expression syntax (-E) instead of basic ones (-e), but that change would also affect all add-ons. As this is an optional customization feature, uses who really need this either also have to work around, or supply a GNU sed port on MacOS. * FIX: Compatibility: sed \+ multi not supported on MacOS Use the POSIX \{1,\} instead. Co-authored-by: Ali Karbassi <ali@karbassi.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I noticed that todo.sh mistakenly picks up some random stuff as projects and contexts. The todo.txt specification is very lenient in what makes those (allowing any length of non-whitespace characters), but in practice, every user has its own idea of the set of used words. This change allows (expert) users to tweak the pattern (via
TODOTXT_SIGIL_VALID_PATTERN
), to be able to reduce the amount of "false positives" that listproj and listcon show.Additionally, there's a (mainly unspecified) extension mechanism in the form of key:value, which often is used to implement custom "markers", like
w:something
to make a task blocked and waiting for "something". It would be nice to be able to refer to@contexts
(and maybe also+projects
), but the default syntax (which requires whitespace around those) doesn't allow it, and these context then don't show up in searches, which is unfortunate. The addedTODOTXT_SIGIL_BEFORE_PATTERN
andTODOTXT_SIGIL_AFTER_PATTERN
allow to tweak the syntax to accommodate this.The implementation just exchanges grep with a corresponding sed pipeline step, which shouldn't negatively affect the performance at all (as sed is one of the main commands used thoughout the script), but which allows for the additional matching flexibility.
Before submitting a pull request, please make sure the following is done:
master
.fixes #XX
reference to the issue that this pull request fixes. No existing issue