Geany Dev Team:
I have some additional ideas that I would like to share with you all and get feedback before I implement the code.
*./data/filetype_extensions.conf*
- Adding "*.s03;*.s79;*.s82;*.s90;*.s;*.S;" to "ASM=" *.s## - GNU-style Assembly (GAS/AT&T) Capital "S" - Must be preprocessed Lowercase "s" - Does not require preprocessing The numbers appended to *.s indicate the assembly version or intended microprocessor *.s is also used by Common Intermediate Language (CIL) which looks like assembly The Linux kernel contains some "*.S" files such as https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x8... Sources: http://labor-liber.org/en/gnu-linux/development/extensions http://wiki.linuxquestions.org/wiki/List_of_file_extensions#S https://en.wikipedia.org/wiki/Common_Intermediate_Language
- Adding "*.ll;" to "ASM=" I suggested this before, but I want to ensure that the team is okay with this idea before I commit and PR LLVM assembly ( http://linux.die.net/man/1/llvm-as )
- Adding "*.i;" to "C=" *.i - C source code which should not be preprocessed http://labor-liber.org/en/gnu-linux/development/extensions
- Adding "*.ii;" to "C++=" *.ii - C++ source code which should not be preprocessed http://labor-liber.org/en/gnu-linux/development/extensions
- Adding "*.r;*.f15;*.F15;" to "Fortran=" *.r - Fortran source code which must be preprocessed with a RATFOR preprocessor http://labor-liber.org/en/gnu-linux/development/extensions *.f15 - Fortran 2015 http://fortranwiki.org/fortran/show/File+extensions
- Adding "*.xaml;" to "XML=" XAML (Extensible Application Markup Language) This is a markup-language made by Microsoft XAML is used in .NET Framework 3 and 4 Mimetype = application/xaml+xml https://en.wikipedia.org/wiki/Extensible_Application_Markup_Language https://msdn.microsoft.com/en-us/library/cc295302.aspx https://msdn.microsoft.com/en-us/library/System.Windows.Markup.aspx
*Previous Ideas*
These proposed Python file-extensions are not officially mentioned in the Python Documentation. I shared this idea previously in the mailing list, but I would like to know if this idea is a possibility or a definite "no". However, some programmers use the extensions. - py2 and py3 Used to specifically distinguish Python3 code from Python2, especially when code is written that only works on one of the two versions. - pygtk Used to specifically show that a script contains PyGObject or PyGTK code, as opposed to Qt - pyqt Like pygtk, but used to specifically show that a script contains PySide or PyQt code
After reading my explanation, what do you think about the suggested Python extensions?
*Possible Ideas*
These are ideas that I am thinking about (or would like to hear your thoughts) before I proceed.
- Previously, I think mentioned adding XNA support. That idea will be delayed or never implemented because Microsoft discontinued XNA. In addition, I cannot find Microsoft's XNA specification. However, I would be willing to add XNA support if the Geany Dev Team thinks it would still be a good idea.
- I would like to add support for Qt's QML (Qt Meta Language or Qt Modeling Language). It is a scripting language that resembles JavaScript ( http://doc.qt.io/qt-5/qmlapplications.html ). If the Geany lexers and parsers highlight this language well, would it be a good idea to add it?
- Would it be a good idea to add Java bytecode files (*.class) to "ASM="? I do not know Java, so this may be a poor idea. https://en.wikipedia.org/wiki/Java_bytecode#Example
- In my opinion, it would be a good idea to add support for sed scripts ( http://www.grymoire.com/Unix/Sed.html#uh-20 && https://www.gnu.org/software/sed/manual/sed.html#Centering-lines ). They use the "*.sed" file-extension. However, I will need to experiment with the lexers and parsers.
- In addition, I could add awk scripts ( http://www.grymoire.com/Unix/Scripts/awk_print_squares.awk ). They use the "*.awk" file-extension. However, I will need to experiment with the lexers and parsers.
- Add support for FASTA ( https://en.wikipedia.org/wiki/FASTA_format && https://en.wikipedia.org/wiki/FASTA && http://fasta.bioch.virginia.edu/fasta_www2/fasta_list2.shtml ). I am not sure how you will all feel about this idea. FASTA is a file format used to represent nucleotide and peptide sequences. True, it is not a programming language, and I do not know yet if any lexer or parser used by Geany will work with FASTA. However, with the rise of "open-source biology", Boolean Integrase Logic (BIL) gates, and biochemical-based transistors (/DNA and RNA transistors = transcriptors/), this may be an idea to consider. Also, such a feature would make Geany stand-out among other "traditional" IDEs.
On 2015-11-08 2:34 PM, Devyn Collier Johnson wrote:
Geany Dev Team:
I have some additional ideas that I would like to share with you all and get feedback before I implement the code.
*./data/filetype_extensions.conf*
- Adding "*.s03;*.s79;*.s82;*.s90;*.s;*.S;" to "ASM="
*.s## - GNU-style Assembly (GAS/AT&T) Capital "S" - Must be preprocessed Lowercase "s" - Does not require preprocessing The numbers appended to *.s indicate the assembly version or intended microprocessor [...]
Does the ASM lexer support the AT&T syntax? I thought it was for Intel syntax (NASM/MASM/etc), but if not, adding .S seems to make sense, it's what GCC outputs when you tell it to generate only assembly (-S option IIRC).
- Adding "*.ll;" to "ASM="
I suggested this before, but I want to ensure that the team is okay with this idea before I commit and PR LLVM assembly ( http://linux.die.net/man/1/llvm-as )
Does the ASM lexer support LLVM IR? It's quite a bit different from either Intel or AT&T syntax.
[...]
- Adding "*.r;*.f15;*.F15;" to "Fortran="
*.r - Fortran source code which must be preprocessed with a RATFOR preprocessor
The *.r one is probably more commonly used for R language code, which is already in the filetype_extensions.conf. Adding it for Fortran means it will get used first, and R programmers will have to start editing the file manually to restore previous.
http://labor-liber.org/en/gnu-linux/development/extensions *.f15 - Fortran 2015 http://fortranwiki.org/fortran/show/File+extensions
- Adding "*.xaml;" to "XML="
XAML (Extensible Application Markup Language) This is a markup-language made by Microsoft XAML is used in .NET Framework 3 and 4 [...]
It's also used for non .NET-specific stuff like the Ribbon framework. Seems OK to add this one to me.
*Previous Ideas*
These proposed Python file-extensions are not officially mentioned in the Python Documentation. I shared this idea previously in the mailing list, but I would like to know if this idea is a possibility or a definite "no". However, some programmers use the extensions.
- py2 and py3
Used to specifically distinguish Python3 code from Python2, especially when code is written that only works on one of the two versions.
- pygtk
Used to specifically show that a script contains PyGObject or PyGTK code, as opposed to Qt
- pyqt
Like pygtk, but used to specifically show that a script contains PySide or PyQt code
After reading my explanation, what do you think about the suggested Python extensions?
I've been programming in Python for almost a decade and have never come across any of those extensions. Not that it means nobody uses them, just that they mustn't be very popular. Even IDLE doesn't recognize those extensions (at least on Windows 10).
*Possible Ideas*
[...]
- I would like to add support for Qt's QML (Qt Meta Language or Qt
Modeling Language). It is a scripting language that resembles JavaScript ( http://doc.qt.io/qt-5/qmlapplications.html ). If the Geany lexers and parsers highlight this language well, would it be a good idea to add it?
See http://wiki.geany.org/config/qml?s%5B%5D=qml
I've done similar before and the result was tolerable, though QtCreator has far better support for QML, so I use that when coding QtQuick stuff.
[...]
- Add support for FASTA ( https://en.wikipedia.org/wiki/FASTA_format &&
Seems a little esoteric.
Cheers, Matthew Brush
On 9 November 2015 at 05:34, Devyn Collier Johnson devyncjohnson@gmail.com wrote:
Geany Dev Team:
I have some additional ideas that I would like to share with you all and get feedback before I implement the code.
./data/filetype_extensions.conf
- Adding "*.s03;*.s79;*.s82;*.s90;*.s;*.S;" to "ASM="
*.s## - GNU-style Assembly (GAS/AT&T) Capital "S" - Must be preprocessed Lowercase "s" - Does not require preprocessing The numbers appended to *.s indicate the assembly version or intended microprocessor *.s is also used by Common Intermediate Language (CIL) which looks like assembly The Linux kernel contains some "*.S" files such as https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x8... Sources: http://labor-liber.org/en/gnu-linux/development/extensions http://wiki.linuxquestions.org/wiki/List_of_file_extensions#S https://en.wikipedia.org/wiki/Common_Intermediate_Language
The geany ASM parser specifies .s and .S so those should be ok, if they don't work for some special cases (eg CIL) that can't be helped. As for the other ASMs, well, if they work why no. Note that both the lexer and parser are pretty general, so there will be no specialisation for different extensions.
- Adding "*.ll;" to "ASM="
I suggested this before, but I want to ensure that the team is okay with this idea before I commit and PR LLVM assembly ( http://linux.die.net/man/1/llvm-as )
Well, if it works, though I am not sure if many people will edit LLVM. Remember that if we provide something by default we are advertising that it should work, and that users can reasonably raise bug reports if it doesn't. But we won't be able to support them. For obscure things I would prefer that the few who need it can add it to their own `filetype_extensions.conf`.
- Adding "*.i;" to "C="
*.i - C source code which should not be preprocessed http://labor-liber.org/en/gnu-linux/development/extensions
g++ treats this as C++, all languages are *not* C :)
This is the same problem as .h, it could be either.
- Adding "*.ii;" to "C++="
*.ii - C++ source code which should not be preprocessed http://labor-liber.org/en/gnu-linux/development/extensions
- Adding "*.r;*.f15;*.F15;" to "Fortran="
*.r - Fortran source code which must be preprocessed with a RATFOR preprocessor http://labor-liber.org/en/gnu-linux/development/extensions *.f15 - Fortran 2015 http://fortranwiki.org/fortran/show/File+extensions
I very much doubt that lexer and parser support these variants of fortran properly.
- Adding "*.xaml;" to "XML="
XAML (Extensible Application Markup Language) This is a markup-language made by Microsoft XAML is used in .NET Framework 3 and 4 Mimetype = application/xaml+xml https://en.wikipedia.org/wiki/Extensible_Application_Markup_Language https://msdn.microsoft.com/en-us/library/cc295302.aspx https://msdn.microsoft.com/en-us/library/System.Windows.Markup.aspx
Myeh, we should remove XML totally </reaction="allergic to XML"> :)
Previous Ideas
These proposed Python file-extensions are not officially mentioned in the Python Documentation. I shared this idea previously in the mailing list, but I would like to know if this idea is a possibility or a definite "no". However, some programmers use the extensions.
- py2 and py3
Used to specifically distinguish Python3 code from Python2, especially when code is written that only works on one of the two versions.
- pygtk
Used to specifically show that a script contains PyGObject or PyGTK code, as opposed to Qt
- pyqt
Like pygtk, but used to specifically show that a script contains PySide or PyQt code
After reading my explanation, what do you think about the suggested Python extensions?
Well, IMHO these should be rare, since they are not supported by the standard Python implementation, so again the users can add them to their personal `filetypes.extensions.conf` if they really want them.
Possible Ideas
These are ideas that I am thinking about (or would like to hear your thoughts) before I proceed.
- Previously, I think mentioned adding XNA support. That idea will be
delayed or never implemented because Microsoft discontinued XNA. In addition, I cannot find Microsoft's XNA specification. However, I would be willing to add XNA support if the Geany Dev Team thinks it would still be a good idea.
Unless you or someone else is clamouring for support of this (discontinued you say) language then I don't see the point, again it has to be supported.
This point applies to all the following as well. Things should not be added "just because they exist". There needs to be a demand for it to be available in Geany, it needs to be sensible, and some indication that the added features will be supported.
Rather too much gets dumped into open source projects and then left to fester </rant> :)
Many of the following are things that don't get edited often, or have better tools elsewhere, eg qtcreator for qml.
- I would like to add support for Qt's QML (Qt Meta Language or Qt Modeling
Language). It is a scripting language that resembles JavaScript ( http://doc.qt.io/qt-5/qmlapplications.html ). If the Geany lexers and parsers highlight this language well, would it be a good idea to add it?
- Would it be a good idea to add Java bytecode files (*.class) to "ASM="? I
do not know Java, so this may be a poor idea. https://en.wikipedia.org/wiki/Java_bytecode#Example
- In my opinion, it would be a good idea to add support for sed scripts (
http://www.grymoire.com/Unix/Sed.html#uh-20 && https://www.gnu.org/software/sed/manual/sed.html#Centering-lines ). They use the "*.sed" file-extension. However, I will need to experiment with the lexers and parsers.
- In addition, I could add awk scripts (
http://www.grymoire.com/Unix/Scripts/awk_print_squares.awk ). They use the "*.awk" file-extension. However, I will need to experiment with the lexers and parsers.
- Add support for FASTA ( https://en.wikipedia.org/wiki/FASTA_format &&
https://en.wikipedia.org/wiki/FASTA && http://fasta.bioch.virginia.edu/fasta_www2/fasta_list2.shtml ). I am not sure how you will all feel about this idea. FASTA is a file format used to represent nucleotide and peptide sequences. True, it is not a programming language, and I do not know yet if any lexer or parser used by Geany will work with FASTA. However, with the rise of "open-source biology", Boolean Integrase Logic (BIL) gates, and biochemical-based transistors (DNA and RNA transistors = transcriptors), this may be an idea to consider. Also, such a feature would make Geany stand-out among other "traditional" IDEs.
Geany stands out by being fast and lightweight, adding large amounts of rarely used excess baggage will kill that.
Cheers Lex
-- Thanks, Devyn Collier Johnson DevynCJohnson@Gmail.com
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 2015-11-08 3:19 PM, Lex Trotman wrote:
On 9 November 2015 at 05:34, Devyn Collier Johnson devyncjohnson@gmail.com wrote:
[...]
- Adding "*.i;" to "C="
*.i - C source code which should not be preprocessed http://labor-liber.org/en/gnu-linux/development/extensions
g++ treats this as C++, all languages are *not* C :)
This is the same problem as .h, it could be either.
I've been meaning to bring this up. We should move *.h to C++ now that C++ can use C tags. Having it under C means C++ headers don't work, but having it under C++ works for both C and C++ headers.
Cheers, Matthew Brush
On 2015-11-08 12:25 PM, Matthew Brush wrote:
On 2015-11-08 3:19 PM, Lex Trotman wrote:
On 9 November 2015 at 05:34, Devyn Collier Johnson devyncjohnson@gmail.com wrote:
[...]
- Adding "*.i;" to "C="
*.i - C source code which should not be preprocessed http://labor-liber.org/en/gnu-linux/development/extensions
g++ treats this as C++, all languages are *not* C :)
This is the same problem as .h, it could be either.
I've been meaning to bring this up. We should move *.h to C++ now that C++ can use C tags. Having it under C means C++ headers don't work, but having it under C++ works for both C and C++ headers.
Oops, I forgot the tags from the C++ header wouldn't be visible in C files (the opposite is not true). I still think *.h should be for C++, but it's probably a hard sell for Geany crowd, it being written in plain C and all :)
Cheers, Matthew Brush
On Sun, Nov 8, 2015 at 6:29 PM, Matthew Brush mbrush@codebrainz.ca wrote:
On 2015-11-08 12:25 PM, Matthew Brush wrote:
On 2015-11-08 3:19 PM, Lex Trotman wrote:
On 9 November 2015 at 05:34, Devyn Collier Johnson devyncjohnson@gmail.com wrote:
[...]
- Adding "*.i;" to "C="
*.i - C source code which should not be preprocessed http://labor-liber.org/en/gnu-linux/development/extensions
g++ treats this as C++, all languages are *not* C :)
This is the same problem as .h, it could be either.
I've been meaning to bring this up. We should move *.h to C++ now that C++ can use C tags. Having it under C means C++ headers don't work, but having it under C++ works for both C and C++ headers.
Oops, I forgot the tags from the C++ header wouldn't be visible in C files (the opposite is not true). I still think *.h should be for C++, but it's probably a hard sell for Geany crowd, it being written in plain C and all :)
I made it the opposite way too here (to be fully reviewed/merged):
https://github.com/techee/geany/commit/5c18b3d1328b8d3dff923a2a02bc3cc6b41a3...
see the langs_compatible() function. I would personally also like what you suggest but another problem is that e.g. a C variable named "template"(plus all the extra keywords C++ has) could screw up the parsing.
Cheers,
Jiri
On 9 November 2015 at 08:09, Jiří Techet techet@gmail.com wrote:
On Sun, Nov 8, 2015 at 6:29 PM, Matthew Brush mbrush@codebrainz.ca wrote:
On 2015-11-08 12:25 PM, Matthew Brush wrote:
On 2015-11-08 3:19 PM, Lex Trotman wrote:
On 9 November 2015 at 05:34, Devyn Collier Johnson devyncjohnson@gmail.com wrote:
[...]
- Adding "*.i;" to "C="
*.i - C source code which should not be preprocessed http://labor-liber.org/en/gnu-linux/development/extensions
g++ treats this as C++, all languages are *not* C :)
This is the same problem as .h, it could be either.
I've been meaning to bring this up. We should move *.h to C++ now that C++ can use C tags. Having it under C means C++ headers don't work, but having it under C++ works for both C and C++ headers.
Oops, I forgot the tags from the C++ header wouldn't be visible in C files (the opposite is not true). I still think *.h should be for C++, but it's probably a hard sell for Geany crowd, it being written in plain C and all :)
I made it the opposite way too here (to be fully reviewed/merged):
https://github.com/techee/geany/commit/5c18b3d1328b8d3dff923a2a02bc3cc6b41a3...
see the langs_compatible() function. I would personally also like what you suggest but another problem is that e.g. a C variable named "template"(plus all the extra keywords C++ has) could screw up the parsing.
Indeed, in fact that happened with Geany in the past, one of the headers used "template" (now changed to "temp") as a parameter name, so it was not possible to make C++ plugins since that header couldn't be included in C++.
Cheers,
Jiri
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 11/08/2015 03:19 PM, Lex Trotman wrote:
On 9 November 2015 at 05:34, Devyn Collier Johnson devyncjohnson@gmail.com wrote:
Geany Dev Team:
I have some additional ideas that I would like to share with you all and get feedback before I implement the code.
./data/filetype_extensions.conf
- Adding "*.s03;*.s79;*.s82;*.s90;*.s;*.S;" to "ASM="
*.s## - GNU-style Assembly (GAS/AT&T) Capital "S" - Must be preprocessed Lowercase "s" - Does not require preprocessing The numbers appended to *.s indicate the assembly version or intended microprocessor *.s is also used by Common Intermediate Language (CIL) which looks like assembly The Linux kernel contains some "*.S" files such as https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x8... Sources: http://labor-liber.org/en/gnu-linux/development/extensions http://wiki.linuxquestions.org/wiki/List_of_file_extensions#S https://en.wikipedia.org/wiki/Common_Intermediate_Language
The geany ASM parser specifies .s and .S so those should be ok, if they don't work for some special cases (eg CIL) that can't be helped. As for the other ASMs, well, if they work why no. Note that both the lexer and parser are pretty general, so there will be no specialisation for different extensions.
- Adding "*.ll;" to "ASM="
I suggested this before, but I want to ensure that the team is okay with this idea before I commit and PR LLVM assembly ( http://linux.die.net/man/1/llvm-as )
Well, if it works, though I am not sure if many people will edit LLVM. Remember that if we provide something by default we are advertising that it should work, and that users can reasonably raise bug reports if it doesn't. But we won't be able to support them. For obscure things I would prefer that the few who need it can add it to their own `filetype_extensions.conf`.
- Adding "*.i;" to "C="
*.i - C source code which should not be preprocessed http://labor-liber.org/en/gnu-linux/development/extensions
g++ treats this as C++, all languages are *not* C :)
This is the same problem as .h, it could be either.
- Adding "*.ii;" to "C++="
*.ii - C++ source code which should not be preprocessed http://labor-liber.org/en/gnu-linux/development/extensions
- Adding "*.r;*.f15;*.F15;" to "Fortran="
*.r - Fortran source code which must be preprocessed with a RATFOR preprocessor http://labor-liber.org/en/gnu-linux/development/extensions *.f15 - Fortran 2015 http://fortranwiki.org/fortran/show/File+extensions
I very much doubt that lexer and parser support these variants of fortran properly.
- Adding "*.xaml;" to "XML="
XAML (Extensible Application Markup Language) This is a markup-language made by Microsoft XAML is used in .NET Framework 3 and 4 Mimetype = application/xaml+xml https://en.wikipedia.org/wiki/Extensible_Application_Markup_Language https://msdn.microsoft.com/en-us/library/cc295302.aspx https://msdn.microsoft.com/en-us/library/System.Windows.Markup.aspx
Myeh, we should remove XML totally </reaction="allergic to XML"> :)
Previous Ideas
These proposed Python file-extensions are not officially mentioned in the Python Documentation. I shared this idea previously in the mailing list, but I would like to know if this idea is a possibility or a definite "no". However, some programmers use the extensions.
- py2 and py3
Used to specifically distinguish Python3 code from Python2, especially when code is written that only works on one of the two versions.
- pygtk
Used to specifically show that a script contains PyGObject or PyGTK code, as opposed to Qt
- pyqt
Like pygtk, but used to specifically show that a script contains PySide or PyQt code
After reading my explanation, what do you think about the suggested Python extensions?
Well, IMHO these should be rare, since they are not supported by the standard Python implementation, so again the users can add them to their personal `filetypes.extensions.conf` if they really want them.
Possible Ideas
These are ideas that I am thinking about (or would like to hear your thoughts) before I proceed.
- Previously, I think mentioned adding XNA support. That idea will be
delayed or never implemented because Microsoft discontinued XNA. In addition, I cannot find Microsoft's XNA specification. However, I would be willing to add XNA support if the Geany Dev Team thinks it would still be a good idea.
Unless you or someone else is clamouring for support of this (discontinued you say) language then I don't see the point, again it has to be supported.
This point applies to all the following as well. Things should not be added "just because they exist". There needs to be a demand for it to be available in Geany, it needs to be sensible, and some indication that the added features will be supported.
Rather too much gets dumped into open source projects and then left to fester </rant> :)
Many of the following are things that don't get edited often, or have better tools elsewhere, eg qtcreator for qml.
- I would like to add support for Qt's QML (Qt Meta Language or Qt Modeling
Language). It is a scripting language that resembles JavaScript ( http://doc.qt.io/qt-5/qmlapplications.html ). If the Geany lexers and parsers highlight this language well, would it be a good idea to add it?
- Would it be a good idea to add Java bytecode files (*.class) to "ASM="? I
do not know Java, so this may be a poor idea. https://en.wikipedia.org/wiki/Java_bytecode#Example
- In my opinion, it would be a good idea to add support for sed scripts (
http://www.grymoire.com/Unix/Sed.html#uh-20 && https://www.gnu.org/software/sed/manual/sed.html#Centering-lines ). They use the "*.sed" file-extension. However, I will need to experiment with the lexers and parsers.
- In addition, I could add awk scripts (
http://www.grymoire.com/Unix/Scripts/awk_print_squares.awk ). They use the "*.awk" file-extension. However, I will need to experiment with the lexers and parsers.
- Add support for FASTA ( https://en.wikipedia.org/wiki/FASTA_format &&
https://en.wikipedia.org/wiki/FASTA && http://fasta.bioch.virginia.edu/fasta_www2/fasta_list2.shtml ). I am not sure how you will all feel about this idea. FASTA is a file format used to represent nucleotide and peptide sequences. True, it is not a programming language, and I do not know yet if any lexer or parser used by Geany will work with FASTA. However, with the rise of "open-source biology", Boolean Integrase Logic (BIL) gates, and biochemical-based transistors (DNA and RNA transistors = transcriptors), this may be an idea to consider. Also, such a feature would make Geany stand-out among other "traditional" IDEs.
Geany stands out by being fast and lightweight, adding large amounts of rarely used excess baggage will kill that.
Cheers Lex
-- Thanks, Devyn Collier Johnson DevynCJohnson@Gmail.com
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Geany Dev Team:
Thank you Lex Trotman and Matthew Brush for your time, effort, and insightful feedback.
Thanks Matthew for the QML link; I greatly appreciate it. I added the code to my system. Could we add this to the mainstream Geany? True, QtCreator may have better support, but some people prefer Geany over all IDEs (including me).
Okay. I just thought I could at least suggest FASTA. To me, it seems like a good idea, although very odd and unusual for a programming IDE. Sometimes, I like to make wild ideas because such ideas may become a "brilliant idea". However, I understand the team's viewpoint.
True, one of Geany's best features is that it is fast and light-weight. However, are there any benchmarks that indicate a significant performance drop when adding many file-extensions and file-types?
Perhaps, a "plugin" could be made that has support for extra and "weird" file-extensions and file-types. Could Geany be modified to also look for a "filetypes_extension_extra.conf" file that would contain such file-extensions? For instance, an additional package could be made that contains "filetypes_extension_extra.conf" and various filetypes.*.conf files. If the user downloads and installs this package, Geany will see "filetypes_extension_extra.conf" and merge the contents to "filetypes_extension.conf" and load the related filetypes.*.conf files. Such a feature may help us with development. For instance, we could use such a feature for testing proposed file and language support and provide "backported" and unstable file-extension support. As a specific example, the Manpage file-extensions I proposed could be added to such a package until Scintilla adds highlighting support for Manpages. Do you understand what I am saying? Would this be a possible idea to consider?
*Will Not Add*
These are ideas that I will not add after hearing the team's viewpoints and after I have reconsidered and pros and cons.
- *.ll: Good point, Matthew and Lex. - Python: Okay, I will not worry about the suggested extensions. - *.r: Thank you, Matthew, for pointing that out. I knew that R used the "*.R" extension, but I was unaware of "*.r". - XNA: I do not know XNA very well neither do I personally care about XNA. I just wanted to ensure that Geany supports XNA for those that do like XNA. However, since XNA is discontinued and I cannot find the specification, I will not add XNA. Unless, in the future, support is desirable. - Java Bytecode - I did more research, and I feel that this idea can be dropped.
Lex, I assume you are joking about removing "XML=", right? In my opinion, XML support in Geany is a "must".
*Will Add Soon*
These are ideas that I feel are beneficial and that the team approves.
- Add "*.f15;*.F15;" to "Fortran=" *.f15 = Fortran 2015 I do not know Fortran, but if highlighting does not work well with Fortran 2015, perhaps it will when Scintilla adds updates for this new Fortran standard http://fortranwiki.org/fortran/show/File+extensions
- Add "*.xaml;" to "XML=" XAML (Extensible Application Markup Language) This is a markup-language made by Microsoft XAML is used in .NET Framework 3 and 4 Mimetype = application/xaml+xml https://en.wikipedia.org/wiki/Extensible_Application_Markup_Language https://msdn.microsoft.com/en-us/library/cc295302.aspx https://msdn.microsoft.com/en-us/library/System.Windows.Markup.aspx
- Adding "*.ii;" to "C++=" *.ii - C++ source code which should not be preprocessed http://labor-liber.org/en/gnu-linux/development/extensions
*May Add/Consider*
These are ideas that I may reconsider, or I would like to hear your further thoughts.
- *.s: True, the ASM lexer does not support AT&T syntax. However, if Geany recognizes the file-type, then the Assembly tools listed in the "Build" menu are available. - *.i: *.i and *.ii are different. "i" is for C, and "ii" is for C++ - *.sed and *.awk: Sed and Awk are commonly used on Unixoid (Unix systems and Unix-like systems) systems. Are you sure that this idea should be dropped?
*Additional Comments*
By the way, I would like to thank everyone in the Geany Dev Team for their time, effort, and support. I am also thankful for being a part of the team.
What must I do to earn a spot under "Contributors" in Geany's "Credits" tab of the "About" window?
-- Thanks, Devyn Collier Johnson DevynCJohnson@Gmail.com
Geany Dev Team:
Thank you Lex Trotman and Matthew Brush for your time, effort, and insightful feedback.
Thanks Matthew for the QML link; I greatly appreciate it. I added the code to my system. Could we add this to the mainstream Geany? True, QtCreator may have better support, but some people prefer Geany over all IDEs (including me).
Is there a lexer that works *right* and/or a parser that works *right* for QML? If there are no parsers or lexers adding a filetype is pretty much a waste of time.
Okay. I just thought I could at least suggest FASTA. To me, it seems like a good idea, although very odd and unusual for a programming IDE. Sometimes, I like to make wild ideas because such ideas may become a "brilliant idea". However, I understand the team's viewpoint.
True, one of Geany's best features is that it is fast and light-weight. However, are there any benchmarks that indicate a significant performance drop when adding many file-extensions and file-types?
Adding extensions doesn't have a material cost, except that *the filetype has to work* or it brings bug reports. Adding filetypes has some cost, particularly in the support of the filetype when Geany devs don't know the language.
Perhaps, a "plugin" could be made that has support for extra and "weird" file-extensions and file-types. Could Geany be modified to also look for a "filetypes_extension_extra.conf" file that would contain such file-extensions?
No point, all the extensions have to be loaded so Geany can check for the extension of the file being opened to select the filetype (assuming no magic incantations are present).
For instance, an additional package could be made that contains "filetypes_extension_extra.conf" and various filetypes.*.conf files. If the user downloads and installs this package, Geany will see "filetypes_extension_extra.conf" and merge the contents to "filetypes_extension.conf" and load the related filetypes.*.conf files.
Packaging is not something Geany does, thats the distro's job.
What you could do is add custom filetypes that use existing lexers and parsers to the wiki http://wiki.geany.org/filetype?do=showtag&tag=filetype. That makes them available to others.
NOTE if a page already exists, add yours as another, do NOT overwrite someone elses page, it will get yours reverted when it is noticed.
Such
a feature may help us with development. For instance, we could use such a feature for testing proposed file and language support and provide "backported" and unstable file-extension support. As a specific example, the Manpage file-extensions I proposed could be added to such a package until Scintilla adds highlighting support for Manpages. Do you understand what I am saying? Would this be a possible idea to consider?
I don't think people should be editing manpage formats these days, they should be using one of the lightweight markups that compile to manpages. There has not been a huge demand for editing manpages that I'm aware of. Again I emphasise that just adding filetypes brings a support cost that detracts from other efforts.
Will Not Add
These are ideas that I will not add after hearing the team's viewpoints and after I have reconsidered and pros and cons.
- *.ll: Good point, Matthew and Lex.
- Python: Okay, I will not worry about the suggested extensions.
- *.r: Thank you, Matthew, for pointing that out. I knew that R used the
"*.R" extension, but I was unaware of "*.r".
- XNA: I do not know XNA very well neither do I personally care about XNA. I
just wanted to ensure that Geany supports XNA for those that do like XNA. However, since XNA is discontinued and I cannot find the specification, I will not add XNA. Unless, in the future, support is desirable.
- Java Bytecode - I did more research, and I feel that this idea can be
dropped.
Lex, I assume you are joking about removing "XML=", right? In my opinion, XML support in Geany is a "must".
Oh I suppose so ;)
Will Add Soon
These are ideas that I feel are beneficial and that the team approves.
- Add "*.f15;*.F15;" to "Fortran="
*.f15 = Fortran 2015 I do not know Fortran, but if highlighting does not work well with Fortran 2015, perhaps it will when Scintilla adds updates for this new Fortran standard http://fortranwiki.org/fortran/show/File+extensions
- Add "*.xaml;" to "XML="
XAML (Extensible Application Markup Language) This is a markup-language made by Microsoft XAML is used in .NET Framework 3 and 4 Mimetype = application/xaml+xml https://en.wikipedia.org/wiki/Extensible_Application_Markup_Language https://msdn.microsoft.com/en-us/library/cc295302.aspx https://msdn.microsoft.com/en-us/library/System.Windows.Markup.aspx
Again havn't seen the demand.
- Adding "*.ii;" to "C++="
*.ii - C++ source code which should not be preprocessed http://labor-liber.org/en/gnu-linux/development/extensions
May Add/Consider
These are ideas that I may reconsider, or I would like to hear your further thoughts.
- *.s: True, the ASM lexer does not support AT&T syntax. However, if Geany
recognizes the file-type, then the Assembly tools listed in the "Build" menu are available.
Are these assemblers the same command as that provided by the filetype?
- *.i: *.i and *.ii are different. "i" is for C, and "ii" is for C++
Yes, but g++ still accepts and reads .i files as C++.
- *.sed and *.awk: Sed and Awk are commonly used on Unixoid (Unix systems
and Unix-like systems) systems. Are you sure that this idea should be dropped?
Do you have a working lexer or parser?
Additional Comments
By the way, I would like to thank everyone in the Geany Dev Team for their time, effort, and support. I am also thankful for being a part of the team.
What must I do to earn a spot under "Contributors" in Geany's "Credits" tab of the "About" window?
I thought it was scraped from the commits, but I may be wrong.
-- Thanks, Devyn Collier Johnson DevynCJohnson@Gmail.com
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 11/09/2015 07:31 PM, Lex Trotman wrote:
Geany Dev Team:
Thank you Lex Trotman and Matthew Brush for your time, effort, and insightful feedback.
Thanks Matthew for the QML link; I greatly appreciate it. I added the code to my system. Could we add this to the mainstream Geany? True, QtCreator may have better support, but some people prefer Geany over all IDEs (including me).
Is there a lexer that works *right* and/or a parser that works *right* for QML? If there are no parsers or lexers adding a filetype is pretty much a waste of time.
Okay. I just thought I could at least suggest FASTA. To me, it seems like a good idea, although very odd and unusual for a programming IDE. Sometimes, I like to make wild ideas because such ideas may become a "brilliant idea". However, I understand the team's viewpoint.
True, one of Geany's best features is that it is fast and light-weight. However, are there any benchmarks that indicate a significant performance drop when adding many file-extensions and file-types?
Adding extensions doesn't have a material cost, except that *the filetype has to work* or it brings bug reports. Adding filetypes has some cost, particularly in the support of the filetype when Geany devs don't know the language.
Perhaps, a "plugin" could be made that has support for extra and "weird" file-extensions and file-types. Could Geany be modified to also look for a "filetypes_extension_extra.conf" file that would contain such file-extensions?
No point, all the extensions have to be loaded so Geany can check for the extension of the file being opened to select the filetype (assuming no magic incantations are present).
For instance, an additional package could be made that contains "filetypes_extension_extra.conf" and various filetypes.*.conf files. If the user downloads and installs this package, Geany will see "filetypes_extension_extra.conf" and merge the contents to "filetypes_extension.conf" and load the related filetypes.*.conf files.
Packaging is not something Geany does, thats the distro's job.
What you could do is add custom filetypes that use existing lexers and parsers to the wiki http://wiki.geany.org/filetype?do=showtag&tag=filetype. That makes them available to others.
NOTE if a page already exists, add yours as another, do NOT overwrite someone elses page, it will get yours reverted when it is noticed.
Such
a feature may help us with development. For instance, we could use such a feature for testing proposed file and language support and provide "backported" and unstable file-extension support. As a specific example, the Manpage file-extensions I proposed could be added to such a package until Scintilla adds highlighting support for Manpages. Do you understand what I am saying? Would this be a possible idea to consider?
I don't think people should be editing manpage formats these days, they should be using one of the lightweight markups that compile to manpages. There has not been a huge demand for editing manpages that I'm aware of. Again I emphasise that just adding filetypes brings a support cost that detracts from other efforts.
Will Not Add
These are ideas that I will not add after hearing the team's viewpoints and after I have reconsidered and pros and cons.
- *.ll: Good point, Matthew and Lex.
- Python: Okay, I will not worry about the suggested extensions.
- *.r: Thank you, Matthew, for pointing that out. I knew that R used the
"*.R" extension, but I was unaware of "*.r".
- XNA: I do not know XNA very well neither do I personally care about XNA. I
just wanted to ensure that Geany supports XNA for those that do like XNA. However, since XNA is discontinued and I cannot find the specification, I will not add XNA. Unless, in the future, support is desirable.
- Java Bytecode - I did more research, and I feel that this idea can be
dropped.
Lex, I assume you are joking about removing "XML=", right? In my opinion, XML support in Geany is a "must".
Oh I suppose so ;)
Will Add Soon
These are ideas that I feel are beneficial and that the team approves.
- Add "*.f15;*.F15;" to "Fortran="
*.f15 = Fortran 2015 I do not know Fortran, but if highlighting does not work well with Fortran 2015, perhaps it will when Scintilla adds updates for this new Fortran standard http://fortranwiki.org/fortran/show/File+extensions
- Add "*.xaml;" to "XML="
XAML (Extensible Application Markup Language) This is a markup-language made by Microsoft XAML is used in .NET Framework 3 and 4 Mimetype = application/xaml+xml https://en.wikipedia.org/wiki/Extensible_Application_Markup_Language https://msdn.microsoft.com/en-us/library/cc295302.aspx https://msdn.microsoft.com/en-us/library/System.Windows.Markup.aspx
Again havn't seen the demand.
- Adding "*.ii;" to "C++="
*.ii - C++ source code which should not be preprocessed http://labor-liber.org/en/gnu-linux/development/extensions
May Add/Consider
These are ideas that I may reconsider, or I would like to hear your further thoughts.
- *.s: True, the ASM lexer does not support AT&T syntax. However, if Geany
recognizes the file-type, then the Assembly tools listed in the "Build" menu are available.
Are these assemblers the same command as that provided by the filetype?
- *.i: *.i and *.ii are different. "i" is for C, and "ii" is for C++
Yes, but g++ still accepts and reads .i files as C++.
- *.sed and *.awk: Sed and Awk are commonly used on Unixoid (Unix systems
and Unix-like systems) systems. Are you sure that this idea should be dropped?
Do you have a working lexer or parser?
Additional Comments
By the way, I would like to thank everyone in the Geany Dev Team for their time, effort, and support. I am also thankful for being a part of the team.
What must I do to earn a spot under "Contributors" in Geany's "Credits" tab of the "About" window?
I thought it was scraped from the commits, but I may be wrong.
-- Thanks, Devyn Collier Johnson DevynCJohnson@Gmail.com
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Geany Dev Team:
Thanks again, Lex Trotman, for your feedback.
When I was referring to "packages" when discussing "filetypes_extension_extra.conf", I did not mean files like *.deb. I mean "package" as in a general file containing multiple files. In other words, I meant that Geany.org could have a Tarball available for download that contains additional file-extensions. True, I should have explained my idea more clearly.
I have not tested *.sed and *.awk, yet. Everything listed under "May Consider" are ideas I thought about, but have not yet coded or tested. I wanted to get the team's thoughts before I put time into testing and coding an idea that the team may consider a definite "no". Anything listed under "Will Add Soon", "Will Add", and similar headers are file-types I have either tested or I am currently using. So, to rephrase the question about *.sed and *.awk, if I were to find a parser and lexer that works, would *.sed and *.awk be considerable?
As far as *.ii is concerned, I will wait until standards change or if Geany gains support for headers that may be C or C++ implicitly. (NOTE: For instance, *.h++ and *.hpp are explicitly C++ headers)
I will be sure to try to be more clear with my proposals.
-- Thanks, Devyn Collier Johnson DevynCJohnson@Gmail.com
Geany Dev Team:
Thanks again, Lex Trotman, for your feedback.
When I was referring to "packages" when discussing "filetypes_extension_extra.conf", I did not mean files like *.deb. I mean "package" as in a general file containing multiple files. In other words, I meant that Geany.org could have a Tarball available for download that contains additional file-extensions. True, I should have explained my idea more clearly.
Definitely something on the wiki.
I have not tested *.sed and *.awk, yet. Everything listed under "May Consider" are ideas I thought about, but have not yet coded or tested. I wanted to get the team's thoughts before I put time into testing and coding an idea that the team may consider a definite "no". Anything listed under "Will Add Soon", "Will Add", and similar headers are file-types I have either tested or I am currently using. So, to rephrase the question about *.sed and *.awk, if I were to find a parser and lexer that works, would *.sed and *.awk be considerable?
Well, to save you the search Scintilla has no lexer for either awk or sed so no highlighting. ctags has a parser for awk which would at least give you the symbol pane but nothing for sed.
But frankly, as much as I love dear little old awk, I just don't see the demand for it to be worth the effort and maintenance. These days people tend to use Python or Ruby or even <shudder> Perl to do stuff awk used to be used for.
Cheers Lex
As far as *.ii is concerned, I will wait until standards change or if Geany gains support for headers that may be C or C++ implicitly. (NOTE: For instance, *.h++ and *.hpp are explicitly C++ headers)
I will be sure to try to be more clear with my proposals.
-- Thanks, Devyn Collier Johnson DevynCJohnson@Gmail.com _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel