Taskbook: Like Trello but for the Terminal(github.com)
github.com
Taskbook: Like Trello but for the Terminal
https://github.com/klauscfhq/taskbook#--taskbook
79 comments
Enjoy bright yellow on white. The author's blurb (q.v.) for this other to-do list tool says that colour customization is not in version 2.
* https://screenshots.debian.net/package/devtodo
* https://screenshots.debian.net/package/devtodo
That doesn't use true colour escape codes though so you can at least redefine the colour palette in your terminal. eg:
https://i.imgur.com/s2tGVHW.png
That said, it uses the "intense" palette which seems odd considering the regular colours would have sufficed.
https://i.imgur.com/s2tGVHW.png
That said, it uses the "intense" palette which seems odd considering the regular colours would have sufficed.
is you suggestion that if they had of used 3/4 bit ANSI colors (basic but not high intensity) that you could have remapped "white" to be something that shows up in your white terminal?
That.... works i guess but it's pretty limiting and only helps people who happened to have completely reworked the definitions of basic things like "white" and "black" and "blue" which would result in a completely unpredictable result for the app creator. A much BETTER solution would be for them to set the background color because they've got a UI specifically designed for dark background.
That.... works i guess but it's pretty limiting and only helps people who happened to have completely reworked the definitions of basic things like "white" and "black" and "blue" which would result in a completely unpredictable result for the app creator. A much BETTER solution would be for them to set the background color because they've got a UI specifically designed for dark background.
My solution would be to use the standard 8 colour ANSI escapes. Using the faint and intense shades for when they need to emphasis stuff. If they cannot get the desired effect from that then I'd rather than disabled colour by default and had an optional flag / environmental variable to enable true colour.
> That.... works i guess but it's pretty limiting and only helps people who happened to have completely reworked the definitions of basic things like "white" and "black" and "blue" which would result in a completely unpredictable result for the app creator.
I completely disagree for a few reasons:
1/ if you're running a white (or any other coloured) terminal then odds are you've already changed the other colours to suite (since other applications use the 3/4bit standard as well).
2/ or if they are just using a preset theme then that theme would have a suitable colour palette already
3/ CLI programs shouldn't be so dependant on the palette of the colours that alternative shades render the tool "unpredictable". It's a CLI tool, not a fancy graphical package. You cannot make any assumptions about the terminal eg what if the user has colour disabled entirely - does that then also make the tool "unpredictable"? What about different terminal typefaces? Or widths? You cannot make any assumptions aside that text will be rendered (and even that isn't a guarantee if you're using unicode).
The one exception to this is ASCII / terminal art. But they are justified in using true colour escape sequences since their entire point is pseudo-graphical.
> A much BETTER solution would be for them to set the background color because they've got a UI specifically designed for dark background.
That's another solution but I fundamentally disagree it is a better one. eg what if people are dyslexic or partially sighted so have their terminal configured for readability reasons? What the developer is doing is overriding that accessibility setting.
Unlike many CLI junkies I actually don't mind a bit of colour in the terminal. But I'd honestly rather have developers not using colour at all if they're really that concerned about their output looking identical on every terminal.
> That.... works i guess but it's pretty limiting and only helps people who happened to have completely reworked the definitions of basic things like "white" and "black" and "blue" which would result in a completely unpredictable result for the app creator.
I completely disagree for a few reasons:
1/ if you're running a white (or any other coloured) terminal then odds are you've already changed the other colours to suite (since other applications use the 3/4bit standard as well).
2/ or if they are just using a preset theme then that theme would have a suitable colour palette already
3/ CLI programs shouldn't be so dependant on the palette of the colours that alternative shades render the tool "unpredictable". It's a CLI tool, not a fancy graphical package. You cannot make any assumptions about the terminal eg what if the user has colour disabled entirely - does that then also make the tool "unpredictable"? What about different terminal typefaces? Or widths? You cannot make any assumptions aside that text will be rendered (and even that isn't a guarantee if you're using unicode).
The one exception to this is ASCII / terminal art. But they are justified in using true colour escape sequences since their entire point is pseudo-graphical.
> A much BETTER solution would be for them to set the background color because they've got a UI specifically designed for dark background.
That's another solution but I fundamentally disagree it is a better one. eg what if people are dyslexic or partially sighted so have their terminal configured for readability reasons? What the developer is doing is overriding that accessibility setting.
Unlike many CLI junkies I actually don't mind a bit of colour in the terminal. But I'd honestly rather have developers not using colour at all if they're really that concerned about their output looking identical on every terminal.
> That's another solution but I fundamentally disagree it is a better one. eg what if people are dyslexic or partially sighted so have their terminal configured for readability reasons? What the developer is doing is overriding that accessibility setting.
those points are totally valid and really important. I can't help but think of what the implications are for them on the web though. Sure we, as users, can control font choice and size for readability but color? Realistically the only thing i think you could do is install a plugin that compensates for various forms of color blindness by shifting the colors.
maybe _that_ is the right solution to the color blindness on the cli... modify your shell to run all input through a color shifter. I can't think of ever having seen an example of this but... it shouldn't be too hard AND for people without color blindness you could customize the behavior so that it shifted the output of apps like this one to colors more useful / happy-making to you.
I expect to be proven wrong about the "shouldn't be too hard" shortly.... ;)
> 1/ if you're running a white (or any other coloured) terminal then odds are you've already changed the other colours to suite (since other applications use the 3/4bit standard as well).
That doesn't seem right to me. The people i see running white terminals almost completely overlap with the people who have done NO customization.
> It's a CLI tool, not a fancy graphical package.
I have issues with this general approach to CLI apps. As someone who basically lives in the terminal every day I am regularly disappointed by just how poor the current state of cli UI is. There are SO many opportunities for them to be providing me with useful feedback by leveraging colors, and emoji, and formatting and most of them... just don't. This kind of UI / UX helps avoid bad data entry, mistaken choices, etc....
There are a lot of young folks writing new cli tools in nodejs these days AND thinking about how they can make the visuals more useful to the user. I totally applaud this approach. But, you're right about not taking disabilities into account.
those points are totally valid and really important. I can't help but think of what the implications are for them on the web though. Sure we, as users, can control font choice and size for readability but color? Realistically the only thing i think you could do is install a plugin that compensates for various forms of color blindness by shifting the colors.
maybe _that_ is the right solution to the color blindness on the cli... modify your shell to run all input through a color shifter. I can't think of ever having seen an example of this but... it shouldn't be too hard AND for people without color blindness you could customize the behavior so that it shifted the output of apps like this one to colors more useful / happy-making to you.
I expect to be proven wrong about the "shouldn't be too hard" shortly.... ;)
> 1/ if you're running a white (or any other coloured) terminal then odds are you've already changed the other colours to suite (since other applications use the 3/4bit standard as well).
That doesn't seem right to me. The people i see running white terminals almost completely overlap with the people who have done NO customization.
> It's a CLI tool, not a fancy graphical package.
I have issues with this general approach to CLI apps. As someone who basically lives in the terminal every day I am regularly disappointed by just how poor the current state of cli UI is. There are SO many opportunities for them to be providing me with useful feedback by leveraging colors, and emoji, and formatting and most of them... just don't. This kind of UI / UX helps avoid bad data entry, mistaken choices, etc....
There are a lot of young folks writing new cli tools in nodejs these days AND thinking about how they can make the visuals more useful to the user. I totally applaud this approach. But, you're right about not taking disabilities into account.
Re web Vs CLI: I think most browsers have a readability mode or something where you can click a button and just the article body is retained; without CSS formatting and stuff. But yes you're right, accessibility is a really big problem with the web. There are screen readers but some pages even break those :( at least with the CLI, there is no real need to add colour beyond vanity (and i have no issue with it being used for vanities sake either, just so long as it doesnt render the text unreadable on my term)
Re CLIs should be more graphical. I both agree and disagree. The issue with user input and mistakes etc is more down to the tooling and/or user experience than the CLI itself. This is actually why I'm writing my own shell at the moment. I'm trying to address some of the discoverability issues that traditional shells have. A bit like Fish tries to do except mine is more programmer orientated.
I do actually think modern terminals would benefit from supporting richer content but I really don't think that should be at the cost of breaking the basics we come to expect (tools can be pipelined, shells can be customised, etc). I think if the web has taught us anything, it's that developers cannot be trusted with UIs. I know that sounds harsh but every webpage is themed differently and on the whole it's a bit of a UX nightmare. Where as CLI tools need to work homogeneously together. Coloured output breaks this because many developers (particularly the nodejs ones it seems) forget to check if the tool is outputting to a TTY or not. This matters because it prevents the user from doing the following without writing a load of crap escape sequences that won't render in your text editor:
Re CLIs should be more graphical. I both agree and disagree. The issue with user input and mistakes etc is more down to the tooling and/or user experience than the CLI itself. This is actually why I'm writing my own shell at the moment. I'm trying to address some of the discoverability issues that traditional shells have. A bit like Fish tries to do except mine is more programmer orientated.
I do actually think modern terminals would benefit from supporting richer content but I really don't think that should be at the cost of breaking the basics we come to expect (tools can be pipelined, shells can be customised, etc). I think if the web has taught us anything, it's that developers cannot be trusted with UIs. I know that sounds harsh but every webpage is themed differently and on the whole it's a bit of a UX nightmare. Where as CLI tools need to work homogeneously together. Coloured output breaks this because many developers (particularly the nodejs ones it seems) forget to check if the tool is outputting to a TTY or not. This matters because it prevents the user from doing the following without writing a load of crap escape sequences that won't render in your text editor:
todo list | grep urgent > urgent.txt
You are imposing limits on the to-do list authors who want a different colour for each field, and have more than 7 fields. (-:
* https://screenshots.debian.net/package/yagtd
* https://screenshots.debian.net/package/yagtd
Again, there are more than 7 colours available if you include the intense and faint palettes. Which is, in my opinion at least, better than the to-do list authors imposing limits on what shell colour schemes I can use.
Or alternatively, they can just not use any colours at all. Frankly I don't even have different colour schemes on my JIRA kanban board so the argument that CLI todo lists require true colour support is tenuous at best.
Or alternatively, they can just not use any colours at all. Frankly I don't even have different colour schemes on my JIRA kanban board so the argument that CLI todo lists require true colour support is tenuous at best.
There aren't really intense and faint palettes. The conventional indexed colour mapping has 16 "standard" colours in entries 0 to 15, but those aren't really anything to do with either bold or faint attributes. They are not even standard. ITU T.416 does not specify them.
There are only eight standard colours in ECMA-48, set by SGR 30 to 37 and 40 to 47. Some emulators substitute a colour modifier for boldface. But not all of them even do that, with several terminal emulators rendering boldface as actual boldface, meaning that that is not a route to a colour change in the first place. As for faint, my terminal emulator is one of the very few that even takes any notice at all of the faint attribute.
SGR 90 to 97 and 100 to 107 are not standardized by ECMA-48. They are an extension from aixterm.
There are only eight standard colours in ECMA-48, set by SGR 30 to 37 and 40 to 47. Some emulators substitute a colour modifier for boldface. But not all of them even do that, with several terminal emulators rendering boldface as actual boldface, meaning that that is not a route to a colour change in the first place. As for faint, my terminal emulator is one of the very few that even takes any notice at all of the faint attribute.
SGR 90 to 97 and 100 to 107 are not standardized by ECMA-48. They are an extension from aixterm.
Bold and intense are two completely different things in terms of SGR codes, so let's just strike bold from the conversation now.
The intence and faint codes are the same SGR ranges as the standard 8 colours but have their additional property encoded in their escape sequence (separated by a semi-colon, as is common with terminal escape sequences).
Arguements about whether it is standard or not aside (because there are dozens of standards and no terminal emulator follows any of those standards strictly anyway - instead picking and choosing parts from different standards based on whatever gets the best results the easiest), most terminals do support it. In fact faint and intense are more widely supported than the 8 bit and 24 bit SGR sequences. However if you're really going to get hung up on compatibility and standards then the only safe route is not to use colour at all.
The intence and faint codes are the same SGR ranges as the standard 8 colours but have their additional property encoded in their escape sequence (separated by a semi-colon, as is common with terminal escape sequences).
Arguements about whether it is standard or not aside (because there are dozens of standards and no terminal emulator follows any of those standards strictly anyway - instead picking and choosing parts from different standards based on whatever gets the best results the easiest), most terminals do support it. In fact faint and intense are more widely supported than the 8 bit and 24 bit SGR sequences. However if you're really going to get hung up on compatibility and standards then the only safe route is not to use colour at all.
That's pretty much wrong on every point.
You have the wrong model for how this works. SGR control sequences do not work this way.
There is no "additional property". The "additional property" is the very boldface and faint attribute that you erroneously want to "strike from the conversation". It is a standalone attribute, separate from the foreground/background colour setting. And as I said: Some, but not all, terminal emulators treat the bold attribute as a colour modifier, with several conversely now rendering it as true boldface, sometimes to the surprise of users; and the majority simply ignore the faint attribute completely.
And no, you don't get to set aside whether this is a standard, since you brought up the argument that there were "standard colour ANSI escapes" in the first place. (These are not ANSI, by the way. You have the wrong standards body, on the wrong continent.)
To which you then added this erroneous notion that there are "faint and intense palettes", based as we now see on an incorrect understanding of the ECMA-48 SGR control sequence.
No, not using colour is not the only safe route, as ECMA-48 standardizes eight colours with a mapping from ordinal to colour, the use of which is very safely within standard-defined areas. Indexed colour, standardized by ITU T.416, in contrast does not have a similar defined map for the various indices. The "standard 16 colours" in indices 0 to 15, so often talked about, are not in fact standardized.
And indexed colour control sequences properly use colon, not semi-colon, as a separator. Ironically, that is the way that "additional properties", more properly termed sub-parameters, are encoded in ECMA control sequences. You are not alone in making this mistake. It was widely made based upon samizdat, rather than reading the actual standards, and has some historical inertia behind it; although by my observations a fair number of terminal emulator authors have nowadays come around to supporting the proper, standard, mechanism. But you are nonetheless making another mistake.
No, there are not "dozens of standards". There's ECMA-48, ECMA-35, ITU T.416, the Unicode standard (for UTF-8), and the de facto standard of what the VT520 doco says about all of the DEC private stuff. One can nowadays get away with, as I and the mosh people do, not implementing any of the ECMA-35 8-bit character set switching mechanisms and ignoring that standard. The mosh people tout this as a feature. That leaves just four.
Nor are terminal emulator people flippant about them, as you claim, in my direct experience of dealing with them.
* https://unix.stackexchange.com/a/289871/5132
You have the wrong model for how this works. SGR control sequences do not work this way.
There is no "additional property". The "additional property" is the very boldface and faint attribute that you erroneously want to "strike from the conversation". It is a standalone attribute, separate from the foreground/background colour setting. And as I said: Some, but not all, terminal emulators treat the bold attribute as a colour modifier, with several conversely now rendering it as true boldface, sometimes to the surprise of users; and the majority simply ignore the faint attribute completely.
And no, you don't get to set aside whether this is a standard, since you brought up the argument that there were "standard colour ANSI escapes" in the first place. (These are not ANSI, by the way. You have the wrong standards body, on the wrong continent.)
To which you then added this erroneous notion that there are "faint and intense palettes", based as we now see on an incorrect understanding of the ECMA-48 SGR control sequence.
No, not using colour is not the only safe route, as ECMA-48 standardizes eight colours with a mapping from ordinal to colour, the use of which is very safely within standard-defined areas. Indexed colour, standardized by ITU T.416, in contrast does not have a similar defined map for the various indices. The "standard 16 colours" in indices 0 to 15, so often talked about, are not in fact standardized.
And indexed colour control sequences properly use colon, not semi-colon, as a separator. Ironically, that is the way that "additional properties", more properly termed sub-parameters, are encoded in ECMA control sequences. You are not alone in making this mistake. It was widely made based upon samizdat, rather than reading the actual standards, and has some historical inertia behind it; although by my observations a fair number of terminal emulator authors have nowadays come around to supporting the proper, standard, mechanism. But you are nonetheless making another mistake.
No, there are not "dozens of standards". There's ECMA-48, ECMA-35, ITU T.416, the Unicode standard (for UTF-8), and the de facto standard of what the VT520 doco says about all of the DEC private stuff. One can nowadays get away with, as I and the mosh people do, not implementing any of the ECMA-35 8-bit character set switching mechanisms and ignoring that standard. The mosh people tout this as a feature. That leaves just four.
Nor are terminal emulator people flippant about them, as you claim, in my direct experience of dealing with them.
* https://unix.stackexchange.com/a/289871/5132
> That's pretty much wrong on every point.
I've spent a great many hours of my life implementing terminal escape codes into various $SHELLs and $TERMs (and I don't mean some Electron crap), so I have read the specs and I'm not just making this stuff up nor talking purely from the perspective of throwing some colour in a personal CLI tool.
> There is no "additional property". The "additional property" is the very boldface and faint attribute that you erroneously want to "strike from the conversation".
I think you're more hung up on my wording than anything.
> And no, you don't get to set aside whether this is a standard, since you brought up the argument that there were "standard colour ANSI escapes" in the first place. (These are not ANSI, by the way. You have the wrong standards body, on the wrong continent.)
Again, you're arguing semantics rather than trying to understand the point I was making (maybe that was my fault for trying to discuss complex thing on a phone with a broken touch screen?). But in any case you later went on to reiterate my original arguments when you said devs should use 3/4 bit.
> No, not using colour is not the only safe route, as ECMA-48 standardizes eight colours with a mapping from ordinal to colour, the use of which is very safely within standard-defined areas.
Not all terms honour those SGR sequences. If portability is a concern then you cannot rely on colour - period.
However it's interesting to see you're basically reiterating my primary point now :)
> And indexed colour control sequences properly use colon, not semi-colon, as a separator.
Some do, some don't (as I demonstrated above). Semi-colon is more commonly used as a separator in terminal escape sequences though (not just with SGR codes either, I could list dozens of CSI sequences which use semi-colon as a separator).
But don't take my word for it: https://stackoverflow.com/questions/4842424/list-of-ansi-col...
> No, there are not "dozens of standards".
Not all standards have been enshrined by a standards body but there are indeed multiple vendor specific standards and de facto standards as well. Working with vendor specific standards is "fun".
> Nor are terminal emulator people flippant about them, as you claim, in my direct experience of dealing with them.
Then I question you're experience because my direct experience has been that you cannot count on a $TERM following any specification to the letter (unless of course that specification was written for that term). This is a particularly potent problem when you start dealing with CSI and other sequences. Heck, $TERMs don't even agree on backspace all of the time (^? vs ^H) so god help them when it comes to anything more complex.
But I guess if it was as simple as you claim then termcap et al wouldn't be a thing ;)
I've spent a great many hours of my life implementing terminal escape codes into various $SHELLs and $TERMs (and I don't mean some Electron crap), so I have read the specs and I'm not just making this stuff up nor talking purely from the perspective of throwing some colour in a personal CLI tool.
> There is no "additional property". The "additional property" is the very boldface and faint attribute that you erroneously want to "strike from the conversation".
I think you're more hung up on my wording than anything.
ESC[31m -- red
ESC[1;31m -- intense red
ESC[2;31m -- faint red
ESC[1m -- bold
ESC[2m -- faint
> And no, you don't get to set aside whether this is a standard, since you brought up the argument that there were "standard colour ANSI escapes" in the first place. (These are not ANSI, by the way. You have the wrong standards body, on the wrong continent.)
Again, you're arguing semantics rather than trying to understand the point I was making (maybe that was my fault for trying to discuss complex thing on a phone with a broken touch screen?). But in any case you later went on to reiterate my original arguments when you said devs should use 3/4 bit.
> No, not using colour is not the only safe route, as ECMA-48 standardizes eight colours with a mapping from ordinal to colour, the use of which is very safely within standard-defined areas.
Not all terms honour those SGR sequences. If portability is a concern then you cannot rely on colour - period.
However it's interesting to see you're basically reiterating my primary point now :)
> And indexed colour control sequences properly use colon, not semi-colon, as a separator.
Some do, some don't (as I demonstrated above). Semi-colon is more commonly used as a separator in terminal escape sequences though (not just with SGR codes either, I could list dozens of CSI sequences which use semi-colon as a separator).
But don't take my word for it: https://stackoverflow.com/questions/4842424/list-of-ansi-col...
> No, there are not "dozens of standards".
Not all standards have been enshrined by a standards body but there are indeed multiple vendor specific standards and de facto standards as well. Working with vendor specific standards is "fun".
> Nor are terminal emulator people flippant about them, as you claim, in my direct experience of dealing with them.
Then I question you're experience because my direct experience has been that you cannot count on a $TERM following any specification to the letter (unless of course that specification was written for that term). This is a particularly potent problem when you start dealing with CSI and other sequences. Heck, $TERMs don't even agree on backspace all of the time (^? vs ^H) so god help them when it comes to anything more complex.
But I guess if it was as simple as you claim then termcap et al wouldn't be a thing ;)
On a related note: I very much wish Org Mode had decent support outside Emacs.
It's great, well thought-out in many ways, and supports many types of workflows. I sorely lack a web tool for it to share with others.
It's great, well thought-out in many ways, and supports many types of workflows. I sorely lack a web tool for it to share with others.
Word. Org-mode is like markdown plus jupyter plus black-magic. As much as I very much like org-mode, emacs is just too much of an alien world for me these days.
I wish somebody would make a "dumbed-down" version of emacs that was always in org-mode and used modern interaction-conventions and configuration. Something like FoldingText but for org-mode. (I realize this somebody could be me, but I've already got enough side-projects.)
I wish somebody would make a "dumbed-down" version of emacs that was always in org-mode and used modern interaction-conventions and configuration. Something like FoldingText but for org-mode. (I realize this somebody could be me, but I've already got enough side-projects.)
There's an extension for Org Mode for Visual Studio Code.
https://github.com/ajtoo/vscode-org-mode https://marketplace.visualstudio.com/items?itemName=tootone....
There's also an Android app called Orgzly which supports Org Mode files.
http://www.orgzly.com/
https://github.com/ajtoo/vscode-org-mode https://marketplace.visualstudio.com/items?itemName=tootone....
There's also an Android app called Orgzly which supports Org Mode files.
http://www.orgzly.com/
Orgzly is really nice, have been using it for a long time
Orgzly is great and I have it, but it does have limitations, e.g. it does not yet support custom item states.
Any self-hosted alternative? I tried searching, couldn't find any.
Those screenshots are extremely slick. What terminal is that, and what styling options is it using?
Seems like it's probably slightly Photoshopped, however Hyper (https://hyper.is/) comes really close.
That does look nice, but... hmm... Electron? I don't usually have a problem with Electron, but I kinda think terminals in particular should be as light as possible. No harm in testing it, I suppose.
Yeah there's also a terminal emulator built into VS Code, but it seems that every release they add a heap of features to it which I feel like are already present in existing emulators - feels like reinventing the wheel and I'm not sure about the benefits yet.
Besides of course ease in styling with css and hackability.
Besides of course ease in styling with css and hackability.
Hi, I build the terminal in VS Code and am a maintainer on xterm.js. There is some reinventing of the wheel happening but that's because xterm.js is the best option out there for building a terminal in a web context. As WorldMaker mentioned though, it's open source and a communal effort, so anyone can pick it up and build a terminal that runs in a browser or Electron with ease.
VS Code and Hyper both use the same upstream emulator library (xterm.js [1]), so at least a lot of the wheel "reinvention" in this space is a communal effort.
[1] https://xtermjs.org/
[1] https://xtermjs.org/
lol I saw that it said "built on Electron" and reflexively said "...EWW" out loud.
EDIT: people, I'm not saying Electron is gross. I think it's awesome. I do however think it seems very off to use it to build a terminal.
sadly the vast majority of new projects these days seem to be done in nodeJS regardless of if javascript is a good choice for the project or not, and if it needs a desktop GUI that means electron.
:(
:(
I think is hyper terminal with this theme ; https://github.com/klauscfhq/hyperocean (it is from the same author as taskbook)
Looks like Carbon to me. In other words, fake.
https://carbon.now.sh/
https://carbon.now.sh/
Carbon does not have that theme though, it is probably hyper terminal on Macos with the author's theme https://github.com/klauscfhq/hyperocean
* there is no custom theme option either, and they have stopped accepting new themes too; https://github.com/dawnlabs/carbon/issues/427#issuecomment-4...
* there is no custom theme option either, and they have stopped accepting new themes too; https://github.com/dawnlabs/carbon/issues/427#issuecomment-4...
I love Org-mode for organizing to-do lists for complicated projects. This is great for completing short-term tasks.
[deleted]
I just started using org-mode recently and I also saw some overlap.
From the readme it looks like it is single user - like org-mode. I wonder is any organizations have developed group/multi-user features for org-mode?
From the readme it looks like it is single user - like org-mode. I wonder is any organizations have developed group/multi-user features for org-mode?
There's org-trello, but I think it's not perfect.
Probably a good organizational org-mode policy would be to sync using git. Unless the pace is too fast.
Incidentally, there's many nice ways to make org-agenda look like a kanban.
Probably a good organizational org-mode policy would be to sync using git. Unless the pace is too fast.
Incidentally, there's many nice ways to make org-agenda look like a kanban.
Has anyone tried org-sync[1] and could comment on how well this works, and whether there are more backends hidden away elsewhere (e.g. for gitlab?)
(Although if I'd replied with this at the time rather than accidentally having the tab open for 2 days it would have helped ;)
[1] https://orgmode.org/worg/org-contrib/gsoc2012/student-projec...
(Although if I'd replied with this at the time rather than accidentally having the tab open for 2 days it would have helped ;)
[1] https://orgmode.org/worg/org-contrib/gsoc2012/student-projec...
Half-OT: Is there something like Trello, but with a good smartphone UI?
I found scrolling between the columns a bit cumbersome...
I found scrolling between the columns a bit cumbersome...
This is the perfect android kanban like App I've used with intuitive UI: https://play.google.com/store/apps/details?id=com.sauce.agil...
This is a bit like 123.do a Perl 6 powered command line app:
https://perl6advent.wordpress.com/2017/12/18/perl6-powered-w...
https://perl6advent.wordpress.com/2017/12/18/perl6-powered-w...
This is very cool but unfortunately it looks a bit rough in Solarized Dark since some of the output defaults to black text.
Suggestion: configurable text colors. You already have a config file. I may try to hack it together myself later - if I get it working I'll make a PR.
Overall though this is a cool idea and looks very well executed. Nice work!
Suggestion: configurable text colors. You already have a config file. I may try to hack it together myself later - if I get it working I'll make a PR.
Overall though this is a cool idea and looks very well executed. Nice work!
How is this "like Trello"? Trello is not just a task manager is is very specifically a kansan board. The possibility to see all of the cards in columns is essential and this, at least in screenshots does not have it.
It isn't really, as others have observed. It is, rather, like all of these:
* https://screenshots.debian.net/package/devtodo
* https://screenshots.debian.net/package/taskwarrior
* https://screenshots.debian.net/package/yagtd
* https://screenshots.debian.net/package/w2do
* https://screenshots.debian.net/package/yokadi
* https://screenshots.debian.net/package/pal
* https://packages.debian.org/sid/todotxt-cli
* https://packages.debian.org/sid/todoman
* https://screenshots.debian.net/package/tudu
* https://screenshots.debian.net/package/devtodo
* https://screenshots.debian.net/package/taskwarrior
* https://screenshots.debian.net/package/yagtd
* https://screenshots.debian.net/package/w2do
* https://screenshots.debian.net/package/yokadi
* https://screenshots.debian.net/package/pal
* https://packages.debian.org/sid/todotxt-cli
* https://packages.debian.org/sid/todoman
* https://screenshots.debian.net/package/tudu
In one way you are right, however, many people use Trello as a to-do list instead of as Kanban.
So, like it's "like to-do list", not "like Trello". That is big difference.
How does it compare to taskwarrior?
I like the look of this. Why would I use it over Taskwarrior?
This is great. The command line arguments are a bit obtuse at times. It would be stellar if there was an --interactive mode or a --shell mode, at the minimum.
[deleted]
This looks fantastic! Good work.
It'd be lovely if this could synchronize with Trello. They do have an API :)
It'd be lovely if this could synchronize with Trello. They do have an API :)
Please don't get me wrong. Is this for people who works on non-desktop OSes? I mean what's the point of a command line task manager on a desktop? RAM usage?
Several reasons.
1. If you live in a terminal it's easier to stay in that terminal instead of switching to a new window to deal with your task manager, then switching back to your terminal.
2. It's quicker to type one command with all it's options instead of using a GUI and selecting multiple options.
3. IN my case as a blind programmer I find it easier to use as many command-line tools as possible instead of dealing with possible accessibility issues in a GUI.
4. Personal preference
[deleted]
For me, it is window focus. I am readily in a terminal somewhere in my development flow so I can CRUD my task list there. Personally, I also added tb into my .zshrc so that I have an overview of tasks in-flight and in-queue when I open a new shell. I kind of need that harassment at times to keep on top of things that need to be kept on top of!
Some reasons I prefer command line tools:
1) Don't have to use the mouse. This is a major plus for me. Even when I am not in the CLI, I prefer apps that have heavy KB shortcuts.
2) For ToDo apps, I think it's a good interface, because it forces simplicity.
3) CLI tools usually keep a simple text style DB (not always true, but true of this app at least). This is nice especially since it allows for multiple sharing/syncing patterns.
4) Integration and extensibility. I don't need to wait for the developer to implement a filter tool. I can pipe the output, or the contents of the "DB" to grep and do that. I don't need the developer to add bulk edit features. I can use awk to do that myself. I don't need the developer to implement scheduled tasks. I can write a cron job that does that for me.
Many of us live in the terminal most of the day. The less we have to reach for a mouse the better.
A CLI interface is automatically extendable by virtue of always being scriptable. If a tool can be scripted you can create higher level abstractions on top of it.
This is a hugely understated paradigm.
This is a hugely understated paradigm.
CLI apps are generally lightweight and don't get in your way too much, just get the job done quickly and effectively
I love this kind of thing, but it isn't fair to say it is "like Trello". Trello is an online collaborative kanban board. While Taskbook looks great, AFAICT, it isn't kanban, and it isn't collaborative.
I was expecting C with ncurses, but what I found was javascript.
It's open source; if you believe C and ncurses are a better choice, you can make an alternative client that supports the same format.
It's not really a "client", note. There is no server involved. It's just a standalone utility that reads/writes a database stored in a file in JSON. The database format is undocumented.
I think is just key-value pairs stored in JSON, keys are ids and values object with this properties: https://github.com/klauscfhq/taskbook/blob/master/lib/item.j...
Pretty minimal
You think that; but since it is undocumented, you don't know.
cat ~/.taskbook/storage/storage.json and you can see it.
Overall a very well documented repo if you ask me
You are confusing one particular data set with actual documentation of a database schema. Your notion of what "well documented" is seems to be an extraordinarily low bar, given that you apply it to the case where there is no doco at all.
It is just a JSON file no need of what you are talking about but agree to disagree
It's wrong to be downvoting this without some type of substantive reason. We all know that the guy above was dragging out the bemoaned javascript meme, and the second one was responding 100% as he should. Let's not use the downvote button as an "I'm disgruntled" button, that has never been how this community works.
Let’s not complain about downvotes because that’s in the FAQ.
It's bad to complain about downvotes to one's own posts, but complaining about those to others' posts is sometimes acceptable, especially in cases like this one where the post in question is so obviously correct.
Either way, it's off-topic meta noise. Nobody is going to change their voting behavior based on an admonishment, especially when the owner of the site has acknowledged that votes here are used as like/dislike.
If every time Reddit flubs a deployment we have to get one step closer to this being the case, I'd have to respectfully part ways with HN.
I think the appeal is not so much for downvotes to be reversed but for sympathetic upvotes to compensate for the downvotes?
Looks pretty!
Like taskwarrior, then? (but the layout is nicer)
Hah, I was building something almost identical to this a few months ago. Very nice!
It's really nice!
However, I can't stop thinking "tuberculosis".
However, I can't stop thinking "tuberculosis".
added 122 packages from 41 contributors in 2.462s
I'm giving it a go, looks good and the shortcuts flow well when typing them:
tb -t @personal Finish groceries
I'm giving it a go, looks good and the shortcuts flow well when typing them:
tb -t @personal Finish groceries
https://i.imgur.com/GE0XAfu.png