Unable to paste any DFN from dfns website

[fourier]

Describe the issue you are having

On any attempt to copy/paste dfns from dfns.dyalog.com I get syntax error.

Did you connect to an already running interpreter or start the interpreter from RIDE?

Running interpreter

How do you reproduce the issue?

Open RIDE and connect/start interpreter. In the web browser (Firefox in my case) navigate to any of dfns from dfns.dyalog.com, i.e. http://dfns.dyalog.com/c_bags.htm Copy the dfn into the clipboard, and paste it into the RIDE. Observe the error on the 2nd line of dfn

Paste the contents of Help → About (Shift+F1)

All on Windows, 4.0.2860 4.1.2938

[JohnScholes]

Are you pasting directly into the session window? This won't (currently) work with multi-line dfns. Try opening an edit window ")ed bags" and pasting it there.

[abrudz]

Or even easier: )copy dfns bags

[fourier]

Yes I was posting to the session window. That is exactly a bug/feature request about, its not intuitive to either open a edit window or use it from supplied library. The multi-line dfn could be received from another source, i.e. wiki, forum, etc, and easiest is just paste it directly into the session window and test it immediately.

[romilly]

+1 to pasting multiple lines into the session window.

I've suffered the same frustration as Alexey. If my linux terminal window can cope with muli-line copy, surely RIDE can :)

On 9 February 2018 at 13:01, Alexey Veretennikov notifications@github.com wrote:

Yes I was posting to the session window. That is exactly a bug/feature request about, its not intuitive to either open a edit window or use it from supplied library. The multi-line dfn could be received from another source, i.e. wiki, forum, etc, and easiest is just paste it directly into the session window and test it immediately.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Dyalog/ride/issues/323#issuecomment-364427510, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJHPn2Mh9C8m7zxJKzwo4vu1Qijrqigks5tTEGRgaJpZM4R_o5N .

-- personal:@romillyc work:@rareblog skype:romilly.cocking web: http://blog.rareschool.com/

[e9gille]

Just to clarify, this isn't a limitation of RIDE. Defining multi-line dfns in the session works fine if you surround them with ∇. RIDE behaves the same way as the Windows IDE.

We could potentially:

• inspect the clipboard
• check if the content is likely a function definition
• prompt the user if they want to fix as function, or simply wrap it in ∇

I don't know if I like the idea of automatically adding text on paste without prompting the user. Trad functions are also near to impossible to detect. Perhaps a better option is to add a context menu Paste as function definition?

[fourier]

Yes it is not a limitation of the RIDE, but Windows IDE as well. Yet this behavior is different from other RERLs, i.e. scheme, python, common lisp, ruby etc, and the user shall expect the same behavior usability-wise as in other systems. I guess the matter is just to provide parsing for multi-line input, and dont consider newline as an end of input in case

• opening ∇ encountered and not closing ∇ yet;
• the opening { encountered and not closed } yet

so continue to read until the closing ∇ or } found and until next EOL ?

[romilly]

+1

On 14 February 2018 at 09:20, Alexey Veretennikov notifications@github.com wrote:

Yes it is not a limitation of the RIDE, but Windows IDE as well. Yet this behavior is different from other RERLs, i.e. scheme, python, common lisp, ruby etc, and the user shall expect the same behavior usability-wise as in other systems. I guess the matter is just to provide parsing for multi-line input, and dont consider newline as an end of input in case

• opening ∇ encountered and not closing ∇ yet;
• the opening { encountered and not closed } yet

so continue to read until the closing ∇ or } found and until next EOL ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Dyalog/ride/issues/323#issuecomment-365543360, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJHPmPHsnCh3c_tqmx3-IZ2-VnO10kRks5tUqVggaJpZM4R_o5N .

-- personal:@romillyc work:@rareblog skype:romilly.cocking web: http://blog.rareschool.com/

[JohnScholes]

FYI: There has been much discussion about "multi-line input to the session" along the lines that Alexey suggests. This would apply on all Dyalog platforms and encompass control structures as well as dfns. One of the details is that the session would need to identify multi-line input in its log so that the group of lines can be modified in the session history and re-submitted as a whole.

[romilly]

Ouch. You've just clarified what I really dislike about the Dyalog APL session, and why.

I'm used to working in terminal windows on linux.

If I'm working in exploratory programming mode in a terminal window, my work-flow goes like this: scroll back to he line I want to modify, or use Crtl-shift R to search for it, edit the current line and press enter.

I make the context switch between what I did before and what I want to do now without effort, and the process is pretty much the same whether I want to copy one line or many.

The session never changes; it's simply a record of what happened.

By contrast, I find the Dyalog session distracting, and at times confusing. If I want to copy a line and re-execute it I have to make a change to the line. (Maybe I'm missing out on a short-cut here?).

When I make a change I see it revert, and then the window scrolls. Neither event is relevant to my intention, and my flow of thought is disrupted as a result.

Of course, my prejudices are based around my habitual use of the Linux terminal Window, and most current Dyalog users will feel differently.

I'm not suggesting that you should change the default behaviour of the session. You'd be fighting against years of muscle memory in your paying customers, and they would not be happy. But I'd love to have a 'terminal window mode' switch available.

On 14 February 2018 at 09:47, JohnScholes notifications@github.com wrote:

FYI: There has been much discussion about "multi-line input to the session along the lines that Alexey suggests. This would apply on all Dyalog platforms and encompass control structures as well as dfns. One of the details is that the session would need to identify multi-line input in its log so that the group of lines can be modified in the session history and re-submitted as a whole.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Dyalog/ride/issues/323#issuecomment-365550312, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJHPvum1XEUP9OichDbIb96_wRgfatQks5tUqu4gaJpZM4R_o5N .

-- personal:@romillyc work:@rareblog skype:romilly.cocking web: http://blog.rareschool.com/

[JohnScholes]

There's an alternative in Dyalog, which is probably closer to your muscle memory: use Ctrl+Shift+Backspace to recall the prior input line for editing and resubmission. Repeated use of Ctrl+Shift+Backspace (BK) and Ctrl+Shift+Enter (FD) scrolls back and forth through all session input lines. I think this is similar to the facilities provided by Unix shells. For multi-line input, this would probably mean re-presenting the whole block for editing/resubmission. Or am I misunderstanding your objection?

[romilly]

Ah, that's much better. Thanks!

Is there an equivalent to Ctrl-shift-R (the regex history search?)

Oh - Ctrl-Shift-Backspace seems only to go back as far as the start of the current session :(

On 14 February 2018 at 10:49, JohnScholes notifications@github.com wrote:

There's an alternative in Dyalog, which is probably closer to your muscle memory: use Ctrl+Shift+Backspace to recall the prior input line for editing and resubmission. Repeated use of Ctrl+Shift+Backspace (BK) and Ctrl+Shift+Enter (FD) scrolls back and forth through all session input lines. I think this is similar to the facilities provided by Unix shells. For multi-line input, this would probably mean re-presenting the whole block for editing/resubmission. Or am I misunderstanding your objection?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Dyalog/ride/issues/323#issuecomment-365566051, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJHPkOELTjEVRq13lzKU4GRPTFsmfFgks5tUrotgaJpZM4R_o5N .

-- personal:@romillyc work:@rareblog skype:romilly.cocking web: http://blog.rareschool.com/

[fourier]

As a note to what John said I just rebind Ctrl-Shift-Bs and Ctrl-Shift-Enter to Ctrl-Up and Ctrl-Down, and can scroll through the history real quick then, as in terminal/other repls.

P.S. yes I've seen your comment just now, agree - if the input history will be global and separated from the session history it would be nice.

[jayfoad]

if the input history will be global

@romilly @fourier we do have internal Dyalog feature requests for this, though I can't promise if/when we'll get round to it.

[e9gille]

@fourier @romilly global history added in master (see prefs Code->Persistent history)

@jayfoad As this is not a RIDE issue I suggest we close this.

[fourier]

@e9gille but original problem was about copy-pasting multiline dfns, is it solved as well?

[e9gille]

The original problem would require a change to the interpreter rather than RIDE. If it is fixed there then it will also work in RIDE.

[fourier]

Ok.

[fourier]

Ok its up to @jayfoad to close this issue.

[e9gille]

Closing as it is an interpreter issue. If not already logged in Mantis, could you please add it @jayfoad.