[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: History changes
From: |
Rik |
Subject: |
Re: History changes |
Date: |
Thu, 20 Dec 2012 20:01:33 -0800 |
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