Closed ctron closed 2 years ago
LSP4E and Generic Editor use content-types for file associations.
I see DLTK has a more dynamic handling of content-types, using more extensions and a ShelledContentDescriber
. Using a similar definition for the content-type in ShellWax could solve the issue.
Do you have an example how to do such thing with GenericEditor?
It's not about Generic Editor, but about content-type. Mimicking DLTK content-type definition should work. However, the generic editor often only look at file-name for content-type resolution. So once you get the content-type dynamically resolved, then you may see some issues with Generic Editor or LSP4E regarding resolution, but 1st thing is that content-type resolution should resolve a file to the right content-type.
As end-user, you can go to the Preferences > General > Content-Types
page, find the Shell Script
content-type and add to the associated file names the filename you're targetting. Then the file will be understood as a Shell Script and everything should work (if not, it's bugs to report as such).
To implement this feature in ShellWax directly, we may be able to do it using ContentTypeDescriptors that allow to dynamically detect a content-type. However, I never tried them so I don't know their limitations. Maybe they wouldn't fit at all for that... The only way to know is to try ;)
Is this problem being worked on? It makes this plugin useless, if there is not an .sh
suffix there is usually not suffix at all so associating filenames via preferences isn't really a viable alternative...
You can associate a file name to a type without a suffix. That's typically what's done for Dockerfile or Jenkinsfile.
it seems rather evident to me (and I had therefore omitted it previously in order not to risk to offend the intelligence of the present ones) that there is a big difference between a file which is +/- standardly named Dockerfile
, Dockerfile.*
or *.Dockerfile
and a script that could have whatever name in any project. It is not?
I clearly don't want to setup a workspace-wide association where a test
file is always associated with shellwax cause in no situation I'd require to my devs to change their scaffolding because you know what, you can not longer use test
for your ruby script because now it is a reserved name we use for shell scripts :D
I think the existence of a "open with" feature within eclipse make a sense, I'm not sure why this plugin does not do that way, but once again, ATM it is substantially useless
I just started using Eclipse 2021-06 yesterday and had a very similar issue. I figured out a workaround that I use with Bash Editor but it should hopefully help someone here as well.
Short version: Change "Open unassociated files with:" to "Ask via pop-up"
Longer version:
go to Preferences > General > Editors > File Associations
Change "Open unassociated files with:" to "Ask via pop-up
"
Apply and Close
Now when you double-click a non .sh extension bash file, the Editor Selection window will pop up. Scroll within the Internal editors and double-click shellwax (or Bash Editor in my case). That's it. Syntax highlighting should be there.
The added beauty is that next time you double-click a file with no extension, your last editor selection should already be highlighted and all you need to do is click ok. So basically 3 clicks instead of 2 and and you have your syntax highlights and all.
Hope this helps.
I'm going to +1 on this issue. Especially for scripts which are usually some combination of non-extension files, files that are sourced vs. run and so on. The editor should be an option in the" associate with" preferences if you want this plugin to propagate. Just had to point my entire team to bash editor because of this issue.
The main issue is in how Eclipse Platform can handle content-types: basically, it cannot be configured to define a content-type for file-extension OR file content. So at the moment, either we keep identifying files by extensions (*.sh
and so on) or by Shebang (#! ... bash
).
If there is a consensus Shebang is to be preferred, we can associate with file-patterns *
and add a describer like
package org.eclipse.shellwax;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.Reader;
import org.eclipse.core.runtime.QualifiedName;
import org.eclipse.core.runtime.content.IContentDescription;
import org.eclipse.core.runtime.content.ITextContentDescriber;
public class ContentDescriber implements ITextContentDescriber {
@Override
public int describe(InputStream contents, IContentDescription description) throws IOException {
describe(new BufferedReader(new InputStreamReader(contents)), description);
}
@Override
public QualifiedName[] getSupportedOptions() {
return null;
}
@Override
public int describe(Reader contents, IContentDescription description) throws IOException {
String line = contents.readLine();
if (line == null) {
return INVALID;
}
if (line.startsWith("#!") && line.contains("bash")) {
return VALID;
}
return INVALID;
}
}
@akurtakov your call.
shebang requirement would be so many, many, many orders of magnitude less obtrusive as an opinion to enforce rather than file extension that I think a lot of people could really benefit from that, ie. use this plugin. Let's hope for the better, love! :heart:
Actually, se can relatively easily have both: keep content-type with extensions as it is right.now, and create a child content-type associated to * pattern and adding a describer to verify the shebang.
I played with the proposed fixed and submitted by mistake to the master branch instead of a local branch of mine to create a PR; I could revert it and create the PR and so on; but as build already completed and the risk of regression is relatively low, let's just leave it as it and assume it's fixed. Please try latest snapshots from https://download.eclipse.org/shellwax/snapshots/ and reopen if the issue is not fixed, or create new issues for further related issues.
My thanks for implementing the improvement so quickly (I don't see it as a bug per se). I look forward to trying it out.
There is official release with it now. Just update from https://download.eclipse.org/shellwax/releases/latest/
Just tried both sites above. I'm not seeing shellwax come up as an option on either the releases/latest or shellwax/snapshots sites shown above. It's possible the request should be re-opened.
Window>Preferences>General > Editors > File Associations > Associated Editors > Add
ShellWax 1.1.4.20211112-1345 org.eclipse.shellwax.feature.feature.group null ShellWax 1.1.5.20211112-1435 org.eclipse.shellwax.feature.feature.group null
You should not associate manually. It's autodone. With latest ShellWax just try opening file with proper shebang and without extension and it should auto open in shellwax. Note that if you have already manually selected some file to be opened with specific editor this is remembered. You can see association is there at Window>Preferences>General > Content Types >> Text > Shell Script > Shell Script (with shebang)
it works like a charm, whooooo... so many thanks! Ciao thx bye
Not all shell scripts have an extension of
.sh
. However this seems to be a requirement for this editor. With the Shell editor from Eclipse DLTK you could do "Open With", which also doesn't seem to work with ShellWax.I would expect the editor to also trigger when the file I edit has a
#!
that indicates Bash … e.g.#!/usr/bin/env bash
.