Re: [Bug-apl] History problem with GNU APL (not aplwrap)

[Juergen Sauermann]

Hi Blake, I believe it is more a matter of personal preferences how the history is used. I am more of a cut-and-paste guy than a scroll-up-and-down person and I find it convenient to show the history first and cut-and-paste it then. I believe we can all agree that the order in which function lines are entered by the user into the editor  is rather useless for all purposes. So the options remaining are 1) only show the opening line in the history (the old behavior), or 2) show the entire new function definition (the current behavior) I will make this configurable so that everybody can make himself happy. /// Jürgen On 09/13/2014 01:46 PM, Blake McBride wrote: Dear Juergen, I think there is a significant difference in philosophy here.  I think a history mechanism should keep a history of what _I_ type, but _not_ what is output by the system.  If I were to type in a new function, it should be added to history.  But if I list an existing function, it is displaying _output_ and _not_ what I am typing.  Having the system add its own output to history makes the history nearly unusable for me because I have to scroll through meaningless history in order to get to the last think I typed - in order to try that again.  This is a significant issue IMO. The rule should be "all user input goes into history" and "no system output goes into history". In the example I gave, I input the line to request the system to list the function.  The display of the function was system output and nothing I typed. Thanks. Blake On Sat, Sep 13, 2014 at 5:21 AM, Juergen Sauermann <juergen.sauerm...@t-online.de> wrote: Hi Blake, this is actually on purpose. The reason is replay of (or cut-and-paste from) history files. Previously (libreadline) only the opening of the function (∇test) would be stored in the history. The subsequent lines would be eaten by the ∇-editor until the function was closed. The new history outputs the entire function (so what you see in the )history is the entire function definition which is only by chance similar to the output of the [⎕] command:       ∇foo [1] 11 [2] 22 [3] 33 [4] ∇       )history       ∇foo           ∇foo       [1]   11       [2]   22       [3]   33           ∇ Looking at the above it seems like the first ∇foo in the history should be removed. An interesting question is if, for example, ∇foo[⎕]∇ should be handled differently than ∇foo That sounds reasonable at first sight but then  ∇foo[⎕]∇ would be differrent from ∇foo [⎕]∇ Another approach could be to not include function definitions that don't change the definition. But that would break       )LOAD foo_ws       ∇foo[⎕]∇ /// Jürgen On 09/12/2014 10:28 PM, Blake McBride wrote: Greetings, Create a function like this:       ∇test[⎕]∇     ∇ [0]   test [1]   abc [2]   def [3]   ghi     ∇ Then type:       45 45       55 55       ∇test[⎕]∇ [displays function] So, the last thing you typed was the _single_ line to display the function.  If you hit the up-arrow key you would expect to see:       ∇test[⎕]∇       55       45 but instead, somehow, the _output_ of the display function became _input_ history.  Not right. Thanks. Blake