I've made a fresh install of intellij after switching to v2016.1 and I noticed that I could not write the pipe character | anymore in the embedded terminal.
So I ran cat to see exactly what was going on, and it turns out that when using the alt key, the ESC character is prepended:
$ cat # type alt+shift+l
^[|
So I wonder if there is a (new?) option somewhere I might not be aware of?
It seems to be a known issue of 2016.1 versions: https://youtrack.jetbrains.com/issue/IDEA-152291
Related
Context:
I am trying to set up Powerline on WSL
On my Windows Machine
Which I have set up to be the terminal in Intellij which is running on windows
The colors were displayed in a very odd way. I came across the question How to change the output color of echo in Linux which suggested the use of the following command to test the color outputs.
for code in {0..255}; do echo -e "\033[48;5;${code}m $code "; done | paste - - - - - - - -
Which gave the following result.
I had similar results when trying to make use of the WSL bash terminal.
Edit: This only happens when in intellij. bash.exe and the ubuntu terminal do not have this issue.
What is the correct way to make use of 8-bit and/or 24-bit color in intellij/WSL?
As of Intellij Idea version 2021.3, the terminal now supports 24-bit color thanks to ConPTY support on Windows.
I use Ubuntu 18.04 on a WSL system and usually log on a Linux server through ssh to get some work done. When I activate 'screen' and use the tab key to autocomplete commands, my cursor goes to the end of line, and the formatting of my entire terminal breaks from then on.
When using vim in that condition on a screen terminal, if I go to the end of file and press down on more time, it erases the last line from the terminal.
It seems a kind of misinterpretation of some terminal signal. When using Putty or any other ssh client under the same circumstances, everything works fine, so I am pretty sure it is a problem with WSL environment, specifically.
Any ideas about what is the main issue and how to solve it?
I just came across this same exact issue and it appears to be a possible bug with Windows Console and certain $TERM values.
I have this problem when $TERM is set to screen-256color. The problem went away after setting $TERM to xterm-256color in .screenrc
$ cat ~/.screenrc
term xterm-256color
I have been using ConEmu for some time to run 'bash for windows', but all of the sudden it stopped working. When I launch a bash tab it now says:
ConEmuC: Root process was alive less than 10 sec, ExitCode=0.
Press Enter or Esc to close console...
I think this means that it launched something, but the shell closed quickly. I haven't changed anything that I can recall with the system, it just started doing that.
Windows version: 10 (build 15063)
ConEmu version: 180626 preview
No windows updates were done recently.
If I launch 'Bash on Ubuntu on Windows' from the start bar, it works fine (but I prefer using conemu as a terminal). Also, I can launch a cmd tab in conemu, then type bash and the bash shell will start. Unfortunately, launching bash in this way results in a lack of mouse support, and strange arrow key behavior.
I am at a bit of a loss. It worked perfectly previously... then it just stopped. Any help on how to debug or fix this would be appreciated.
If anybody finds this with a similar problem, my solution was to make a new task in ConEmu, with the command:
%windir%\system32\bash -l -i -cur_console:p5
The key is the -cur_console:p5, which sets the pty type as:
p[N] - pty modes, N - bitmask: 1 - XTermKeys, 2 - BrPaste, 4 - AppCursorKeys; default is 5 (1+4)
For some reason, setting p5 is necessary for me, despite it being listed as the default. Still not sure what changed, but at least it is working now.
I have the same problem but (for what it's worth) found that when it happens (varying between intermittent and incessant) restarting my machine fixes the issue every time.
This may seem like a stupid question, but I really can't find a way to open files from nautilus using jedit. I tried drag n drop and it doesn't work. Couldn't find any plugins in jedit to do this either.
Alternatively, I don't mind just double clicking to open, but I can't set jedit as default text editor application since it doesn't appear in my application list for some reason. So there's no way I can open the files from nautilus.
The only way i can open at the momemnt is either within jedit or in the terminal, but these are really inefficient for me. So it would be great if anyone could give me a hand in solving this trivial problem.
I did some googling and from here http://jedit-devel.narkive.com/3Qsqp2II/jedit-devel-jedit-drag-and-drop-bug-in-gnome, seems like the versions may be affecting this issue. Not sure about this. But here are my facts
java version "1.7.0_65"
jEdit 5.1.0
How about adding jEdit to List of Applications in “Open With” When Right-Clicking Files in Nautilus?
Instructions from https://ubuntugenius.wordpress.com/2012/06/18/ubuntu-fix-add-program-to-list-of-applications-in-open-with-when-right-clicking-files-in-nautilus/
For example, this is my jedit.desktop file:
$ cat /usr/share/applications/jedit.desktop
[Desktop Entry]
Version=1.0
Type=Application
Name=jEdit
GenericName=Text Editor
Comment=Text editor for code
Exec=jedit %F
Terminal=false
MimeType=text/plain;
Icon=jedit
Categories=TextEditor;Development;
StartupNotify=true
Actions=Window;Document;
[Desktop Action Window]
Name=New Window
Exec=jedit
OnlyShowIn=Unity;
[Desktop Action Document]
Name=New File
Exec=jedit
OnlyShowIn=Unity;
If you want to make jEdit the default for opening the particular filetype, you can now right-click one, choose Properties, go to the Open With tab, click on jEdit under Recommended Applications, and click the Set as default button.
Hope this helps.
This should work and works just fine for me.
If you are using the version included in the Ubuntu repository, try changing to our official version in our own repository as described on our homepage.
If you are using the official version, look in your Activity Log for anything suspicious when trying to drag&drop.
Also jEdit should be available as a normal Application and for "Open with Application..." just fine, at least with our official packages.
If all does not work, open a bug in the bugs tracker, then we can maybe help you better than here.
This might be something unique to my wonky machine running Ubuntu 12.04, but I found the line JAVA="${JAVA_HOME}/bin/java" to be the problem.
From a terminal, it resolves to the correct value of /usr/lib/jvm/java-8-oracle/bin/java.
However, from the desktop or launcher bar, it resolves to /com/home/users/current/local/java.
Maybe someone more learned than I can explain this, but my solution was to edit the file at /usr/local/bin/jedit, replacing the last line:
exec "${JAVA}" -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true -jar "/usr/local/share/jEdit/5.3.0/jedit.jar" -reuseview "$#"
With:
exec "java" -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true -jar "/usr/local/share/jEdit/5.3.0/jedit.jar" -reuseview "$#"
This only works if the JVM is set up properly.
I'm trying to use LiteIDE (the Go IDE) on Linux 32-bit. Everything works except for autocomplete. Builds, running, everything works. The gocode binary seems to be running tho:
ithisa#miyasa ~> ps aux | grep gocode
ithisa 10003 0.0 0.0 823788 2624 pts/1 Sl+ 09:06 0:00 /home/ithisa/scratch/liteide/bin/gocode -s -sock unix -addr localhost:37373
What might I be doing wrong?
You may need to set a GOROOT=. To set it within LiteIDE, look for the environment toolbar; it should be a a dropdown, probably with "system" preselected, and a button. Click the button to bring up the Edit Environment pane, then double-click "system.env", or whichever environment was picked in the dropdown.
Change the line that starts GOROOT= to point to your 'go' directory. Plain old $HOME/go is a common setting if you installed it from golang.org, and if you don't know where it is, running go env will show the GOROOT that the Go toolchain itself is using. And of course if the line is commented out (#GOROOT=...) remove the #. Save.
If the toolbar is missing entirely, View -> Environment toolbar unhides it.
It's probably also worth setting GOROOT and related settings in your .bashrc, so tools started from the command line see it. I installed Go and LiteIDE in my homedir and my workspace is ~/gocode, so mine is like:
export PATH="$HOME/go/bin:$HOME/liteide/bin:$PATH"
export GOROOT=$HOME/go
export GOPATH=$HOME/gocode
I can't be certain this is actually your issue, but if I unset my GOROOT the symptom matches what you're seeing: completion works on my code, but not on the standard library. Good luck!
Did you install gocode?
https://github.com/nsf/gocode
Also, does nothing autocomplete or just new packages? Packages need to be installed to autocomplete. Do you have a standard install setup?
Your GOROOT and GOPATH should also be correctly setup.
I've got the exact same problem, except for 64-bit linux (ArchLinux)
I got this solved by:
set up correct GOROOT and GOPATH, for example:
$ cat ~/.bashrc | grep GO
export GOROOT=/usr/lib/go
export GOPATH=~/goroot
PATH="$PATH:$GOPATH/bin"
bash
installing/starting gocode daemon
$ go get -u github.com/nsf/gocode
$ gocode -addr=:37373
$ gocode status
set correct GOROOT on LiteIDE config file:
sudo vim /usr/share/liteide/liteenv/linux64.env
GOROOT=/usr/lib/go
For me gocode (autocomplete) broke in LiteIDE after updating Go to the latest version.
What I did was make sure GOPATH was set correct. Then install gocode:
go get -u github.com/nsf/gocode
Then remove the gocode version from the liteide/bin/ folder, because else LiteIDE will use its own version (I only renamed it just in case).
Now when you boot LiteIDE it should say
GolangCode: Found gocode at <YOUR GOPATH>/bin/gocode
instead of LiteIDE using its own version.