|
From: | Daniel J Sebald |
Subject: | Re: History changes |
Date: | Thu, 20 Dec 2012 18:05:14 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
On 12/20/2012 04:31 PM, Rik wrote:
On 12/20/2012 12:19 PM, address@hidden wrote:Message: 2 Date: Thu, 20 Dec 2012 14:55:28 -0500 From: "John W. Eaton"<address@hidden> To: Ben Abbott<address@hidden> Cc: octave maintainers mailing list<address@hidden> Subject: Re: clumsy patch for h = history (n) Message-ID:<address@hidden> Content-Type: text/plain; charset=us-ascii On 19-Dec-2012, Ben Abbott wrote: | On Dec 19, 2012, at 9:27 PM, John W. Eaton wrote: | |> On 19-Dec-2012, Ben Abbott wrote: |> |> | Perhaps the return cell-strings shouldn' t include the indices? |> |> Oops. I'm attaching an updated version of the changeset. |> |> jwe | | This one works for me! OK, I pushed it to savannah. I'll leave it to someone else to decide whether the doc strings should be updated.Yes to documentation. The coolest new features won't get used if no one knows about them. Also, should we have a sensible default value for N if history is called with no input? Previously, it would display the entire history starting from 1. This could be pages worth of text if you keep the default history_size of 1024. Now, the default is 1 which produces just the last command -- which is always history itself. This is odd. See sample session below. octave:8> x = 1 x = 1 octave:9> history 1033 history octave:10> history 1034 history
I've just tried history. Doesn't seem very useful to me if only because the list starts from oldest the progresses to most recent. (I've always typed code in a "scratch" file and block copied. Easy to save, easy to alter, easy to recall.) Here is a sample:
octave:1> history [pages of history information] 1020 plot(1:50) 1021 history 1022 version 1023 exit 1024 # Octave 3.7.0+, Thu Dec 20 17:43:34 2012 CST <sebald@> 1025 historyI would think most recent first is the way to go. Otherwise one has to scan all the way to the end of the list to get the more recent commands.
Also "# Octave 3.7.0+..." is placed in the history buffer when it really isn't something the user typed.
I think I once wrote a history feature for a different project and added what seemed to me to be much more useful options than the usual simple list. For example, it seems of no use to put numbers next to the history unless there is some useful feature that references that number. Say,
octave> history 1020in this case recalls line 1020 from the history buffer and either executes it or places it on the command line for editing. Tab completion within the history buffer would be nice, i.e., type "history plo" and tab complete or maybe just return and lists all command starting with "plo", ignoring white space.
It isn't the easiest algorithm to do this sort of stuff, I admit. There is buffer order, advancing the display counters so that the same number stays with the same command, sorting, etc. More difficult than one would expect.
I would think a value for N in the range of 10-20 would be a good default
Sure, but again, in my opinion there isn't much use to any of history unless it can be utilized a little more than a simple memory aid. Right now, if one pages through the history and finds the desired command, one can't highlight the text and copy, so copy-paste doesn't work. The center mouse button for highlight-paste doesn't work because one is in the pager, not at the command line.
Dan
[Prev in Thread] | Current Thread | [Next in Thread] |