#taskwarrior

/

      • djp
        pbeckingham: as if!
      • f1gm3nt has quit
      • f1gm3nt joined the channel
      • MZAWeb has quit
      • diyfupeco has quit
      • diyfupeco joined the channel
      • MZAWeb joined the channel
      • jrabbit has quit
      • nkvd is now known as jrabbit
      • bqf: I changed my mind about a task-export-agenda report,I think this would be easier and better; https://github.com/linuxcaffe/tw-effective-date...
      • a simpler means to the same ends, I hope :) better because the proposed date uda can be used in a number of ways, obviating the need for an export-->agenda report endless tweaking
      • danielsh
        .oO ( task add -- check out task +LATEST )
      • pbeckingham
        danielsh: It's the simplest possible implementation, as an experiment.
      • pbeckingham has quit
      • pbeckingham joined the channel
      • jrusnack joined the channel
      • jrusnack has quit
      • jrusnack joined the channel
      • jrusnack has quit
      • gour joined the channel
      • bqf
        pbeckingham / tbabej: there are ways to a) check that two colors will be readable when used as foreground+background and b) make them readable by adjusting them if they are not. that gets harder with misbehaving terminals of course, but it would still be better than the current situation.
      • djp: simpler - not really, no. you even mention in your "specs" that apart from the hook(s), a tool to run it on your data manually would be needed. that's three things to test - on-add hook, on-modify hook, and external tool.
      • not saying it's hard, but it is not simpler than outputting a list of UUIDs.
      • MZAWeb has quit
      • tbabej
        pbeckingham: Alright then. I will find time to implement it, then we can decide what to do with it.
      • My suggestion would probably be to let merge be on by default, and put merge=off to the color themes definitions that we know have cases that do not work well.
      • bqf: What ways?
      • lydgate joined the channel
      • bqf
      • brought to you by the "will take a bit of time to get right and is probably overkill, but it sure would be nice" department.
      • tbabej
        bqf: That link seems to compute the background as a function of foreground. That would not work for our use case.
      • Foreground colors should already be readable on the default background, otherwise the color theme makes no sense.
      • If you compute the background as a function of foreground, than it has no additional value, since it carries no extra information.
      • bqf
        tbabej: that link was just an example. what i was trying to get at is that you can tell whether two colors are far enough apart on the visible spectrum to be used as foreground and background color. it was not a link meant for you to copy&paste code. :)
      • tbabej
        bqf: Pity. I overestimated your abilities, yet again.
      • gour
        morning all
      • tbabej: you're behind taskwiki which uses vimwiki, so i'm curious if the latter has some capabilities to quickly jump/indent/etc. within outline, something like org-mode?
      • tbabej
        gour: Oh, I am by no means a vimwiki expert.
      • gour: There's :help vimwiki to advise you, I guess - or djp.
      • gour
        ok, let me install it 1st
      • deitario1 joined the channel
      • deitarion has quit
      • zacts has quit
      • zacts joined the channel
      • i bet that reST plugin (riv) will serve my purpose better
      • fruehwir joined the channel
      • Haudegen has quit
      • Haudegen joined the channel
      • gour_ joined the channel
      • gour has quit
      • gour_ is now known as gour
      • eliasp has quit
      • eliasp joined the channel
      • paul__ joined the channel
      • paul__ is now known as pauby
      • pauby
        Anybody help with tips on '504 Request too big' error when syncing task list with server?
      • rivarun has quit
      • rivarun joined the channel
      • Is there antyhing you can add to make taskwarrior client sync only batches of changes to the server?
      • pauby has quit
      • pbeckingham
        pauby: There is a configurable request size limit. Change it and restart the server. See 'man taskdrc'.
      • f1gm3nt has quit
      • pbecking1 joined the channel
      • pbeckingham has quit
      • djp
        tbabej: --> msg
      • gour: I too pine for robust outlining in [vim|task]wiki
      • tbabej
        djp: gour: What exactly are you guys missing? Never used org-mode.
      • I recently thought that it would be useful if I could mark some headers explicitly as folded on open.
      • djp
        the best test-outliner I ever used was on a ROM chip for a Model100 ion the 1980's
      • tbabej: I think what's missing is the handlinks of the headers, the ability ti easily manipulate items in a hierarchy
      • taskwiki's dep hierarchy has the right shape, just not the right manipulation handles
      • gour
        tbabej: i use rst markup for other things, so riv plugin is better option for me
      • tbabej
        djp: Not sure what's that supposed to mean.
      • djp
        :)
      • tbabej
        djp: Craft more self-explainable examples and we will discuss :)
      • djp
        tbabej: then you've never been a text-mode-outliner user
      • proof of concept here is beyond my meager abilities, best I can do is point to examples
      • tbabej
        djp: Might be there are lands I yet have to explore - I'm still young you know.
      • djp: That's what I meant. File some issues with examples, then we can discuss.
      • djp
        tbabej: it's more about a users mode of thinking (hierarchical) I do have some examples in the wild to point to
      • tbabej: (changes subject) you gonna try my color themes?
      • tbabej
        djp: I have solarized colors in my terminal, so I guess your color schemes will produce broken results for me.
      • pbecking1
        tbabej: It will likely break if it uses the lower 16, yes. Those generally get remapped by Solarized. The other 240 don't.
      • f1gm3nt joined the channel
      • tbabej
        pbecking1: Thanks for the feedback. Will get back later.
      • (regarding the color merge patch)
      • pbecking1: Btw, I noticed that completion commands are context sensitive. Do you remember if this has been always the case / if there has been a discussion about this?
      • pbecking1
        tbabej: Completion: Not necessarily always the case - do not recall. Now al commands are obeying the "DNA" shown in the "task commands" output. It's an easy to read table, so we can compare all commands and adjust.
      • So if you see something amiss in there, let's talk. I *believe* I captured the state correctly when I did this, but there could be mistakes.
      • tbabej
        pbecking1: I am currently in 'project:Work' context, and wanted to add a task in 'Taskwarrior' project. Started typing task add pro:Ta<Tab> - Completion did not work.
      • pbecking1: So this is all correct according to the source - no bugs.
      • What I am wondering if this is the behaviour we want - should offer options for metadata outside of context when adding, or not?
      • pbecking1
        No, not "correct", it seems. We need to adjust.
      • I'm guessing completion should be exempt from context.
      • Maybe all helpers.
      • tbabej
        pbecking1: Yeah, that's about my standpoint too, but I did not do a lot of thorough thinking yet.
      • Nevertheless, I find it kind of funny that after nearly a year of using TW, I just realized that urgency is a genious thing after all.
      • pbecking1
        tbabej: Interesting. There are several subtle features that are not obvious to new users.
      • It's one reason why I don't pay attention to new users who think things need to change. They need to absorb some of it first.
      • tbabej
        pbecking1: Well, it took me some time to become comfortable with surrendering my decision making to the sentient machines :)
      • pbecking1
        Afterwards, they have context, and the opinions carry more weight.
      • tbabej
        pbecking1: My turning point was when I realized I really do spend a lot of time choosing what to do, and the choices are often suboptimal.
      • pbecking1
        \o/ Good news tbabej.
      • Everyone agrees that priority H tasks should probably be done before priority L tasks. Probably. Urgency captures that (and more), so therefore if you try to stick to doing tasks near the top of the list, you're probably doing the right thing.
      • bqf
        tbabej: good, good. now come to the dark side by setting blocked and blocking coefficient to 0, then enabling urgency.inherit. "L" priority to -0.5 helps as well.
      • tbabej
        bqf: Yep, I did that.
      • Lynoure
        bqf: that does not sound like the dark side at all, more like enlightenment
      • tbabej
        I also set 0 to most of the other stuff as well, as project or tag urgency.
      • pbecking1: On a related not, +next special treatment for urgency can be replaced by a configuration entry, no?
      • bqf
        tbabej: i actually still have those at their default values, they don't bother me as much as blocked and blocking.
      • Lynoure: i should mention that you then also need to add a +READY filter to "next", or whatever report you prefer running that sorts by urgency. with blocked and blocking coefficients at 0 and urgency.inherit active, the next report gets ugly if you don't.
      • that reminds me, did i ever ask why +READY is not a default filter for "next"? surely a task does not deserve to be in a "next" report if it can't actually be completed right now.
      • tbabej
        bqf: I guess +READY came later than 'task next'
      • bqf: But yeah, you're probably right.
      • pbecking1
        tbabej: If you set too many coefficients to zero, it degenerates into the sort provided by the "list" report. Just saying.
      • bqf: +READY is new. Filters are old.
      • bqf
        pbecking1: tasks with more tags being arbitrarily sorted above ones with less tags does not make the report better. just saying. :)
      • pbecking1
        bqf: Maybe for you. I like it. Fortunately it's configurable.
      • bqf
        pbecking1: well, "status:pending -BLOCKED" then? not sure how old BLOCKED is :)
      • pbecking1
        Well, virtual tags are relatively new, so ...
      • Also: "status:pending -BLOCKED" could be "+PENDING -BLOCKED", if you want readability.
      • tbabej
        Virtual tags are here since 2.4.0 or 2.3.0, so quite new. Nevertheless, let's discuss if and how to change stuff, not the history :)
      • bqf
        pbecking1: yeah, exactly. everyone prefers different things. i like my tasks to be sorted by stuff that is actually relevant - priority, due dates, things like that. although i have found that the age coefficient is actually pretty decent at making sure i don't let tasks linger too long.
      • tbabej
        Yeah, age coefficient is cool.
      • nitefall joined the channel
      • MZAWeb joined the channel
      • djp
        imho, the next report has been due for a shakeup for some time, based on the meaning of the word "next"
      • sure, highest urgency is a (the?) primary factor, but in selecting what to do "next" everything that _can't_ be done next should be filtered out
      • I use: report.next.filter +PENDING and ( scheduled.none: or scheduled.before:now ) and ( +next or +TODAY or +OVERDUE or due.before:today-2days or priority:H or +ACTIVE) -BLOCKED -WAITING limit:10
      • which ain't perfect, now that I look at it :)
      • tbabej
        what the heck djp
      • djp
        my holy grail is the reduction of a 200+ task list to those items I really must do _next_
      • (context helps)
      • tbabej: yeah, it's a brutally constructed filter, I'll clean it up
      • bqf
        djp: that filter reads like a window into your mind.
      • viq has quit
      • viq joined the channel
      • djp
        bqf: indeed, that said, a context-filtered list report is my "go to"
      • that is, until I can realize "agenda"
      • pbecking1
        djp: "reduction of a 200+ task list to those items I really must do" - this will be the driving force behind dismissing and closing a whole boatload it Jira issues. Good that you grok this now, because your name is on a lot of it. Not personal - got to make it manageable.
      • djp
        pbecking1: I get that, I always "grokked it" jus hope you try and wrap your head around the concepts before closing
      • pbecking1
        djp: Yep. Gotta clear some more deadwood though. Also, I think we no longer want so many duplicates, so I'll be merging and closing those too.
      • djp
        go for it. some propose upcoming feature, as well as external projects, should chop through a lot of that. I can always mine the reject-pile for old ideas revisited :)
      • harleypig
        is there a way to do case insensitive searching? I'm not finding anything in the man page or online docs, especially the 'searching' doc, I tried task '/foo/i' term but that didn't work.
      • Is the search engine pcre?
      • I even tried task '/(?-i:term)/' list
      • danielsh
        % task show | grep case
      • search.case.sensitive yes
      • So I guess task rc.search.case.sensitive:no <filter args>
      • harleypig
        feh ... didn't think to look in configuration