From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 10.96.142.65 with SMTP id ru1csp163230qdb; Mon, 31 Mar 2014 20:55:20 -0700 (PDT) X-Received: by 10.194.57.38 with SMTP id f6mr10268836wjq.59.1396324520092; Mon, 31 Mar 2014 20:55:20 -0700 (PDT) Return-Path: Received: from mr.tuwien.ac.at (mr1.kom.tuwien.ac.at. [128.130.2.109]) by mx.google.com with ESMTPS id 49si25828731een.275.2014.03.31.20.55.19 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 31 Mar 2014 20:55:20 -0700 (PDT) Received-SPF: pass (google.com: domain of mbaehr@email.archlab.tuwien.ac.at designates 128.130.2.109 as permitted sender) client-ip=128.130.2.109; Authentication-Results: mx.google.com; spf=pass (google.com: domain of mbaehr@email.archlab.tuwien.ac.at designates 128.130.2.109 as permitted sender) smtp.mail=mbaehr@email.archlab.tuwien.ac.at Received: from email.archlab.tuwien.ac.at (email.archlab.tuwien.ac.at [128.131.118.17]) by mr.tuwien.ac.at (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id s313tHr6002627 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 1 Apr 2014 05:55:18 +0200 Received: from mbaehr by email.archlab.tuwien.ac.at with local (Exim 4.72) (envelope-from ) id 1WUpn6-0001C8-Re; Tue, 01 Apr 2014 05:55:12 +0200 Date: Tue, 01 Apr 2014 05:55:12 +0200 From: =?utf-8?q?Martin_B=C3=A4hr?= To: Gaute Hope Cc: sup-devel Message-ID: <1396324091-sup-9960@email.archlab.tuwien.ac.at> In-Reply-To: <1396299131-sup-5113@qwerzila> References: <1396168444-sup-8010@email.archlab.tuwien.ac.at> <1396294116-sup-6519@kpad> <1396299131-sup-5113@qwerzila> Subject: Re: [sup-devel] use-mail branch and other work Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable User-Agent: Sup/git X-Virus-Scanned: by amavisd-new Excerpts from Gaute Hope's message of 2014-03-31 22:57:06 +0200: > We could do something similar to what tagging and + does now, but > iterate over all the threads in the search without rendering them. > Unless the chunks are loaded it is a matter of loading it from the > index. It would be an extension to thread-index mode. Basically a > command: Apply an action to all threads matching the current search. It= > will be the equivalent of: Search + show all (!!) + tag all + > do action. yes, that's how i imagined to use it. btw: do action for all tagged blocks. with a few threads tagged or on a f= ast machine it's not noticable, but on a slower machine it is. if the above is solved to run in the background, then the current do acti= on for all tagged, could use the same mechanism. it is just a matter of which li= st of threads/messages the function receives to operate on: search + tag some messages + do action on tagged -> call action with list= of tagged messages. search + do action on search -> call action with list of matching message= s. same function for both, return to view immideately, maybe update view whe= n function completes greetings, martin. -- = eKita - the online platform for your entire academic = life hackerspace beijing - http://qike.= info -- = chief engineer eKit= a.co pike programmer pike.lysator.liu.se caudium.net societyserver= .org BLUG secretary beijinglug= .org foresight developer foresightlinux.org realss= .com unix sysadmin Martin B=C3=A4hr working in china http://societyserver.or= g/mbaehr/