Links sometimes try to open external program instead of code source file

[andrewaarestad]

Using Awesome Console 0.1337.8 on WebStorm 2019.3.5233.80

Sometimes when I click on a link parsed by Awesome Console, it will attempt to open an external program like Linguist. This seems to be intermittent unfortunately.

In the screenshot below, if I click on Link 1, it attempts to open Linguist. If I click on Link 2, it properly opens the source file.

Perhaps a way to deal with this would be adding an option that would restrict Awesome Console to only opening source files from the links it generates, and no external programs? Thank you and let me know if I can provide any more information!

[cfecherolle]

+1 to this, I sorta have the same problem but in my case, it opens the links with gedit (my default external editor, as it seems?). I can't figure how to fix this/force to open links in IntelliJ IDEA directly, and it was working properly before.

The problem seems to be present only with absolute paths, relative paths are working fine!

I'm currently using InteliiJ IDEA 2019.3.1 and Awesome Console 0.1337.8.

Also, feel free to ask me for more info if you have leads on this topic :)

[jjolmo]

I can confirm this bug too Happened on Webstorm using Fedora 31. I have added a BAD workaround to solve this: Since all my js/ts files are only opened in webstorm I changed the default app to be opened with webstorm. It is important to mark it to be opened in a terminal windows. Otherwise the files are not opened.

This is still not a good way to solve but I can stick with it until this get fixed

[anthraxx]

well that is the correct fix, some of those links are just regular file system links. Those will ultimately be opened defined by mimetype and default apps handling that mimetype. It indeed is the correct solution for such paths to be bound to the correct default application to open them.

Project local links only work for non absolute paths.

https://wiki.archlinux.org/index.php/XDG_MIME_Applications

[aepshteyn]

This plugin breaks code navigation in Python stack traces, which contain absolute paths.

Example:

Traceback (most recent call last):
  File "C:\Python27\lib\unittest\case.py", line 329, in run
    testMethod()
  File "C:\Users\Alex\Projects\Example\code\src\python\test\test_login.py", line 25, in testLoginTokenCookie
    self.doLogin(LoginHandler.getURI(), user, expectedCookieDomain=None)
  File "C:\Users\Alex\Projects\Example\code\src\python\test\test_login.py", line 41, in doLogin
    self.assertEqual(1, cookieJar)

Without this plugin, clicking these file links would open the source file with the cursor on the appropriate line in the (IntelliJ) editor. Now it just opens them in an external editor (Notepad++ in my case).

It appears that the Awesome Console plugin is not compatible with the native IntelliJ Python plugin. It should not be replacing the console links created by other plugins (especially built-in plugins from JetBrains).

@anthraxx I get what you're saying about the file type associations, but that logic doesn't apply in this case. These links are supposed to open inside IntelliJ regardless of the system-wide associations. The Python plugin handles them correctly, but Awesome Console breaks it, so this is a bug.

[adithyabsk]

I thought I'd bump this issue, I'm running into the same problem. I can definitely add filetype associations but for example, I might want a .rst file to open in PyCharm for a python project but in RubyMine for a ruby project

[twavv]

Project local links only work for non absolute paths.

Can this be changed? I get opening project-external files in external applications, but it doesn't make sense that a project file that was outputted as an absolute path opens in an external application. Basically, just some logic that says "if this path starts with PROJECT_ABS_PATH, open it locally", otherwise open is using the normal system tool.

For me, this makes fixing ESLint warnings nightmarish because it outputs the file names as absolute paths and so I can't click on them in the console.

[Dan1ve]

+1. This plugin is indeed awesome , but this is unfortunately a deal breaker for me...

[Bobronium]

It indeed is the correct solution for such paths to be bound to the correct default application to open them.

@anthraxx, it's not, when we deal with python traceback in python IDE which has built-in behaviour for paths in it. It's crucial for me to be able to navigate through the files and lines in traceback.

This plugin is indeed awesome , but this is unfortunately a deal breaker for me...

Same here

[davidecampello]

Hi, thanks for this awesome (console) plugin. Do you have any updates on this?