Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Console: tab behaviour when pasting from clipboard #1164

Closed
x8x opened this issue May 8, 2015 · 10 comments
Closed

Console: tab behaviour when pasting from clipboard #1164

x8x opened this issue May 8, 2015 · 10 comments
Assignees
Labels
status.built A change in codebase has been done to address the ticket. status.tested The change in code has been manually tested and verified to fix the issue. type.bug Ticket describes an abnormal behavior, not conforming to the specs or expectation.

Comments

@x8x
Copy link
Contributor

x8x commented May 8, 2015

Could the tab autocompletion differentiate between typed TAB key and pasted text form clipboard containing tabs? If yes, tab autocompletion should probably always be turned off in such cases.

Currently, pasting this text sys(TAB)123 will return:
red>> system123
I'm not sure what would be the best solution, I think if pasting outside a string definition, tabs should be converted to spaces, so in the case above I should get:
red>> sys 123
with tab autocomplete turned off.

When pasting text containing tabs into a string definition (after an open { or an open ") tab autocompleting should be turned off and tabs converted to ^-, same treatment as CR and LF currently get.
So it would be great if after:
red>> {
pasting a string like sys(TAB)is(TAB)(LF)great} would return:
red>> {sys^-is^-^/great}

@x8x
Copy link
Contributor Author

x8x commented May 15, 2015

It can be dangerous!! check this example:

killme: does [q]

f: func [][
ki: 1
ki(TAB);comment
]

pasting above code in the console:

  killme: does [q]
;   func [][q]

  f: func [][
[    ki: 1
[    killme;comment
[    ]
;   func [][ki: 1 killme]

Calling the harmless 'f function! will call the could be evil 'killme function!
In this case it will luckily just quit.

@dockimbel dockimbel added type.review Ticket describes a possible improvement. Red labels Jan 15, 2016
@dockimbel dockimbel removed the Red label Mar 27, 2016
@dockimbel
Copy link
Member

Fixed by commit 7ee272a5.

@dockimbel dockimbel added status.built A change in codebase has been done to address the ticket. status.tested The change in code has been manually tested and verified to fix the issue. type.bug Ticket describes an abnormal behavior, not conforming to the specs or expectation. and removed type.review Ticket describes a possible improvement. labels May 10, 2016
@dockimbel dockimbel added this to the 0.6.1 milestone May 10, 2016
@x8x
Copy link
Contributor Author

x8x commented May 10, 2016

Not fixed, at least not on MacOS and Linux

@qtxie
Copy link
Contributor

qtxie commented May 10, 2016

Yes. CLI console still has this issue.

@qtxie
Copy link
Contributor

qtxie commented May 10, 2016

Actually in CLI console I cannot distinguish between the text from keyboard, and the text from clipboard.
So maybe we should provide a way to disable autocompletion, something like: system/console/auto-completion?: off.

@x8x
Copy link
Contributor Author

x8x commented May 10, 2016

nodejs has the same issue, probably because they also can't differentiate between typed vs pasted.
In node REPL, pasting conso(TAB)//123 will print console//123
I will do some research about this.

@x8x
Copy link
Contributor Author

x8x commented May 10, 2016

There is a nice solution working on MacOS and Linux: "Bracketed paste mode".
Quoting: "it enables something very cool: programs can tell the difference between stuff you type manually and stuff you pasted".
Have a look https://cirw.in/blog/bracketed-paste

@x8x
Copy link
Contributor Author

x8x commented May 12, 2016

Please reopen this one. 8-)

@qtxie qtxie reopened this May 12, 2016
@dockimbel dockimbel added status.reviewed Ticket has been reviewed and accepted for further processing. and removed status.built A change in codebase has been done to address the ticket. status.tested The change in code has been manually tested and verified to fix the issue. labels Jun 16, 2016
@dockimbel
Copy link
Member

@qtxie We can try that proposed solution, though it works probably only on Unix terminals, not in Windows DOS console.

@x8x
Copy link
Contributor Author

x8x commented Jun 16, 2016

👍

@dockimbel dockimbel modified the milestones: 0.6.1, 0.6.2 Jun 29, 2016
@dockimbel dockimbel added status.deferred Ticket's resolution is deferred for later processing (should be elaborated in comments). and removed status.reviewed Ticket has been reviewed and accepted for further processing. labels Mar 3, 2017
@dockimbel dockimbel modified the milestone: 0.6.2 Mar 26, 2017
@qtxie qtxie added status.built A change in codebase has been done to address the ticket. status.tested The change in code has been manually tested and verified to fix the issue. and removed status.deferred Ticket's resolution is deferred for later processing (should be elaborated in comments). labels May 10, 2017
@qtxie qtxie closed this as completed May 10, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status.built A change in codebase has been done to address the ticket. status.tested The change in code has been manually tested and verified to fix the issue. type.bug Ticket describes an abnormal behavior, not conforming to the specs or expectation.
Projects
None yet
Development

No branches or pull requests

3 participants