[Geany-Devel] DevynCJohnson's Ideas (November)

Devyn Collier Johnson devyncjohnson at xxxxx
Tue Nov 10 15:26:51 UTC 2015

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 at Gmail.com
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.geany.org
>> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel at 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.

Devyn Collier Johnson
DevynCJohnson at Gmail.com

More information about the Devel mailing list