From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (71-38-131-64.ptld.qwest.net [71.38.131.64]) by hurricane.the-brannons.com (Postfix) with ESMTPSA id 160A4789E8 for ; Sun, 20 Sep 2015 01:41:56 -0700 (PDT) From: Chris Brannon To: Edbrowse-dev@lists.the-brannons.com References: <20150820015101.eklhad@comcast.net> Date: Sun, 20 Sep 2015 01:44:56 -0700 In-Reply-To: <20150820015101.eklhad@comcast.net> (Karl Dahlke's message of "Sun, 20 Sep 2015 01:51:01 -0400") Message-ID: <8737y9pjhz.fsf@mushroom.localdomain> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Edbrowse-dev] various new commands X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2015 08:41:56 -0000 Karl Dahlke writes: > g$ > go to the last link on the line. Yep, it seems to follow the principle of least astonishment. I like it. I frequently encounter pages with 12 links on a line, so this would be useful! i$* belongs, if for no other reason than regularity of the command set. > > lsl file length How would these work? Would they just operate on the current file? Another alternative would be to have a single lsf command that operates kind of like a toggle. Initially, you just see filenames in the buffer, like the situation today. But when lsf is invoked, the buffer is rebuilt to display stat info alongside each filename. Executing lsf again would hide the extra info. This one isn't all that important to me either way. > Should I continue to use