Closed taskwarrior closed 6 years ago
Migrated metadata:
Created: 2015-03-12T08:07:06Z
Modified: 2017-08-01T18:08:11Z
Paul Beckingham on 2015-03-14T19:10:22Z says:
This was a feature request, not a bug. Closing because:
I don't think supporting different context in different terminal windows is useful. I don't think staying out of .taskrc because it forces people to update repositories is useful. Any script that uses context, can provide a command line override. I don't think making context fail to survive reboot is useful.
Peter Rochen on 2015-03-24T10:22:17Z says:
All these four issues also affects me.
I'm using not git, but RCS, and this (ci(1)) leaves .taskrc-settings in read-only mode. My .taskrc file contains only one relevant line: include ~/.taskrc-settings So I can switch context several times a day, and task doesn't want to rewrite each time my VCS-ed read-only setting file unsuccessful.
Issue 3: I agree with Tomas, context doesn't need to (always) survive a reboot.
Tomas, using include solves also two of your cases: Issue 4: "Users that store .taskrc in .dotfiles git repo, wouldn't get false positive messages about .taskrc being modified" And maybe Issue 2, too: "Bash scripts that use context would not step on each other's toes if run concurrently in different shells (i.e. executed via cron)"
Issue 1: To different context in different tmux windows, there are the old methods: different HOME different TASKRC and data_location local-task.sh (TW-514) scripting creating reports
Tomas, how do you do workarounded these situations? Or do you not using the context feature anymore?
Peter Rochen on 2015-03-24T10:28:07Z says:
Summary: I satisfied my aforementioned "workaround".
Tomas Babej on 2015-03-24T14:45:31Z says:
Yes, creating a different taskrc file per environment where you want to have the context applied would work, it's just a quite a overkill of a hack. I ended up using the context feature less than I suspected.
Ivan Čukić on 2016-02-21T15:15:14Z says:
Although this one is closed as wontfix, if somebody needs this and does not mind manually patching the sources, here is the diff to the current master (I'm pondering whether I should make diffs for the stable versions instead...).
The patch allows the user to override the current context by specifying the TASK_CONTEXT environment variable.
This could be made nicer, but this way the patch changes already existing files as little as possible.
diff --git a/src/CLI2.cpp b/src/CLI2.cpp index 6e37b11..710dbb6 100644
+#include
// Overridden by rc.abbreviation.minimum. @@ -608,7 +610,7 @@ void CLI2::addContextFilter () return;
// Detect if any context is set, and bail out if not
+#ifndef CURRENTCONTEXT_H +#define CURRENTCONTEXT_H
+inline std::string getCurrentContext (Context &context) +{
+#endif / !CURRENTCONTEXT_H / diff --git a/src/commands/CmdContext.cpp b/src/commands/CmdContext.cpp index ac168bd..a61b0b1 100644
+#include
////////////////////////////////////////////////////////////////////////////////
@@ -201,6 +203,8 @@ int CmdContext::deleteContext (const std::vector
// If the currently set context was deleted, unset it
// but the actual configured value std::string currentContext = context.config.get ("context");
if (currentContext == words[1]) @@ -247,7 +251,7 @@ int CmdContext::listContexts (std::stringstream& out) Color label (context.config.get ("color.label")); view.colorHeader (label);
std::string activeContext = getCurrentContext (context);
for (auto& userContext : contexts)
{
@@ -323,7 +327,7 @@ int CmdContext::setContext (const std::vector
std::string currentContext = getCurrentContext (context);
if (currentContext == "") out << STRING_CMD_CONTEXT_SHOW_EMPT << "\n";
Paul Beckingham on 2016-02-21T15:20:32Z says:
Ivan - I think your patch (above) needs either to be added as an attachment, or surrounded by "```" markers, to preserve the formatting.
Paul Beckingham on 2016-02-21T15:21:18Z says:
I meant "{ n o f o r m a t }" markers (remove the spaces)
Ivan Čukić on 2016-02-21T15:35:51Z says:
Thanks, I realized that formatting ruined it a bit late - and tried , backticks.
I've also set up a temporary fork at evil github at https://github.com/ivan-cukic/taskwarrior-fork
diff --git a/src/CLI2.cpp b/src/CLI2.cpp
index 6e37b11..710dbb6 100644
* -- a/src/CLI2.cpp
+++ b/src/CLI2.cpp
@@ -35,6 +35,8 @@
1. include <util.h>
1. include <i18n.h>
+#include <CurrentContext.h>
+
extern Context context;
// Overridden by rc.abbreviation.minimum.
@@ -608,7 +610,7 @@ void CLI2::addContextFilter ()
return;
// Detect if any context is set, and bail out if not
* std::string contextName = context.config.get ("context");
+ std::string contextName = getCurrentContext (context);
if (contextName == "")
{
context.debug ("No context.");
diff --git a/src/CurrentContext.h b/src/CurrentContext.h
new file mode 100644
index 0000000..8dc7982
* -- /dev/null
+++ b/src/CurrentContext.h
@@ -0,0 +1,20 @@
+/*
+ * CurrentContext.h
+ * Copyright (C) 2016 Ivan Čukić <ivan.cukic(at)kde.org>
+ *
+ * Distributed under terms of the MIT license.
+ */
+
+#ifndef CURRENTCONTEXT_H
+#define CURRENTCONTEXT_H
+
+inline std::string getCurrentContext (Context &context)
+{
+ // If the currently set context was deleted, unset it
+ const char * currentContextOverride = getenv ("TASK_CONTEXT");
+
+ return currentContextOverride ? std::string (currentContextOverride)
+ : context.config.get ("context");
+}
+
+#endif /* !CURRENTCONTEXT_H */
diff --git a/src/commands/CmdContext.cpp b/src/commands/CmdContext.cpp
index ac168bd..a61b0b1 100644
* -- a/src/commands/CmdContext.cpp
+++ b/src/commands/CmdContext.cpp
@@ -35,6 +35,8 @@
1. include <CmdContext.h>
1. include <CmdConfig.h>
+#include <CurrentContext.h>
+
extern Context context;
////////////////////////////////////////////////////////////////////////////////
@@ -201,6 +203,8 @@ int CmdContext::deleteContext (const std::vector <std::string>& words, std::stri
rc = CmdConfig::unsetConfigVariable(name, confirmation);
// If the currently set context was deleted, unset it
+ // We are not using the environment variable override here,
+ // but the actual configured value
std::string currentContext = context.config.get ("context");
if (currentContext == words[1])
@@ -247,7 +251,7 @@ int CmdContext::listContexts (std::stringstream& out)
Color label (context.config.get ("color.label"));
view.colorHeader (label);
* std::string activeContext = context.config.get ("context");
+ std::string activeContext = getCurrentContext (context);
for (auto& userContext : contexts)
{
@@ -323,7 +327,7 @@ int CmdContext::setContext (const std::vector <std::string>& words, std::strings
//
int CmdContext::showContext (std::stringstream& out)
{
* std::string currentContext = context.config.get ("context");
+ std::string currentContext = getCurrentContext (context);
if (currentContext == "")
out << STRING_CMD_CONTEXT_SHOW_EMPT << "\n";
Tomas Babej on 2016-03-08T15:36:38Z says:
Thanks for taking the time to implement this, works quite nice. Finally I can incorporate context into my tmuxinator setup :)
Wael Nasreddine on 2017-06-27T17:11:41Z says:
(at)paul I'm trying to understand your reservation over this feature, can we agree on a middle ground? Perhaps allow overriding of context via the environment variable on top of setting it in the taskrc file?
My use case is that I use a concept of profiles for my shell, so when I switch to personal (or work), all my tools (Git, AWS, etc..) gets affected. I would like to be able to switch the context using an environment variable regardless of what is the persistent context is (which would be none for me)
Wael Nasreddine on 2017-06-27T18:11:40Z says:
For anyone using the patch, I've updated for Task 2.5.2 and hosted it in the AUR package (Arch Linux) task-context-env here https://aur.archlinux.org/cgit/aur.git/tree/env.patch?h=task-context-env
Paul Beckingham on 2017-06-28T01:41:39Z says:
For any readers: There is no Taskwarrior 2.5.2 release, the patch is not merged, has not been tested and is not supported.
Wael Nasreddine, I would appreciate you not misrepresenting our work. Please withdraw that package.
Wael Nasreddine on 2017-06-28T03:28:23Z says:
(at)paul that was a typo, I meant 2.5.1 release, and the package released on the open Arch Linux User Package repository, I'm not trying to hack anyone! Please see it here https://aur.archlinux.org/packages/task-context-env/
As for the patch itself, it's Ivan Čukić's patch rebased for 2.5.1 release.
Are you open to discuss possible implementation or should I not bother and maintain it myself?
Wael Nasreddine on 2017-06-28T05:40:18Z says:
This was discussed on IRC (see log [here|https://botbot.me/freenode/taskwarrior/2017-06-28/?msg=87870774&page=1]). The patch is really unnecessary as it can be easily achieved with a shell function like the one following.
{code} function task() { command task rc.context=personal "$@" } {code}
Paul Beckingham on 2017-06-30T00:03:53Z says:
Nice. Thanks Wael!
Just a little more on this to help others who may not be super proficient with bash (like me).
You can do:
function task() {
command task rc.context=$TWCONTEXT "$@"
}
Then on the command line:
TWCONTEXT=peronsal
or TWCONTEXT=work
, etc.
Version 2.6 makes progress here
Environment variables are supported in .taskrc
, so you can do e.g.
context=$TW_CONTEXT
Alongside this, version 2.6 will write elements of your current context to tasks as discussed in #1955 ;
Combined with a means of setting environment automatically per folder like direnv
you can do task add
in a folder and have it pick up the tags and attributes for a specific context linked to the folder.
Because of these new features it would still be nice if you could override context with an environment variable though ; this means you could switch context views in a task shell like vit
which reconfigures the context variable in .taskrc
but still have e.g. task add
drop tasks into a context defined by the folder you are in, and task next
do the same ; just report stuff relevant to a context you're in because of where your shell is.
Maybe a separate read and write context would be nice as well, now that context implies setting attributes and tags on tasks.
Tomas Babej on 2015-03-12T08:07:06Z says:
Currently, the context is stored in a configuration variable in .taskrc. This has the guarantee of only one context being set at a time on one machine.
However, there are use cases where storing context in a environment variable might be preferable:
EIther storing context in .taskrc or in environment variable should be supported, not both. A configration setting, e.g rc.contextstore with possible values of "configuration" and "environment" (defaulting to current behaviour, that is "configuration") should set the context store being used.