#taskwarrior

/

      • ToxicFrog
        xcm: note that depending on your setup you may need to run tmux as `tmux -2` for it to report 256-colour support
      • (at which point it will self-report as `screen-256color` in $TERM)
      • That's generally the first thing I check when I'm having a tmux colour disaster and 90% of the time that's the problem.
      • svij has quit
      • svij joined the channel
      • govg has quit
      • task-git
        *** Taskwarrior - commit 7af6db4 in "2.6.0", Mark Scannell: Portability: Updated to make main re-entrant()
      • morethantwo joined the channel
      • ToxicFrog
        Is there a detailed breakdown of what exactly the verbose:blank setting controls? The most obvious effect is that it inserts an extra blank line at the end of output, which doesn't really help with clarity at all, but I'm wondering if by turning it off I might be losing other stuff I do want.
      • pbeckingham
        ToxicFrog: man taskrc
      • ToxicFrog
        pbeckingham: yes, I did that first. The man page's information on that setting, in full: "blank Inserts extra blank lines in output, for clarity"
      • pbeckingham
        Right, my point being that's what it does.
      • ToxicFrog
        Right, but where are these lines inserted? What, apart from the trailing newline, am I losing out on by turning it off that may not be immediately obvious in (e.g.) `task next`?
      • pbeckingham
        Have you tried turning it off and on again, and seeing the difference? Otherwise the answer is to read the code.
      • ToxicFrog
        Yeah, and it looks like it inserts a leading and trailing newline in report output; I'm just wondering if there's other behaviour that is only evident in some reports. I'll RTFS.
      • paininabox has quit
      • andrey_utkin has left the channel
      • Hmm. rc.indent.annotation only affects the first line of each annotation.
      • govg joined the channel
      • paininabox joined the channel
      • And it looks like you can set a multiline value for a field using `task modify` but not using `task edit`.
      • ...also, putting a trailing \ on a line in `task edit` corrupts the completed.data in ways that `task undo` won't reverse. Sweet.
      • pbeckingham
        Submit a bug!
      • xcm has quit
      • xcm joined the channel
      • morethantwo joined the channel
      • ddeimeke has quit
      • ddeimeke joined the channel
      • morethantwo joined the channel
      • gour joined the channel
      • morethantwo joined the channel
      • rjc has quit
      • morethantwo joined the channel
      • Haudegen joined the channel
      • xcm has quit
      • xcm joined the channel
      • paininabox has quit
      • rjc joined the channel
      • titaa joined the channel
      • titaa
        I was in here the other day with a question about tasks being locked from editing. Figured it would be a good idea to check back and say it's got a very simple solution. :D
      • There's a temp file created in the ~/.task folder that prevents further editing. Removing that, and adding "editor=vim" or whichever editor in .taskrc fixes the locked task and future problems.
      • (my system doesn't have any references to vi, just vim)
      • titaa has quit
      • morethantwo joined the channel
      • morethantwo has quit
      • morethantwo joined the channel
      • morethantwo has quit
      • bstinson has quit
      • bstinson joined the channel
      • netvor_ joined the channel
      • gour_ joined the channel
      • gour has quit
      • gour_ is now known as gour
      • JuanDaugherty joined the channel
      • woshty joined the channel
      • D630 joined the channel
      • Haudegen joined the channel
      • D630 has quit
      • ToxicFrog
        pbeckingham: yep, just want to create a minimal repro first
      • bexelbie joined the channel
      • bexelbie
        re: taskwiki - does not not work to intermix taskwiki and task cli usage? a task added via the cli refuses to appear in the wiki page
      • paininabox joined the channel
      • ToxicFrog
      • I've added a comment with the output when this script is run, and the contents of pending.data before and after it goes wrong.
      • martylake[m]
        bexelbie: what if you close and open your buffer again?
      • govg joined the channel
      • pbeckingham
        ToxicFrog: Good info. Ready for a bug.
      • ToxicFrog
        pbeckingham: alright, will file one when I have time to sign up for a new account, hopefully later today
      • pbeckingham
        Merci TF
      • ToxicFrog
        File as "critical" for "loss of data"?
      • xcm has quit
      • xcm joined the channel
      • Oh sweet, I just found an even simpler repro: `task ... annotate \\`
      • ...and if I do that, not only does it corrupt pending.data, but `task list` asserts!
      • ToxicFrog revises the reproduction script
      • pbeckingham
        ToxicFrog: Perect. Thanks for doing that.
      • ToxicFrog
        You're welcome.
      • fujisan joined the channel
      • There's some non-data-corruption around multiline entry weirdness that I need to nail down well enough to file a bug report for that, too.
      • Like, a literal "\n" in `task edit` turns into a newline, at least in some fields, but it doesn't roundtrip; if you `task edit` again you get a literal newline in the file, and saving *that* unmodified discards all lines after the first for that field.
      • pbeckingham
        Good catch.
      • ToxicFrog
        Conversely, if you put a \n in the value of `task modify`, you get exactly those characters in the task, but you can embed actual newlines in the modify command and those will get properly written to the task.
      • (but if the first line has no whitespace in it, other kinds of funkyness happen; still investigating that)
      • I can turn all my multiline field experimentation into bug reports as well if you like, but that's going to be a while because I have to do a systematic investigation of where and how the wheels come off.
      • (the actual goal here was just to be able to have an "author" UDA that doesn't eat the entire terminal when listing a book with 4+ co-authors)
      • pbeckingham
        ToxicFrog: Understood, multi-field wrapping would be nice. It's not excessively hard, it just hasn't been done. Most of the support for it is there.
      • ToxicFrog nods
      • ToxicFrog
        Multifield wrapping would be great, but I think I might want something like this even if it were done now, since e.g. with an author field I'd want to it to wrap at the breaks between author names, rather than wherever's typographically optimal.
      • Embedded newlines in fields do seem to work well as long as I'm very, very careful with subsequent invokations of `edit` on those entries.
      • Alternate idea: let on-exit hooks modify the tasks in order to alter what will be displayed (or add an on-display hook for that purpose).
      • pbeckingham
        on-exit: I think we have something better coming to handle this.
      • ToxicFrog
        Awesome.
      • A lot of this experimentation with multiline field values goes away if I can just (e.g.) use '&' in the field value and then have an on-display filter that turns that into actual newlines after the tasks are selected but before the report is typeset.
      • pbeckingham
        What we really need is a function that can be given a std::string&, and return the next good break point. Difficult to do well.
      • ToxicFrog
        For automatic wrapping of arbitrary fields, you mena?
      • pbeckingham
        Getting optimal break points is too expensive - you have to scan all tasks, all text fields, and find the longest break point to determine the minimum column width. All before rendering a single task.
      • Yes, it's a needed function to even begin to do it right.
      • With description, that's easy because you just look for spaces. Not so easy with arbitrary text.
      • ToxicFrog nods
      • ToxicFrog
        For my part, I'm not even attempting that; I just want to be able to explicitly add breakpoints to field values.
      • pbeckingham
        Got it. I'm always trying to generalize things.
      • ToxicFrog
        Oh, right, that's the weirdness -- if there's no whitespace in the first line, it doesn't interpret it as a field setting, but as setting the description.
      • So if you do this:
      • task 1 edit author:"Kelly Weinersmith
      • Zach Weinersmith"
      • it works fine, but if you do this:
      • task 1 edit author:"Kelly
      • Zach"
      • It leaves the author field alone and sets the description to "author:Kelly\nZach"
      • That's probably worth a bug report as well, no?
      • If you embed literal backspace characters in the field it gets super confused but that's probably not worth a bug report.
      • pbeckingham
        Yes, that's a different flavor of bug.
      • Agreed, literal backspaces is unreasonable use, no bug.
      • ToxicFrog
        Embedding `CSI -1 a` and then `task list` makes it hang at 100% CPU :D
      • Ok, I'll file a bug for modify not playing nice with (some) multiline values.
      • pbeckingham
        ToxicFrog: You wouldn't be heading to FOSDEM this weekend would you?
      • ToxicFrog
        pbeckingham: afraid not
      • pbeckingham
        Too bad.
      • ddeimeke
        pbeckingham: When will you start your trip?
      • pbeckingham
        Anyone here who is heading to FOSDEM, look for the taskwarrior log on shirts, and come say hi.
      • ddeimeke: Heading to airport in 3h. Probably installed at the usual place by noon tomorrow.
      • ddeimeke: You?
      • ddeimeke
        pbeckingham: Touch down in Brussels 2:30 PM and somewhat later at the usual place.
      • ToxicFrog
        Some of my co-workers are, but I was originally planning to be out of the country in a few weeks, and FOSDEM immediately prior would be too much travel. Perhaps next year.
      • pbeckingham
        ddeimeke: Excellent. The bar tab will be open by then.
      • ToxicFrog: Next year? Sounds likely to me.
      • ddeimeke
        ToxicFrog: Glad to meet you.
      • pbeckingham: This year we need to take more photos ...
      • pbeckingham: ... of pizzas of course.
      • pbeckingham
        ddeimeke: I was thinking more beer.
      • svij
        four cheese pizza to be precise
      • pbeckingham
        svij: Don't forget the extra garlic.
      • ddeimeke
        pbeckingham: Yes, you are paying, so doubling the "yes".
      • svij
        pbeckingham: true
      • ddeimeke
        svij: ... with extra cheese ...
      • svij
        I'll be around 5-6pm I think. We're leaving from work at around ~3pm
      • ToxicFrog
      • pbeckingham
        svij: Free food and beer all weekend. So we'll defnitely be seeing you. :)
      • ToxicFrog: Thanks again.
      • svij
        pbeckingham: too bad that I still don't drink beer :)
      • tbabej
        pbeckingham: Did anybody say free food?
      • pbeckingham
        tbabej: Are you in the right country yet?
      • tbabej
        pbeckingham: No, I'm departing at 8pm.
      • pbeckingham: Expected arrival to hotel approximately 7pm local time.
      • IS there anything planned for Friday evening?
      • pbeckingham
        tbabej: Yes, there is a party that ends at 7pm.'
      • tbabej: Friday: the usual, I presume, dinner and arguing.
      • tbabej
        pbeckingham: So I'm going to be the party-stopper again. Things never change.
      • pbeckingham
        tbabej: Well, you know the two possible places we will be.