Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ARM assembly syntax file using .s file extension conflicts with asm.yaml #1559

Open
phpeterson-usf opened this issue Mar 6, 2020 · 6 comments

Comments

@phpeterson-usf
Copy link

phpeterson-usf commented Mar 6, 2020

Description of the problem or steps to reproduce

I would like to use micro for a project in ARM assembly language, and could contribute a syntax file for that instruction set. However, our source files use the extension .s, which is already used by the built-in syntax file for x86 assembly language. I looked at the detect/header syntax in YAML, but the Go code in ftdetect.go prefers the file extension to the firstLine header. I can see two cumbersome ways to make this work:

  1. Make up a bogus file extension like .as for ARM assembly language
  2. Type set filetype armasm every time I open a file this doesn't work

Is there a better way? If not, can we make something up, like maybe allowing the firstLine header to take priority over the file extension?

Specifications

Version: 2.0.2
Commit hash: c51f849
Compiled on February 26, 2020

@sparques
Copy link

sparques commented Mar 7, 2020

If you take a look at the ftoptions plugin, you can use that as a template to write your own plugin that detects your filetype and changes the filetype option.

I think something like, if ft == "asm" then if {custom detect code} {filetype = armasm}

@sparques
Copy link

sparques commented Mar 7, 2020

Okay, I went ahead and wrote this for you.

function onBufferOpen(b)
    local ft = b:FileType()

    if ft == "asm" then
    	if string.find(b:Line(0), "armasm") then
    		b:SetOption("filetype","armasm")
    	end
    end
end

Not sure what your arm asm file looks like. If you add a comment to to the top of your file, containing the string "armasm" this will detect it. Or you can figure out something else.

You need a separate syntax file defining armasm syntax, of course.

To use this, mkdir -p ~/.config/micro/plug/armhelper
Store the function in ~/.config/micro/plug/armhelper/armhelp.lua

@phpeterson-usf
Copy link
Author

Thanks. I thought I would make it more readable by making the filetype arm-asm, and naming the plugin to match. However, my plugin never got called. It appears that this line of code does not permit dashes in the filenames of runtime files :-)

Now the filetype switch (to arm_asm) works, but that seems to break syntax highlighting. I will file a separate issue on that.

@phpeterson-usf
Copy link
Author

phpeterson-usf commented Mar 8, 2020

I would really like to see something like this in a comment in the source file:
/* micro:set filetype arm_asm */
as vim does
Want to repurpose this issue? Or close and open a new one?

FWIW, I wonder if micro already has contention for file extensions with C++. runtime/syntax/ contains two syntax files for C++ (cpp.yaml and c++.yaml), both claiming .cpp files. Is there a way to apply one or the other? Or first one encountered wins?

@zyedidia
Copy link
Owner

zyedidia commented Mar 8, 2020

By the way, it should be possible to achieve a similar effect to the plugin by adding the following to your settings.json:

{
...
    "*.s": {
        "filetype": "arm_asm"
    }
...
}

@phpeterson-usf
Copy link
Author

Does that approach lock users into a one-to-one relationship between file extensions and syntax files? I'm looking for an approach which allows file extensions to have a one-to-many relationship with syntax files. That's certainly the real-world scenario for .s files files representing completely different architectures.

I also imagine one-to-many would be useful for other languages as they evolve, gaining new syntax or deprecating old syntax. For example, one-to-many would allow Micro to edit python3 files with a .py extension, which might be nice too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants