Ihor Radchenko writes:
> For reference, I am seeing this feature as a step towards better
> modularity of org-list.el.
Modularity is good if we have use-cases for it, at least one feature
relying on it. I wouldn't implement a feature just to add modularity.
> The current list code is rather
> "TC" == Tim Cross writes:
TC> At any rate, at this point, I suspect this is something best
TC> handled in individual configurations rather than attempting to
TC> impose a specific interpretation on everyone. If someone needs
TC> help to write a simple command to 'toggle'
Tim Cross writes:
> +1. As usual, I'm concerned about over engineering and over
> complicating matters for corner cases. As you correctly point out,
> implementing something here is likely to force a specific interpretation
> of cancelled with may not fit with other interpretations.
For
Bastien writes:
> Daniel Fleischer writes:
>
>> At first it makes sense, but we do have headlines and TODO keywords to
>> express different states, colors and even sets of states. This is just a
>> checklist construct. I think if I wanted to mark something as canceled
>> or not relevant I
> "B" == Bastien writes:
B> FWIW, I use this:
B> - [X] +This task will probably be canceled+
B> I don't think we should implement a new status for canceled
B> tasks.
Such a workaround doesn’t work well for lists that are to be re-used
next time or cleared when the whole
Daniel Fleischer writes:
> At first it makes sense, but we do have headlines and TODO keywords to
> express different states, colors and even sets of states. This is just a
> checklist construct. I think if I wanted to mark something as canceled
> or not relevant I would do something like this:
Hi,
* Christophe Schockaert wrote:
> As for me, I am interested in having a way to manage cancels.
>
> I have always managed it with workarounds up to now, so it would be nice
> to have a clean way for it.
"Clean" depends on the definition.
To me, a general convention with the statement that
Christophe Schockaert writes:
> (my wish would be to have a robust way to handle multilines formating,
> but that’s on another topic going on ^^)
>
> I don’t know what’s the usual process : can’t we file an issue to track
> it, and write down the options we have, then decide the outcome of it
On 2022-09-14 14:43, Ihor Radchenko wrote:
Karl Voit writes:
So, to me the main use case to have an explicit cancel, is when I
have a
long list, and to remember that I stated it as "cancelled".
If we go that way, having no other nice idea at the moment, I quite
like
the [C] which is
Karl Voit [2022-09-13 Tue 10:07] wrote:
> Is it only me who is thinking that a non-blocking cancelled checkbox
> state would be a good idea?
At first it makes sense, but we do have headlines and TODO keywords to
express different states, colors and even sets of states. This is just a
checklist
Karl Voit writes:
>> So, to me the main use case to have an explicit cancel, is when I have a
>> long list, and to remember that I stated it as "cancelled".
>> If we go that way, having no other nice idea at the moment, I quite like
>> the [C] which is explicit although language specific.
>
>
Hi Christophe,
* Christophe Schockaert wrote:
>
> In a sense I can feel it’s useful to have an explicit cancel while
> working.
> But I don’t know how to handle it (see below).
> I don’t think [/] would be a good candidate anyway, it’s used as a
> statistic cookie, so it already has a meaning
On 2022-09-13 10:07, Karl Voit wrote:
Hi Ihor,
* Ihor Radchenko wrote:
Karl Voit writes:
I was using list checkboxes like that:
- [ ] open task
- [X] closed task
- [-] cancelled task
From the manual (5.6 Checkboxes):
‘C-c C-x C-b’ (‘org-toggle-checkbox’)
Toggle checkbox status
On 2022-09-13, at 10:07, Karl Voit wrote:
> Is it only me who is thinking that a non-blocking cancelled checkbox
> state would be a good idea?
No.
--
Marcin Borkowski
http://mbork.pl
Hi Ihor,
* Ihor Radchenko wrote:
> Karl Voit writes:
>
>> I was using list checkboxes like that:
>> - [ ] open task
>> - [X] closed task
>> - [-] cancelled task
>
> From the manual (5.6 Checkboxes):
>
> ‘C-c C-x C-b’ (‘org-toggle-checkbox’)
> Toggle checkbox status or—with prefix
Karl Voit writes:
> I was using list checkboxes like that:
>
> - [ ] open task
> - [X] closed task
> - [-] cancelled task
>
> The latter one is supported via C-u C-u C-c C-c.
>From the manual (5.6 Checkboxes):
‘C-c C-x C-b’ (‘org-toggle-checkbox’)
Toggle checkbox status or—with prefix
16 matches
Mail list logo
