From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net Date: Wed, 2 Jul 2008 18:52:11 -0400 From: a@9srv.net In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-eisgkfqlifbjmgqtlepoijsaiq" Subject: Re: [9fans] acme scrollbar Topicbox-Message-UUID: d7d71140-ead3-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --upas-eisgkfqlifbjmgqtlepoijsaiq Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I dislike this idea. I think for most people, most of the time, the lines acme's working with will fit well within the width of a window. Yeah, I bet most of us have run into longer lines at times, but the interface is optimized for the common case. I wouldn't like to see that go. Having the "undo" (paralleling the "undo" of a 1-2, 1-3 chord) is very nice. The feature is certainly *not* "useless" for not being 100% reliable; what's it' off by, a line? Even that's a "good enough" job for your eye to find the line quick enough. Anthony --upas-eisgkfqlifbjmgqtlepoijsaiq Content-Type: message/rfc822 Content-Disposition: inline Received: from gouda.swtch.com ([67.207.142.3]) by 9srv.net; Wed Jul 2 18:34:49 EDT 2008 Received: from localhost ([127.0.0.1] helo=gouda.swtch.com) by gouda.swtch.com with esmtp (Exim 4.67) (envelope-from <9fans-bounces@9fans.net>) id 1KEAtt-0002Ch-Kg; Wed, 02 Jul 2008 22:34:09 +0000 Received: from fk-out-0910.google.com ([209.85.128.184]) by gouda.swtch.com with esmtp (Exim 4.67) (envelope-from <23hiro@googlemail.com>) id 1KEAts-0002Cc-0Z for 9fans@9fans.net; Wed, 02 Jul 2008 22:34:08 +0000 Received: by fk-out-0910.google.com with SMTP id b27so439221fka.0 for <9fans@9fans.net>; Wed, 02 Jul 2008 15:34:07 -0700 (PDT) Received: by 10.78.145.16 with SMTP id s16mr2147463hud.23.1215038046935; Wed, 02 Jul 2008 15:34:06 -0700 (PDT) Received: by 10.78.183.11 with HTTP; Wed, 2 Jul 2008 15:34:06 -0700 (PDT) Message-ID: Date: Thu, 3 Jul 2008 00:34:06 +0200 From: hiro <23hiro@googlemail.com> To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: <20080702221757.GA3742@shodan.homeunix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <989ef6acd802ba74b58860c093b87ef4@coraid.com> <20080702221757.GA3742@shodan.homeunix.net> Subject: Re: [9fans] acme scrollbar X-BeenThere: 9fans@9fans.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.9fans.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces@9fans.net Errors-To: 9fans-bounces+a=9srv.net@9fans.net On 7/3/08, Martin Neubauer wrote: > The left click is basically doing the opposite of the right click - it moves > the top line to the position of the click. That way a left click after a > right click restores the previous view of the file. (There may be some small > distortion due to lines longer than the width of the window but that doesn't > really matter much.) Oh, i ruled this possibility out, because I didn't see any opposite behaviour. The long lines *do* matter much. This feature is useless when it's unreliable. What do you think about my idea of moving the line to the bottom instead? --upas-eisgkfqlifbjmgqtlepoijsaiq--