I want a vim-like text editor to send code to REPLs including iPython in Windows. In Linux SLIMUX is perfect. (I use WSL often, but sometimes it's inconvenient.)
Let's start with ATOM's platformio-ide-terminal package. Here's the code I send:
and here's what get's sent to the iPython REPL running in Powershell:
For ordinary Python it does not do that; it works fine.
Let's go to NeoVim's iron.nvim, where things are even worse for iPython when sending a selection (<Plug>(iron-send-motion)):
In addition to adding extra characters, the iron.nvim send-selection command fails to even execute the command (an issue logged on Github). The just sits in the REPL until you switch vim windows, go into insert mode, and press enter. While it will not add extra characters to ordinary Python, it will still not execute it (this could be a separate issue).
What's going on with iPython and these extra characters? Is there any way to fix it? Why, on Windows, is it so difficult to send code from a text editor to an arbitrary REPL?
This post on the emacs stack exchange at least has a partial answer: At Version 5, iPython got a "new terminal interface" that was incompatible with Emacs' inferior shells. It makes sense that it would give Atom's and iron.nvim's a hard time as well.
For Atom, starting the shell with ipython --simple-prompt completely solves the problem. For iron.nvim, it at least gets rid of the bad characters. In iron.nvim, I've traded bad characters for the iPython multiline paste loosing its newlines, but that seems out of scope for this question.
Related
I was working on a Ruby program and had issues that I finally found out were caused by the default encoding in Windows 10 terminal, which apparently is CP850, an encoding so old it doesn't even include the € symbol. I read that, of course, if I try to change this other programs around the computer will give issues.
Wikipedia indicates that CP850 has theorically been "largely replaced" by Windows-1252 and, later, Unicode, and yet it's here, right in the OS's terminal.
Picture attached as proof. It's in italian language but you'll see it under "Tabella codici corrente", aka "Current code table".
How's that possible?
This is historical.
DOS had cp437, and later cp850 (and e.g. also cp852) as standard code page.
Terminal in Windows was also known as "DOS prompt": so a way to run DOS programs in Windows, so they keep the code page of DOS. Microsoft dislikes non-backward compatible changes, so your DOS program should works also on Windows terminal without problem.
Windows-1252, as the name stress it out, was done for Windows, so no compatibility problem, and for Windows programs, but so, in order to gain graphical interface market, but keeping compatibility with many business applications, Microsoft maintained two different code page.
I've been using GSView 5.0 and GhostScript 9.52 to do postscript printing on vellums. However, today GSView started throwing error codes on every .ps file I've attempted to print. I'm using Windows 10 Pro and the printer is an Epson Artisan 1430.
The error is as follows:
GPL Ghostscript 9.52: **** Could not open file 00000e60.
Unrecoverable error: invalidfileaccess in showpage
Operand stack:
--nostringval-- 1 true
gsapi_execute_cont returns -9
gsapi_exit returns 0
I've tried changing permissions for the files and different printer drivers to no avail. I'm sorry I can't be more descriptive on this issue as it's hard to articulate.
OK... You must have recently updated to a new version of Ghostscript. I can reproduce your problem, and it comes down to a recent (documented) change in behaviour for Ghostscript.
Due to the well-documented public disclosure of security exploits using Ghostscript a couple of years ago, the current version (and any version since 9.50) now defaults to running in SAFER mode.
When running in SAFER, Ghostscript prevents access by the PostScript interpreter to the file system. For those unaware of the problem; PostScript is a full-blown programming language and, by design, permits programs to access the underlying file system. SAFER mode prevents this so that malicious PostScript programs cannot, for example, run arbitrary code on your computer.
It seems that GSView is using Ghostscript in a way which requires it to read the PostScript program to be printed using the PostScript interpreter, instead of the more normal practice of specifying the input file as one of the arguments. For simplicity the input file is granted read availability by the Ghostscript executable. I suspect that GSview is using the DLL directly and not adding that extra information.
Now there are ways to permit access to specific files or folders, so that existing PostScript programs can continue to work, but obviously this requires some changes in the calling application. GSview has not changed in, literally, years so obviously it does not take any such action.
You can, however, get GSview to work as before. Under Options select Advanced Configure. In the resulting dialog look for the 'Ghostscript options' text box. In there add -dNOSAFER, that should get it to work again, though you may have to reboot the computer if the OS print subsystem has stalled.
Yes, this does open you up to the sorts of exploits I alluded to above, you should only do this with PostScript programs that you trust.
What methods are there to move the cursor in a command line app?
I've tried simpler things, such as using "\b", but that didn't work:
print("test\ba");
I expected the output tesa but I get testa (\b was ignored).
Update
Regarding (2), that was the output in the webstorm IDE, however it worked fine in the normal OS X Terminal.
On Linux or OSX you can use ANSI sequences https://en.wikipedia.org/wiki/ANSI_escape_code. On Windows you are pretty much out of luck AFAIK. Take a look at https://pub.dartlang.org/packages/ansicolor for an example how to use ANSI codes.
See also this similar question Clearing the terminal screen in a command-line Dart app
I use SPSS-22 on a Linux machine.
I would like to know, if I can somehow tell the editor to automatically introduce line breaks, once the edge of the window is reached, as I would like to insert some longer comments in the syntax without having to press return all the time.
The syntax editor will turn overly long lines red, but it will not wrap the lines for you. 251 characters is the maximum legal length, but you would probably not want lines that long in your output for readability, so wrapping them yourself is probably warranted.
You might be interested in the TEXT extension command for writing long comments that will appear in separate text blocks in the output rather than being buried in log blocks. TEXT supports html and rtf markup as well.
TEXT requires the (free) Python Essentials for Statistics. Details are on the SPSS Community website (www.ibm.com/developerworks/spssdevcentral), but the Essentials are automatically installed (unless you decline) with Statistics 22. I think TEXT is included in the Essentials, but if not, you can get it via the Download and Install Extension Bundles feature under Utilities.
I'm using P4COM to communicate with our perforce server. I have written an little utility to simplify our QA of what files have changed from one release to another. I have been using the P4COM interface from Delphi. So far so good.
I though it might be nice to allow users to view the diff between the two versions of the file from within my little utility rather than going back to p4v. So I print (get) the files at each revision using p4COM and the following command
print -o "E:\Development\TempProjects\p4Changes\temp\File_dispatch.pas#25" "//depot/mydepotpath/File_dispatch.pas"#25
and
print -o "E:\Development\TempProjects\p4Changes\temp\File_dispatch.pas#26" "//depot/mydepotpath/File_dispatch.pas"#26
However when I do this from my app using P4COM I seem to get random files (and they appear to be deleted ones). If I run the exact same command from the command line I get perfect results. Running both of these does return a file and correctly dumps it to disk where I want it, its just not the file I've asked for.
Any ideas?
Could it be a backslash issue in the command string? This would work fine at the command line, but a single backslash may be being interpreted as an escape code by whatever language compiler you are using (if C or C++, then this will definitely cause a problem, and that maybe happening under the hood on the P4COM side).
Try using double backslashes and see if that fixes it.
You're probably better of asking this to Perforce support itself, as this sounds like a bug in their software.
As a sidenote : Why do you use p4v? (I hugely prefer p4win myself)