Dear Juergen, The default behavior now works as I would expect. Thanks a lot!
Blake On Sun, Sep 14, 2014 at 9:36 AM, Juergen Sauermann < juergen.sauerm...@t-online.de> wrote: > Hi Blake, > > done in SVN 472. See the new preferences file. > You can now choose between the old behavior, always inserting the > function text and inserting the function text only if the function has > changed. > > /// Jürgen > > > On 09/13/2014 03:12 PM, Blake McBride wrote: > > 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 >>> >>> >>> >> >> > >
