Dear Juergen, Having a configuration option to have history only keep what I type, and not anything output by the system, is perfect.
Thanks. Blake On Sat, Sep 13, 2014 at 8:03 AM, Juergen Sauermann < juergen.sauerm...@t-online.de> wrote: > 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 >> >> >> > >
