From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29 invoked from network); 25 Jan 2008 09:33:00 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.4 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 25 Jan 2008 09:33:00 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 88490 invoked from network); 25 Jan 2008 09:32:41 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 25 Jan 2008 09:32:41 -0000 Received: (qmail 18843 invoked by alias); 25 Jan 2008 09:32:31 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12478 Received: (qmail 18829 invoked from network); 25 Jan 2008 09:32:30 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 25 Jan 2008 09:32:30 -0000 Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by bifrost.dotsrc.org (Postfix) with ESMTP id 95C198028C6A for ; Fri, 25 Jan 2008 10:32:26 +0100 (CET) Received: by an-out-0708.google.com with SMTP id c14so157514anc.13 for ; Fri, 25 Jan 2008 01:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=nrm6hb9Fay0OPe8mhaWdpnrUUxpZFh2BfplfYVFob0A=; b=r/IlQh+s+91mcFCt//k7Vwnw+mYE3oLqRAiIjln9/fb6A0OPrB7nHAXYTuWDJMQ4dfRMmY1xixnFe5ejf+6ozHNniY8f8XQTPAWE6IGtg0tdYl2ChiWCDIvRIclA3z0/DXu0E0sUqwqSqpCAXPf90keCBqH5B4EhNrYqy8JaAl8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EnwePVkoMuTJaYroCByPVeZ3Em7YHYwJy4nxvTjMtBR1iWRRjIJX+Y+THnhhaCYydh8ADqadTafABZxNBRIC3C2Xa252xmQuy93/T09Hs02aQnNbCKTjbJAFJSdg/zajpnXwcU2AasY1XPMVnQ8c92HEnPbqIEF6gvmsnOr6RuE= Received: by 10.101.68.19 with SMTP id v19mr3779865ank.13.1201253545544; Fri, 25 Jan 2008 01:32:25 -0800 (PST) Received: by 10.100.143.1 with HTTP; Fri, 25 Jan 2008 01:32:25 -0800 (PST) Message-ID: <2d460de70801250132n1692f74cn78d3fdc40da88b9@mail.gmail.com> Date: Fri, 25 Jan 2008 10:32:25 +0100 From: "Richard Hartmann" To: "Robert Knight" , zsh-users@sunsite.dk Subject: Re: idea for new feature (was: Re: sticky-note and zle bindings) In-Reply-To: <13ed09c00801241857n2b1613f0m2d74fd12a90135cc@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <13ed09c00801241017x1cd7c454lcbf9156b6bccd9bb@mail.gmail.com> <2d460de70801241209u63a33fe6ufb8f396bff440dc6@mail.gmail.com> <2d460de70801241254v52d8a9c4he75e450f2f2bd29e@mail.gmail.com> <13ed09c00801241354g306f5aaay4d9e6f22c1622ec7@mail.gmail.com> <2d460de70801241522y47611d27k2e60c132fea1f01d@mail.gmail.com> <13ed09c00801241857n2b1613f0m2d74fd12a90135cc@mail.gmail.com> X-Virus-Scanned: ClamAV 0.91.2/5550/Fri Jan 25 08:02:45 2008 on bifrost X-Virus-Status: Clean On Jan 25, 2008 3:57 AM, Robert Knight wrote: > There is a misunderstanding. By "end the session", I meant ending a > session and removing all data associated with it. An analogy would be > the option not to save the tabs in a web browser when closing it. > Saving the session state would be the default behavior which would > occur when logging out of the X session or closing the shell by > sending SIGHUP for example. Oh, now I get it. Personally, I would prefer to keep X sessions around. Explicitly deleting them could simply be a built-in command. Finding, using and agreeing upon a control sequence seems like overkill, to me. One thing that would need to be decided is which sessions to delete first. Oldest overall, oldest upate, smallest footprint, largest footprint all have their respective merrits. Probably another option :) Another thing to note is that some people would probably want to keep the respective histories seperate, other would want to merge them on session 'detach', still others would probably want to merge the information on explicit session destruction. Option one could be done by hand by the route of .zsh_history.$SHELL_SESSION_COOKIE the others would probably, again, need options. Richard