Re: History changes

[Rik]

On 12/20/2012 04:05 PM, Daniel J Sebald wrote:
> 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 history
>
> I 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 1020
>
> in 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.
Have you looked at 'run_history' and 'edit_history' for some of this
functionality?
>
> 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.
I find 'history -q' to remove the line numbers and then the left-mouse
button to highlight, middle button to paste works for my Linux system.  I'm
not seeing the same issues that you are with the pager, but I am running
'less' rather than 'more'.

--Rik