[linux-l] Wohin mit den alten Mails? -> +sent

[olafBuddenhagen at gmx.net]

Hallo,

On Wed, Feb 14, 2007 at 01:13:23PM +0100, Volker Grabsch wrote:
> On Mon, Feb 12, 2007 at 03:16:22AM +0100, olafBuddenhagen at gmx.net
> wrote:

> > aber es erfordert dann doch schon einiges an spezieller
> > UI-funktionalität, um das komfortabel zu gestalten. Dazu gehört
> > unter Anderem auch, dass man einfach aus schon existierenden Tags
> > auswählen kann, zum Beispiel über eine spezielle Form von
> > Completion. (Die normale wäre dafür wohl zu umständlich.)
> 
> Die Tab-Autovervollständigung in mutt finde ich sehr komfortabel. Die
> könnte man direkt dafür nutzen, genauso wie es bei "alias", "change
> folder", etc. gemacht wird.
> 
> (Und dass es sich beim Einlesen der Folder alle augetretenen Tags
> merkt und dann anbietet, ist IMHO auch nicht schwer zu
> implementieren.)
> 
> Oder dachtest du an was anderes?

Ich weiß nicht in wie weit die Completion bei Mutt konfigurierbar ist.
Was aber bei den Tags wünschenswert wäre (eventuell auch an anderer
Stelle), wäre dass man beim Aufruf des Tag-Kommandos *sofort* eine Liste
bekannter Tags zu sehen bekommt, nicht erst wenn man Tab drückt. Dann
kann man, je nach dem wie man drauf ist, trotzdem eintippen (unterstützt
durch klassische Tab-Completion), oder mit Cursortasten/Maus aus der
Liste wählen.

> > Auch sind die bisherigen Filtermöglichkeiten bei mutt viel zu
> > unpraktisch, um das wirklich benutzbar zu machen. Es muss ganz
> > einfach möglich sein, bei einem bereits gefilterten Ordner ein
> > weiteres Filterkriterium hinzuzufügen oder zu entfernen.
> 
> Kannst du doch. Filter aufrufen, Pfeiltaste hoch (liefert alten
> Filter), neues Kriterium direkt hinzutragen. Mit diesem Mechanismus
> kannst du sogar vorherige Filter leicht abwandeln oder wieder heraus
> nehmen. Finde ich sehr komfortabel.

Das ist eben *nicht* das, was man in der Regel will. Wenn man mit diesem
Verfahren nach vielen Kriterien sortieren will (und die nicht alle durch
ein einfaches AND verknüpft sind, sondern auch OR und NOT ins Spiel
kommen), muss man schon sehr abstrakt denken, um auf den richtigen
Ausdruck zu kommen. Wenn man eine vorhandene Regel modifizieren möchte,
muss man sehr genau überlegen, wie man das neue Kriterium in den
Ausdruck einfügen muss. Und dann die Modifizierung an sich vornehmen,
was bei einem langen Ausdruck garnicht so einfach ist. Überhaupt muss
man erstmal die Prinzipien der boolschen Ausdrücke verstehen, und genau
wissen, wie sie in Mutt-Syntax umgesetzt werden.

Das Problem dabei ist, dass die Filterregeln sich grundsätzlich auf den
Ausgangszustand (alle Mails) beziehen. Man kann sich nicht wirklich
schrittweise vorarbeiten. Viel komfortabler wäre es meistens, wenn man
zunächst eine Regel anwendet, um einer erste grobe Filterung zu
erreichen, und dann ausgehend von diesem Zwischenergebnis weitergeht.
Mann muss sich dann nur noch überlegen, wie man vom aktuellen Zustand
zum Ziel kommt; was man vorher schon gemacht hat, kann man getrost
vergessen. Erfordert sehr viel weniger abstraktes Denken.

Wie schon angedeutet, kann man diese Schritte auch auf Gesammtregeln
zurückführen. Und eine solche Funktion wäre sogar sehr nützlich, wenn
diese zurückgeführten Regeln immer mit angezeigt werden -- denn dann
kann man gleich mitlernen, und weiß in Zukunft dann vielleicht, wie man
mehrere Schritte mit einem Ausdruck zusammenfassen kann, ohne dass man
gleich ins kalte Wasser geschmissen wird. Aber das ist wie gesagt nicht
ganz trivial zu implementieren.

(Man könnte es trivial implementieren, aber dann würden die Ausdrücke
nach mehreren Filterschritten bald absurde Ausmaße annehmen. Also muss
ständig automatisch vereinfacht werden, nach den Regeln der boolschen
Algebra.)

Insbesondere ist das auch deshalb wichtig, weil man bei der Suche
eigentlich nie von der gesammten Liste ausgehen wird, sondern von einer
bereits vorhandenen Standard-Ansicht, die schon eine ganze Reihe
Filterkriterien vorgibt. Da neue hinzuzufügen oder welche rauszunehmen,
ist alles andere als einfach.

> Was *mich* eher stört, ist dass man sich ~b, ~H, etc. merken muss, da
> fände ich eine Eingabemaske benutzerfreundlicher.

Das auch.

> Vielleicht sollte es mehr Beispiele für Standard-Aufgaben
> (auskommentiert) in der .muttrc geben? Das würde die Einstiegshürde
> vermutlich senken.

Es würde die Einstiegshürde senken, wenn es für jede wichtige
Funktionalität neben der direkten Manipulation von Variable etc. auch
eine GUI-Schnittstelle gäbe :-)

> > Der postpone-Mechanismus muss auch angepasst werden, um mit Tags
> > statt echter Folder arbeiten zu können -- ebenso wie zahlreiche
> > andere Stellen in mutt, die von echten Foldern ausgehen.
> 
> Mir ist jetzt nicht klar, was genau du damit meinst.

Wenn man ein "Postpone" in Mutt macht, wird die Mail in einen speziellen
Ordner geschoben. Wenn man aber nur noch mit Tags arbeitet, will man
dafür natürlich keinen extra Ordner mehr, sondern nur noch ein
spezielles Tag. Dafür muss die Programmlogik entsprechend angepasst
werden.

> > Schließlich müssen die Filtermöglichkeiten selbst erweitert werden.
> > Zum Beispiel muss es einfach möglich sein, neben den Mails, die
> > direkt den Kriterien entsprechen, auch diejenigen anzuzeigen, die
> > ihnen nicht entsprechen, aber sich im gleichen Thread befinden, wie
> > welche die es tun. (Oder geht das schon irgendwie?...)
> 
> Mail-Eintrag "ausgrauen" statt auszublenden wäre vielleicht ein Weg.
> 
> Das kann mutt AFAIK nicht, wäre aber ein interessantes Feature.

Tatsächlich habe ich genau in die gleiche Richtung gedacht :-) Wenn man
neben der eigentlich zutreffenden Mails auch noch die anderen Mails des
Threads einblendet, müssen diese anderen Mails natürlich deutlich
markiert werden, beispielsweise eben farblich.

Allerdings ist das erst sekundär. Zunächst müsste es ja überhaupt die
Möglichkeit geben, zusätzlich Mails im Thread zu matchen. Vielleicht
gibt's die ja sogar schon, aber ich kenne sie nicht... Bei Mutt weiß man
ja nie ;-)

> > Auch muss es möglich sein, falls man gesendete und empfangene Mails
> > im gleichen Ordner hat, gesendete Mails automatisch zu verstecken,
> > sobald die gleiche Mail (z.B. über eine Mailingliste) auch empfangen
> > wurde -- sonst wird das zu chaotisch.
> 
> Das kann mutt schon. Naja, nicht verstecken, aber zumindest markiert
> es Duplikate. Sie stehen direkt untereinander und sind in der Thread-
> Ansicht durch ein "=" gekennzeichnet. Sehr einfach und intuitiv, IMHO.

Das weiß ich natürlich, aber ich würde das chaotisch finden, wenn jede
von mir an eine Liste gesendete Mail auf diese Weise doppelt angezeigt
wird. Insbesondere wenn schon auf anderem Wege (beispielsweise ein
Cross-Posting) Duplikate vorhanden sind...

> Ungefragtes "Verstecken" hingegen würde in meinen Augen eher für
> Verwirrung sorgen. (ist die Mail schon in der Liste gelandet oder
> nicht? ...)

Würde es nicht, wenn man es richtig macht. Auch hier muss man das
natürlich deutlich visuell unterschieden (am besten wieder durch Farbe),
ob es sich um eine nur gesendete Mail handelt, oder eine extern
empfangene. Wenn man die gesendete sieht, weiß man halt, dass sie noch
nicht wieder zurückgekommen ist.

(Bei privaten Mailwechseln, wo die eigenen Mails nicht zurückkommen,
würden die gesendeten natürlich immer ihren Sonderstatus behalten -- was
aber auch wünschenswert ist.)

> Auf der anderen Seite stimme ich dir natürlich zu, dass das Tagging
> die Einsortierung in Folder ablösen müsste, denn Folder *und* Tagging,
> das wäre murks.

Richtig. Wobei ich bei einer Stelle eine Ausnahme in Erwägung ziehen
würde: Spam. Hier wäre es vermutlich sinnvoll, die weiterhin in einen
ganz eigenen Ordner zu verbannen: Zum einen, da sie sonst unnötig
Resourcen fressen. Zum anderen, damit externe Tools (Bayes-Filter,
Backup-Software) damit arbeiten können. Macht das ganze aber natürlich
auch viel umständlicher :-(

Am besten wäre es wohl, das transparent zu gestalten -- so dass im
Hintergrund Mails, die das spezielle Spam-Tag tragen, in einen extra
Ordner gepackt werden, aber von der UI her genauso behandlet werden, wie
die normalen...

-Olaf-