[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Yesterday's discussion, re inference
- To: Tuomas Lukka <lukka@xxxxxxxxxx>
- Subject: Re: [zzdev] Yesterday's discussion, re inference
- From: "B. Fallenstein" <b.fallenstein@xxxxxx>
- Date: Wed, 23 May 2001 16:34:49 +0200
- Cc: zzdev@xxxxxxxxxx
- References: <20010523130004.K23534@xxxxxxxxxxxxxx>
Tuomas Lukka wrote:
> On IRC, benja and Stugge discussed inference. One point that comes
> to me is that an inference system that changes the user's inputs
> based on later inputs is usually not good; for example, debian's dselect
> does this and it is not good.
True! I'm not familiar with deselect, but I do know the problem from
other fields. The rule of thumb I stated yesterday seems to apply here, too:
1) Show as much information as possible, even if it conflicts.
2) Don't change anything when there's a conflict.
But, as always, the problem is drawing the borderline: where is a later
input _meant_ to reverse the previous? Obviously, when the user makes a
connection and then breaks it, it should be plain broken, instead of
being called a "conflict of inputs." My idea was that e.g. excising a
cell from an inferred list, for example a TODO list compiled from
different other lists, might be meant to excise the cell also from the
dimensions used for inferring, in this case from the list the TODO item
was on. (I.e., you have for example a TODO list for an article you write
and a TODO for src/, but you show them on a single longer TODO list;
deleting an item from that list probably indicates it's done/obsoloete,
i.e. should also be removed from the sublist it came from.)
- Benja