ObjAsm vs unix filenames

Another thing I’m battling and not found any posts about…

I’m using ObjAsm via an obey file and I’m hitting an issue in my workflow.

I use sublime text on macOS and I have a network setup and I perform builds on RISCOS, it all works nicely….ish!

The problem I am facing is that to get the correct syntax highlighting in sublime I have to use .asm extension, well any extension, the issue is that I have to have an extension as it’s the only way sublime recognises files.

These extensions show as /asm in RISCOS and that is an issue because ObjAsm seems to automatically decide to convert them to RISCOS directory separators, “.” Which has the effect of making it impossible to pass in the file name to ObjAsm, it then tries to include the assembly file in a non existent folder.

I am temporarily working around this using wildcards which is enough to stop ObjAsm from doing a string replacement but it’s not scalable and I have to be careful with filenames as not to clash.

Is there any way of stopping it doing this?

The problem I am facing is that to get the correct syntax highlighting in sublime I have to use .asm extension, well any extension, the issue is that I have to have an extension as it’s the only way sublime recognises files.

Not 100% sure if I understand your workflow, however, on the template repository on the RISC OS Community on GitHub, I added a script that creates symlinks correctly for IDEs on Windows/macOS/Linux and also for Code testing tools (like SAST, DAST etc.), you can have a look.

https://github.com/RISC-OS-Community/StandardRepoTemplate

Also, just as a side note, many modern graphic editors have started to use .gitattributes to color-higlight sources, adn Sublime (at least from release 4.0 IIRC) should be no exception. I don’t use Sublime, so I may remember wrong.

In any case, you can find the right .gitattributes for C, C++, Forth, Asm on the same repository.

On RISC OS Community on GitHub we now support also GitHub Actions automation for RISC OS code and that include also security tests for C/C++/Python etc. which is very handy.

If ObjAsm needs more help, I’ll be happy to improve support for it :)

HTH

Thanks, I will take a look, but it’s a longstanding issue with Sublime that people hit, there’s been a open issue about it for many years, but it’s possible that .gitattributes may be supported and offer a workaround, I will take a look and report back.

My workflow is based on me having my source directory mapped via either host-fs (if building on rpcemu) or via lanman98, essentially I write everything in macOS and flip to riscos to perform the actual build (in the case of rpcemu I simply switch to the app, for network I use VNC to my riscpc).

I do this for a couple of reasons, firstly it’s much easier to write in sublime than it is in stronged, I use sublime day in day out and it’s an application that I really love.

The second reason is that I have to run various tools on the built software, these tools I run on macOS and I have this set to auto run when the output file changes on macOS, so as soon as I just ObjAsm on riscos, my tool auto runs on macOS and I get the information I need instantly.

I’m literally just using riscos for the build.

These extensions show as /asm in RISCOS and that is an issue because ObjAsm seems to automatically decide to convert them to RISCOS directory separators, “.” Which has the effect of making it impossible to pass in the file name to ObjAsm, it then tries to include the assembly file in a non existent folder.

You could employ the trick that’s used when ROOL’s GitLab is building stuff, by creating symlinks from ./s/MySource to ./MySource.asm or vice versa so both parties are happy.

Since you’re on Mac OS, which is kind of FreeBSD, I assume HostFS would follow the links inside rpcemu, and similarly if it’s exporting the disc via Samba the physical Risc PC would see the symlinked arrangement too. I don’t have a Mac, but I’ve seen symlinks used this way on Samba shares with Windows OK.

The problem I am facing is that to get the correct syntax highlighting in sublime I have to use .asm extension, well any extension, the issue is that I have to have an extension as it’s the only way sublime recognises files.

No… that’s not the only way. Using the `ApplySyntax` package, you can configure the rules for what syntaxes will be used for the files, by filename, extension or interpreter. You can use this package by installing Package Control (which I assume you already have to get the ARM assembly syntax mode but if you don’t…), and installing the Package with Cmd-P → `Package Control: Install Package` → `ApplySyntax`.

Once installed you can configure the package. From the menu, select Sublime Text → Preferences → Package Settings → ApplySyntax → Settings. You can then give the configuration for the various RISC OS files.

My configuration file in ApplySyntax.sublime-settings looks like this:

{
    // If you want exceptions reraised so you can see them in the console, change this to true.
    "reraise_exceptions": false,

    // If you want to have a syntax applied when new files are created, set new_file_syntax to the name of the syntax
    // to use.  The format is exactly the same as "syntax" in the rules below. For example, if you want to have a new
    // file use JavaScript syntax, set new_file_syntax to 'JavaScript'.
    "new_file_syntax": false,

    // Auto add extensions to language settings file in User folder.
    // Do not manually remove "apply_syntax_extensions" from the settings file.
    // "extenstions" are ignored by "match": "all" setting.
    "add_exts_to_lang_settings": true,

    // Control level of logging in the console.
    // (true|false|"verbose")
    "debug": "verbose",

    // Put your custom syntax rules here:
    "default_syntaxes": [
        {
            // Supports RISC OS naming conventions.
            "syntax": "ARM Assembly/Syntaxes/ARM Assembly",
            "extensions": ["arm"],
            "rules": [
                {"file_path": ".*(\\\\|/)(s|s_c|hdr)(\\\\|/)[^\\\/]+$"},
            ]
        },

        {
            // Supports RISC OS naming conventions.
            "syntax": "C Improved/C Improved",
            "extensions": ["c"],
            "rules": [
                {"file_path": ".*(\\\\|/)(c|h)(\\\\|/)[^\\\/]+$"},
            ]
        },

        {
            // Supports RISC OS naming conventions.
            "syntax": "C++/C++",
            "extensions": ["c++"],
            "rules": [
                {"file_path": ".*(\\\\|/)(c\\+\\+|h\\+\\+)(\\\\|/)[^\\\/]+$"},
            ]
        },

        {
            // Supports RISC OS naming conventions.
            "syntax": "Makefile/Makefile",
            "rules": [
                {"file_path": ".*(\\\\|/)*,fe1$"},
            ]
        },

        {
            // RISCOS Specific commands file (Obey, TaskObey, Command, TaskExec, Desktop)
            "syntax": "RISCOSCommand/RISCOSCommand",
            "rules": [
                {"file_path": ".*(\\\\|/)*,(ffe|feb|fd7|fd6|fea)$"},
            ]
        },

        {
            // Supports RISC OS naming conventions.
            "syntax": "BBCBASIC/BBCBASIC",
            "rules": [
                {"file_path": ".*(,fd1|\\.bbc)$"},
            ]
        },

        {
            // CMHG files (Generic Config is good enough)
            "syntax": "RISCOSCMHG/RISCOSCMHG",
            "rules": [
                {"file_path": ".*(\\\\|/)cmhg(\\\\|/)[^./]+$"},
            ]
        },

        {
            "syntax": "Python Improved/PythonImproved",
            "extensions": ["py"],
            "rules": [
                {"interpreter": "python"}
            ]
        },

        {
            "syntax": "Markdown Extended/Syntaxes/Markdown Extended",
            "extensions": ["md"],
        },

        {
            "syntax": "RestructuredText Improved/reStructuredText Improved",
            "extensions": ["rst"],
        },

        {
            "syntax": "Ansible/Ansible",
            "rules": [
                {"file_path": ".*/(tasks|handler)/.*\\.ya?ml$"},
                {"file_path": ".*/roles/[^/]+/(tasks|handler)/.*\\.ya?ml$"},
                {"file_path": ".*/playbooks/.*\\.ya?ml$"},
                {"file_path": ".*/.*ansible(/(?!meta|vars)[^/]*)*/[^/]+\\.ya?ml$"}
            ]
        },

        {
            // Supports YAML magic string at start of file.
            "syntax": "YAML/YAML",
            "extensions": [".gemrc", "yml.dist", "YAML-tmLanguage"],
            "rules": [
                {"file_path": ".*\\.yml$"},
                {"first_line": "^%YAML"}
            ]
        },

        {
            // Supports my test.pl format
            // matches tests|testcode|testdata a file called tests.txt or tests-*.txt
            "syntax": "Generic Config/GenericConfig",
            "rules": [
                {"file_path": ".*(\\\\|/)test(s|code|data)?(\\\\|/)(tests-.*|tests)\\.txt$"},
            ]
        },

        {
            // Nanorc configuration files
            "syntax": "Nano RC Syntax/nanorc",
            "extensions": [".nanorc"],
        },

        {
            // HSC content is HTML
            "syntax": "HTML/HTML",
            "extensions": ["hsc"],
        },

        {
            // I use 't' and 'x' as log files
            "syntax": "Text/Plain text",
            "rules": [
                {"file_path": ".*/[tx]$"},
            ]
        },

        {
            // Dockerfile
            "syntax": "Theme - SoDaReloaded/settings/langs/DockerFile",
            "extensions": ["Dockerfile"],
        }
    ]
}

There are some entries in there that are not relevant to RISC OS, but the bulk of the file directly addresses RISC OS typing issues.

I use SublimeText every day for working with RISC OS source files – hence why I’ve created the SublimeText syntax packages for some – together with RISC OS under RISC OS Pyromaniac (and under Docker for testing the Linux support, or under CrossOver for testing the Windows support), in RPCEmu natively on macOS, in RPCEmu through Docker (for testing some networking things that are easier). So if you have any other questions about using it with RISC OS, please feel free to ask.

Amazing! Thank you, this has indeed resolved the problem :)