Fortran storage modifiers do not appear with colours although they have set to this in the used TextMate theme and language grammar.
In my custom theme, I have set { name = 'Storage'; scope = 'storage, storage.type, storage.modifier'; settings = { fontStyle = 'bold'; foreground = '#003366'; }; which is clearly directing syntax colour for storage, storage type, and storage modifier.
In Fortran bundle, the grammar of Modern Fortran contains information of storage modifiers { name = 'storage.modifier.fortran.modern'; match = '\b(?i:(kind|len|optional|recursive|pointer|allocatable|target|private|public))\b'; },
Any idea how to get syntax colors for storage modifiers in a Fortran code? I have tried but did not get success.
Hi, I'm writing a bundle command that increments the build number of a project by modifying one of the project's files. When that file is the currently active one in TM then TM will detect the change and reload the file, but it will also set the changed status to true. This does not happen if the file is not the currently active one even if the file is opened in another tab, nor does it happen when the file is modified by a different process (ex: vi)
Is this the intended behavior?
Thanks, Gualo
Starting a new thread should not be done by replying to an existing letter and changing subject. It messes up threading for software that uses the in-reply-to email headers.
On 10 Aug 2014, at 8:30, Eduardo Francos wrote:
I'm writing a bundle command that increments the build number of a project by modifying one of the project's files. When that file is the currently active one in TM then TM will detect the change and reload the file, but it will also set the changed status to true. This does not happen if the file is not the currently active one even if the file is opened in another tab, nor does it happen when the file is modified by a different process (ex: vi)
Is this the intended behavior?
It does not sound like it, but I have seen it myself occasionally, where a file has no changes but is marked as modified. I think mostly when using Git → Revert for an open file.
The way TextMate tracks changes on disk is something I would like to rework. But if you have steps-to-reproduce with 100% certainty, please do share.
On 15 août 2014, at 12:39, Allan Odgaard mailinglist@textmate.org wrote:
Starting a new thread should not be done by replying to an existing letter and changing subject. It messes up threading for software that uses the in-reply-to email headers.
Sorry about that. I should have known better :p
On 10 Aug 2014, at 8:30, Eduardo Francos wrote:
I'm writing a bundle command that increments the build number of a project by modifying one of the project's files. When that file is the currently active one in TM then TM will detect the change and reload the file, but it will also set the changed status to true. This does not happen if the file is not the currently active one even if the file is opened in another tab, nor does it happen when the file is modified by a different process (ex: vi)
Is this the intended behavior?
It does not sound like it, but I have seen it myself occasionally, where a file has no changes but is marked as modified. I think mostly when using Git → Revert for an open file.
The way TextMate tracks changes on disk is something I would like to rework. But if you have steps-to-reproduce with 100% certainty, please do share.
As I said before the problem occurs only when the version file is modified by a command AND it's the currently active tab. Running the command when it isn't the active tab is OK, as it is when modifying the file with an external program.
I've included a simplified zipped "project" folder that contains: - A plain text "version.txt" file with the current version number - A dummy README.txt file so you can have another file to open - A simplified version of the "Increment Version.tmCommand" that increments the current version number in the ENV['TM_PROJECT_DIRECTORY']/version.txt file. (key: ^⌥⌘V)
Add the command to a TM bundle of your choice and open the folder as a project.
Test cases when executing the command: 1) The version.txt file is opened in TM but it's not the currently active tab: No problem, the file is reloaded and its status remains unmodified
2) The version.txt file is opened in TM and it is the currently active tab: The file is reloaded but is marked as modified... most of the time The bad news is that when repeatedly running the command at ~2 seconds interval I found that ~8 out of 10 times the version.txt file is reloaded with the new contents but its status is incorrectly set to modified, but for the other 2 it works as expected. This could mean there is a race condition type of problem between the execution of the command and whatever system you use to track file changes on disk. Probably not easy to debug :-(
Please let me know if I can be of any help.
On 17 Aug 2014, at 10:46, Eduardo Francos wrote:
As I said before the problem occurs only when the version file is modified by a command AND it's the currently active tab […]
Thanks for the test case, I have fixed the issue in 2.0-alpha.9563 (current nightly build).
That was fast! Thanks :)
On 2 sept. 2014, at 21:27, Allan Odgaard mailinglist@textmate.org wrote:
On 17 Aug 2014, at 10:46, Eduardo Francos wrote:
As I said before the problem occurs only when the version file is modified by a command AND it's the currently active tab […]
Thanks for the test case, I have fixed the issue in 2.0-alpha.9563 (current nightly build).
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 9 Aug 2014, at 18:54, riki wrote:
Fortran storage modifiers do not appear with colours although they have set to this in the used TextMate theme and language grammar. […]
Any idea how to get syntax colors for storage modifiers in a Fortran code? I have tried but did not get success.
You can press ⌃⇧P on a storage keyword to see its full scope.
First step would be to ensure that the keyword actually has the scope you expect. If it does, then it sounds like the problem can be isolated to your theme, in which case it would be good to have your entire theme, not just a subset, as other rules could affect the scopes.
Thanks a lot Allan Odgaard for your kind response.
Please find herewith my custom theme.
=====================================
{ settings = ( { settings = { foreground = '#000000'; background = '#FFFFFF'; caret = '#000000'; invisibles = '#999999'; selection = '#BAD6FD'; lineHighlight = '#00001A'; }; }, { name = 'String'; scope = 'string'; settings = { foreground = '#006600'; }; }, { name = 'Number'; scope = 'constant.numeric'; settings = { foreground = '#0033CC'; }; }, { name = 'Regular expression'; scope = 'string.regexp'; settings = { foreground = '#FF0080'; }; }, { name = 'Keyword'; scope = 'keyword'; settings = { fontStyle = 'bold'; foreground = '#006699'; }; }, { name = 'Identifier'; scope = 'constant.language'; settings = { fontStyle = 'bold'; foreground = '#9700CC'; }; }, { name = 'Exception'; scope = 'support.class.exception'; settings = { foreground = '#990000'; }; }, { name = 'Function name'; scope = 'entity.name.function'; settings = { fontStyle = 'bold'; foreground = '#990000'; }; }, { name = 'Type name'; scope = 'entity.name.type'; settings = { fontStyle = 'bold underline'; }; }, { name = 'Arguments'; scope = 'variable.parameter'; settings = { fontStyle = 'italic'; }; }, { name = 'Comment'; scope = 'comment'; settings = { fontStyle = 'italic'; foreground = '#009933'; }; }, { name = 'Invalid'; scope = 'invalid'; settings = { foreground = '#FFFFFF'; background = '#E71A11'; }; }, { name = 'Trailing whitespace'; scope = 'invalid.deprecated.trailing-whitespace'; settings = { background = '#E71A1100'; }; }, { name = 'Embedded source'; scope = 'text source, meta.embedded'; settings = { foreground = '#000000'; background = '#FAFAFA'; }; }, { name = 'Tag'; scope = 'meta.tag, declaration.tag'; settings = { foreground = '#0033CC'; }; }, { name = 'Constant'; scope = 'constant, support.constant'; settings = { fontStyle = 'bold'; foreground = '#6600FF'; }; }, { name = 'Support'; scope = 'support'; settings = { fontStyle = 'bold'; foreground = '#3333FF'; }; }, { name = 'Storage'; scope = 'storage, storage.type, storage.modifier'; settings = { fontStyle = 'bold'; foreground = '#003366'; }; }, { name = 'Section name'; scope = 'entity.name.section'; settings = { fontStyle = 'bold underline'; foreground = '#006699'; }; }, { name = 'Frame title'; scope = 'entity.name.function.frame'; settings = { fontStyle = 'bold'; foreground = '#000000'; }; }, { name = 'XML Declaration'; scope = 'meta.tag.preprocessor.xml'; settings = { foreground = '#333333'; }; }, { name = 'Tag Attribute'; scope = 'entity.other.attribute-name'; settings = { fontStyle = 'italic'; foreground = '#3366CC'; }; }, { name = 'Tag Name'; scope = 'entity.name.tag'; settings = { fontStyle = 'bold'; }; }, ); }
=====================================
On Fri, 15 Aug 2014 16:12:50 +0530 "Allan Odgaard" wrote
On 9 Aug 2014, at 18:54, riki wrote:
Fortran storage modifiers do not appear with colours although they
have set to this in the used TextMate theme and language
grammar. […]
Any idea how to get syntax colors for storage modifiers in a Fortran
code? I have tried but did not get success.
You can press ⌃⇧P on a storage keyword to see its full scope.
First step would be to ensure that the keyword actually has the scope
you expect. If it does, then it sounds like the problem can be isolated
to your theme, in which case it would be good to have your entire theme,
not just a subset, as other rules could affect the scopes.
_______________________________________________
textmate mailing list
textmate@lists.macromates.com