Skip to content

emacstbl.pl: Add proper header and footer #107

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

8dcc
Copy link

@8dcc 8dcc commented Mar 20, 2025

Changes the header and footer of the nasmtok.el file generated by emacstbl.pl. This change is needed for closing skeeto/nasm-mode#14, currently being tested in a require-nasmtok (skeeto/nasm-mode@826f881) branch.

For more information about the library header convention in Elisp, see: https://www.gnu.org/software/emacs/manual/html_node/elisp/Library-Headers.html

@8dcc
Copy link
Author

8dcc commented Mar 20, 2025

I also noticed that some preprocessor tokens such as struc, endstruc, istruc, iend and at are not included in the generated nasmtok.el file.

By looking at the following lines, I can see that some other tokens from the nasm-pp-directives list might be missing as well, such as align and alignb: https://github.com/skeeto/nasm-mode/blob/4e670f6dededab858251670aa5459c950f78d867/nasm-mode.el#L528-L534

Please, review this and add them if possible.

@hpax
Copy link
Member

hpax commented May 17, 2025

Ah, makes sense, because align/alignb are actually implemented as macros. It should be possible to pick them up from the macro definitions.

@hpax
Copy link
Member

hpax commented May 17, 2025

Hi,

I will be adding your headers and footers tomorrow, but in the meantime I wanted to hear if dumping predefined macros in this format will be adequate for your needs? (I have filtered out the namespace ?...? which is permanently reserved for NASM symbols, but I can put it back if you wish.)
nasmtok.el.txt

@8dcc
Copy link
Author

8dcc commented May 18, 2025

Hello, I am glad to hear from you!

I wanted to hear if dumping predefined macros in this format will be adequate
for your needs?

I don't see anything wrong from a technical point of view, except that you seem
to have missed the outer list of the definitions (you were calling defconst
with multiple arguments, instead of a list with multiple elements):

--- nasmtok.el.txt  2025-05-18 14:37:12.446063844 +0200
+++ nasmtok.el2.txt 2025-05-18 14:49:02.550699323 +0200
@@ -500,7 +500,7 @@
   "NASM 2.16.03 special tokens for `nasm-mode'.")

 (defconst nasm-out-macros
-  '(("bin")
+  '((("bin")
     ('imacro "org"))
    (("coff" "win32" "win64")
     ('imacro "export" "safeseh"))
@@ -512,11 +512,11 @@
    (("macho" "macho32" "macho64")
     ('imacro "no_dead_strip" "subsections_via_symbols"))
    (("obj")
-    ('imacro "export" "group" "import" "uppercase"))
+    ('imacro "export" "group" "import" "uppercase")))
   "NASM 2.16.03 out macros for `nasm-mode'.")

 (defconst nasm-std-macros
-  '(("nasm")
+  '((("nasm")
     ('defalias "__BITS__" "__DATE_NUM__" "__DATE__" "__DEBUG_FORMAT__"
      "__FILE__" "__FLOAT_DAZ__" "__FLOAT_ROUND__" "__FLOAT__"
      "__LINE__" "__NASM_MAJOR__" "__NASM_MINOR__" "__NASM_PATCHLEVEL__"
@@ -537,11 +537,11 @@
      "struc" "use16" "use32" "use64" "useabs" "usebnd" "usenobnd"
      "userel"))
    (("tasm")
-    ('idefine "end" "ideal" "jumps" "p386" "p486" "p586"))
+    ('idefine "end" "ideal" "jumps" "p386" "p486" "p586")))
   "NASM 2.16.03 std macros for `nasm-mode'.")

 (defconst nasm-use-macros
-  '(("altreg")
+  '((("altreg")
     ('idefine "r0" "r0b" "r0d" "r0h" "r0l" "r0w" "r1" "r10l" "r11l"
      "r12l" "r13l" "r14l" "r15l" "r1b" "r1d" "r1h" "r1l" "r1w" "r2"
      "r2b" "r2d" "r2h" "r2l" "r2w" "r3" "r3b" "r3d" "r3h" "r3l" "r3w"
@@ -560,5 +560,5 @@
     ('imacro "end" "endp" "ends" "proc" "segment"))
    (("smartalign")
     ('defalias "__ALIGNMODE__")
-    ('imacro "align" "alignmode"))
+    ('imacro "align" "alignmode")))
   "NASM 2.16.03 use macros for `nasm-mode'.")

Keep in mind that I updated the indentation of the lists accordingly, but that
should not matter too much in the exported file.

Could you please explain why this sort of "alist-style structure" is needed? I
assume it's because some macros are only defined depending on some context
(e.g. the architecture or output format), but I am not sure.

Furthermore, if you could document this in the docstrings of the .el file
itself, I would appreciate it. For example, following the documentation format
of the c-style-alist Emacs variable:

(defconst nasm-out-macros
  ;; ...
  "NASM 2.16.03 out macros for `nasm-mode'.

Each element in this list has the form:

  (FORMAT-LIST DEFINITION-LIST ...)

where FORMAT-LIST is a list of [...] strings, and each DEFINITION-LIST has the
format:

  (TYPE SYMBOL...)

where TYPE is a symbol representing [...], and each SYMBOL is a string with the
name of the macro.")

This is just an example, I would just like to understand the format, and leave
it reflected in the exported file as well.

I have filtered out the namespace ?...? which is permanently reserved for
NASM symbols, but I can put it back if you wish.

That's fine, thank you for mentioning it.

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

Successfully merging this pull request may close these issues.

2 participants