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

Re-add "File Types" settings option #1543

Closed
Enhex opened this Issue Feb 10, 2017 · 12 comments

Comments

Projects
None yet
2 participants
@Enhex

Enhex commented Feb 10, 2017

CodeLite used to have settings option for "File Types" in CTag -> Advanced, which is missing now.
To edit this option users have to somehow discover m_fileSpec in the auto-completion.conf.

@eranif

This comment has been minimized.

Show comment
Hide comment
@eranif

eranif Feb 11, 2017

Owner

This is not going to get re-added.
What is the problem you are facing (obviously, the above is the solution you found for a problem)?

Owner

eranif commented Feb 11, 2017

This is not going to get re-added.
What is the problem you are facing (obviously, the above is the solution you found for a problem)?

@Enhex

This comment has been minimized.

Show comment
Hide comment
@Enhex

Enhex Feb 11, 2017

It can be useful for some users.
One use case is for users that want to use CodeLite with AngelScript scripting language, they need to add its file extension to the list:
http://discourse.urho3d.io/t/configuring-codelite-for-editing-as-scripts/68
https://wiki.frictionalgames.com/hpl3/3rdparty/codelite

Enhex commented Feb 11, 2017

It can be useful for some users.
One use case is for users that want to use CodeLite with AngelScript scripting language, they need to add its file extension to the list:
http://discourse.urho3d.io/t/configuring-codelite-for-editing-as-scripts/68
https://wiki.frictionalgames.com/hpl3/3rdparty/codelite

@eranif

This comment has been minimized.

Show comment
Hide comment
@eranif

eranif Feb 11, 2017

Owner

So IIRC, we want to handle *.as as valid C++ files, right? (it behaves the same except for the @ thingi?)
Or better: can you give me list of files to add? I will make sure it will be included everywhere so less configuration by your users is needed

Owner

eranif commented Feb 11, 2017

So IIRC, we want to handle *.as as valid C++ files, right? (it behaves the same except for the @ thingi?)
Or better: can you give me list of files to add? I will make sure it will be included everywhere so less configuration by your users is needed

@Enhex

This comment has been minimized.

Show comment
Hide comment
@Enhex

Enhex Feb 11, 2017

Yeah, the languages are similar enough for C++ IDEs to be usable with AngelScript code, but they're not identical so I'm not sure if it's a good idea to officially add it since it's a hack after all (No good IDEs for AngelScript AFAIK).

.as seems to be the common choice for AngelScript source file extension, but it conflicts with the file extension for the more popular Flash ActionScript.

Since it's a rather special use case I think leaving it for the user to config is ok.

Enhex commented Feb 11, 2017

Yeah, the languages are similar enough for C++ IDEs to be usable with AngelScript code, but they're not identical so I'm not sure if it's a good idea to officially add it since it's a hack after all (No good IDEs for AngelScript AFAIK).

.as seems to be the common choice for AngelScript source file extension, but it conflicts with the file extension for the more popular Flash ActionScript.

Since it's a rather special use case I think leaving it for the user to config is ok.

@eranif

This comment has been minimized.

Show comment
Hide comment
@eranif

eranif Feb 11, 2017

Owner

Flash ActionScript.

This is a dead language... no one uses it anymore, so I don't mind adding it as AngelScript

Owner

eranif commented Feb 11, 2017

Flash ActionScript.

This is a dead language... no one uses it anymore, so I don't mind adding it as AngelScript

@Enhex

This comment has been minimized.

Show comment
Hide comment
@Enhex

Enhex Feb 11, 2017

The only problem I can imagine is importing *.as files by mistake into C++ only project, and vice versa (if someone is messy enough to mix them somehow).
Other than that it could be a quick hack solution for people looking for a good AngelScript IDE, so it does have value.

Enhex commented Feb 11, 2017

The only problem I can imagine is importing *.as files by mistake into C++ only project, and vice versa (if someone is messy enough to mix them somehow).
Other than that it could be a quick hack solution for people looking for a good AngelScript IDE, so it does have value.

@eranif

This comment has been minimized.

Show comment
Hide comment
@eranif

eranif Feb 13, 2017

Owner

The docs mentions *.hps while you are talking about *.as is this a typo or both are valid file extensions for AngelScript?

Owner

eranif commented Feb 13, 2017

The docs mentions *.hps while you are talking about *.as is this a typo or both are valid file extensions for AngelScript?

@Enhex

This comment has been minimized.

Show comment
Hide comment
@Enhex

Enhex Feb 13, 2017

I didn't find any place in AngelScript's docs that describes a standard file extension, it's up to the users to choose.

Enhex commented Feb 13, 2017

I didn't find any place in AngelScript's docs that describes a standard file extension, it's up to the users to choose.

@eranif

This comment has been minimized.

Show comment
Hide comment
@eranif

eranif Feb 13, 2017

Owner

But it there some kind of defacto standard? (also in C++, there is no must have extension, just standard)

Owner

eranif commented Feb 13, 2017

But it there some kind of defacto standard? (also in C++, there is no must have extension, just standard)

@Enhex

This comment has been minimized.

Show comment
Hide comment
@Enhex

Enhex Feb 13, 2017

AngelScript's docs use .as in one place:
http://www.angelcode.com/angelscript/sdk/docs/manual/doc_hello_world.html

Why not let the user add extensions via the settings menu?

Enhex commented Feb 13, 2017

AngelScript's docs use .as in one place:
http://www.angelcode.com/angelscript/sdk/docs/manual/doc_hello_world.html

Why not let the user add extensions via the settings menu?

@eranif

This comment has been minimized.

Show comment
Hide comment
@eranif

eranif Feb 13, 2017

Owner

As a strategic decision, I am trying to reduce the number of configuration options. There are tons of them
I prefer to avoid it

Owner

eranif commented Feb 13, 2017

As a strategic decision, I am trying to reduce the number of configuration options. There are tons of them
I prefer to avoid it

@Enhex

This comment has been minimized.

Show comment
Hide comment
@Enhex

Enhex Feb 13, 2017

Completely removing configuration options makes the software less versatile, having them hidden virtually creates the same effect.

If the goal is simpler menus to make them easier to use, perhaps provide some sort of "advanced" checkbox to show options which are hidden by default?
Rarely used options should be hidden behind the advanced option, this way we hide usually unused options from cluttering the menus without removing them.

Enhex commented Feb 13, 2017

Completely removing configuration options makes the software less versatile, having them hidden virtually creates the same effect.

If the goal is simpler menus to make them easier to use, perhaps provide some sort of "advanced" checkbox to show options which are hidden by default?
Rarely used options should be hidden behind the advanced option, this way we hide usually unused options from cluttering the menus without removing them.

@eranif eranif closed this in 4fcf3f3 Feb 15, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment