Geany Dev Team:
When viewing shell script code, some commonly used shell commands are not highlighted (such as "sudo"). True, numerous commands are not part of the core scripting language, but it seems to me that such commands should be highlighted.
Some additional examples of commands that I personally think should be highlighted include
- chmod - chown - echo - rm - mkdir - dpkg - apt-get - and many other core-utils and package-management commands
What do you all think about this? Are their any objections to me adding such commands to be highlighted? Is there a proper way to make non-standard/non-official shell commands get highlighted by Geany?
Does the [keywords] section of ./data/filetypes.* files support a "secondary=" category? If so, perhaps such commands could be listed in "secondary=".
On 4 November 2015 at 01:56, Devyn Collier Johnson devyncjohnson@gmail.com wrote:
Geany Dev Team:
When viewing shell script code, some commonly used shell commands are not highlighted (such as "sudo"). True, numerous commands are not part of the core scripting language, but it seems to me that such commands should be highlighted.
Some additional examples of commands that I personally think should be highlighted include
- chmod
- chown
- echo
- rm
- mkdir
- dpkg
- apt-get
- and many other core-utils and package-management commands
All these are programs, so where do we stop? What about "geany" ;) and the compilers and ...
So then users will have the reasonable right to complain that "my_obscure_executable" is not highlighted.
What do you all think about this? Are their any objections to me adding such commands to be highlighted? Is there a proper way to make non-standard/non-official shell commands get highlighted by Geany?
Does the [keywords] section of ./data/filetypes.* files support a "secondary=" category? If so, perhaps such commands could be listed in "secondary=".
The bash lexer only supports one keyword list.
The current words should be only shell built-ins not programs so highlighting them helps define the structure of your code. That will be lost if every executable is highlighted.
I do not think non-built-ins should be added to the sh filetype word list.
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 11/03/2015 04:51 PM, Lex Trotman wrote:
On 4 November 2015 at 01:56, Devyn Collier Johnson devyncjohnson@gmail.com wrote:
Geany Dev Team:
When viewing shell script code, some commonly used shell commands are not highlighted (such as "sudo"). True, numerous commands are not part of the core scripting language, but it seems to me that such commands should be highlighted.
Some additional examples of commands that I personally think should be highlighted include
- chmod
- chown
- echo
- rm
- mkdir
- dpkg
- apt-get
- and many other core-utils and package-management commands
All these are programs, so where do we stop? What about "geany" ;) and the compilers and ...
So then users will have the reasonable right to complain that "my_obscure_executable" is not highlighted.
What do you all think about this? Are their any objections to me adding such commands to be highlighted? Is there a proper way to make non-standard/non-official shell commands get highlighted by Geany?
Does the [keywords] section of ./data/filetypes.* files support a "secondary=" category? If so, perhaps such commands could be listed in "secondary=".
The bash lexer only supports one keyword list.
The current words should be only shell built-ins not programs so highlighting them helps define the structure of your code. That will be lost if every executable is highlighted.
I do not think non-built-ins should be added to the sh filetype word list.
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
Good point, Lex Trotman. I did not mean every executable, but only common ones (like the commands in GNU core-utils and mainstream package managers). However, after hearing your view-point, I definitely agree with you.
Thanks, Devyn Collier Johnson