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

[Juergen Sauermann]

  
  
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


  


  

[Bug-apl] Keyboard history control

[Elias Mårtenson]

With the new history control, none of the control-character shortcuts don't
work anymore, including C-p, C-n, C-f, C-b, C-a, C-e, C-k and C-y.

Could this be added? I suppose it's a simple matter of adding mappings to
existing functions.

Regards,
Elias

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

[Blake McBride]

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
>
>
>

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 
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:

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

[Blake McBride]

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
>>
>>
>>
>
>

[Bug-apl] What is the correct key code for diamond?

[Peter Teeson]

The subject says it all.

I have a glyph setup for my MacAplAlt but it must be the wrong key code.
Because if I use it I get Offending token…..SYNTAX ERROR.

So what is the correct one to use please?

Thanks….

Peter

[Bug-apl] What is the correct key code for diamond?

[David B. Lamkins]

U+25CA (from src/Avec.def)

Re: [Bug-apl] What is the correct key code for diamond?

[Peter Teeson]

Great thanks that fixed it.
On 2014-09-13, at 6:58 PM, David B. Lamkins  wrote:

> U+25CA (from src/Avec.def)