On Sun, Aug 16, 2020 at 7:41 AM Lars Ingebrigtsen <
larsi@gnus.org> wrote:
Eric Ludlam <ericludlam@gmail.com> writes:
> You can use:
> M-x srecode-get-maps RET
>
> to list all the templates discovered during srecode initialization on
> the different platforms to see what is different.
Thanks. Unfortunately, the number of maps on the Debian machine (where
this works) and the Macos machine (where it doesn't) is identical, and
they both list the test srt files:
-- Application Maps --
tests :
Mode Filename
------ ------------------
srecode-template-mode /Users/larsi/src/emacs/trunk/etc/srecode/test.srt
srecode-template-mode /Users/larsi/src/emacs/trunk/etc/srecode/proj-test.srt
Hm... are those really supposed to have the same mode name? Isn't the
mode name used as an accessor in a hash table somewhere? Could that
explain the differences?
Yes, there will be multiple template files for the same mode. This is one of the cool things about srecode, which was designed for code generation. Each template file has its own priority, and lots of templates for the same mode can be loaded in. For any given context, only templates prioritized for that given file are used.
For example, default.srt has a 'copyright' template for inserting a copyright, and a 'filecomment' template that uses it. Any given mode file might choose to override 'filecomment' but keep using the default 'copyright' template. A particular application that generates code might have a default app template that embed filecomment in itself. Thus, an app FOO might have a FOO_init_file (generic) that uses filecomment (mode specific), that uses copyright (generic).
A user might not like how copyright is represented for C++. They could then create their own c++ template in a project specific location (via ede) or in their home directory. In c++, when using the FOO srecode app, that app will now generate a preferred copyright statement which would match the generic `filecomment' insert.
As you can imagine, you can have any number of templates specialized for a mode or app. This lets us provide ways to generate basic code in core templates, and apps can then generate code specific to what they need re-using the base templates, while also allowing users to customize the core templates as needed.
Hopefully that all makes sense. It's sort of like css for code generation. I just never got around to building that ultimate code gen tool I was dreaming about.
When I was building srecode & semantic, I had to develop my own debugging tools to inspect the complex data structures. I pulled the latest emacs from master to see if they still work. Here are some steps for the extra debugging tools I use:
;; In your .emacs
(require 'data-debug)
(require 'eieio-datadebug)
(load-file "~/cedet/cedet-git/lisp/cedet/semantic/adebug.el") ;; Need to port this to Emacs from CEDET on sourceforge
;; For srecode debugging, you don't need that last line.
(global-set-key "\M-:" 'data-debug-eval-_expression_) ;; Replace typical eval _expression_ for extra debug tooling
I then noticed that the latest version of EIEIO bypassed a key part of data-debug-eval-_expression_. Here's a patch:
diff --git a/lisp/cedet/data-debug.el b/lisp/cedet/data-debug.el
index 604fc40926..11749c5da0 100644
--- a/lisp/cedet/data-debug.el
+++ b/lisp/cedet/data-debug.el
@@ -1063,7 +1063,7 @@ data-debug-eval-_expression_
(unless (eq old-value new-value)
(setq debug-on-error new-value))))
- (if (or (consp (car values)) (vectorp (car values)))
+ (if (or (consp (car values)) (vectorp (car values)) (object-p (car values)))
(let ((v (car values)))
(data-debug-show-stuff v "_expression_"))
;; Old style
I then created /tmp/foo.srt (a template file in /tmp). It looks like this:
;;; My template file for testing.
;; 1 (setq srecode-mode-table-list nil)
;; 2 (call-interactively 'srecode-get-maps)
;; 3 (srecode-load-tables-for-mode major-mode)
;; 4 (srecode-table major-mode)
;; 5 (setq temp (srecode-template-get-table (srecode-table) "test-project" "test" 'tests ))
;; 6 (srecode-load-tables-for-mode major-mode 'tests)
Each line is just a snippet from srecode-test-template.el.
C-x-C-e on line labled 1 to completely flush all data loaded into SRECODE.
M-: (srecode-table) RET
should show nil.
The second line should show the map list of all the various templates which you used before.
The third line will load in tables for srecode-template-mode.
should now show an _expression_ debug of the data structure with that looks like this:
?#<srecode-mode-table srecode-mode-table-158f6d5cd470>
] Name: "srecode-mode-table-158f6d5cd470"
] Class: #'srecode-mode-table
] :major-mode #'srecode-template-mode
] :modetables #<list o' stuff: 1 entries>
] :tables #<list o' stuff: 1 entries>
The last 2 lines should have 1 entry in them.
You can skip line 4 which verifies the above.
LIne 5 should show nil (ie - no app templates loaded.)
Line 6 will load in application specific templates.
This is testing a feature of srecode loading. You can have lots of app specific templates and not slow down basic template loading until they are needed. (ie - the app will load it's own templates)
should now show:
?#<srecode-mode-table srecode-mode-table-158f6cf8352c>
] Name: "srecode-mode-table-158f6cf8352c"
] Class: #'srecode-mode-table
] :major-mode #'srecode-template-mode
] :modetables #<list o' stuff: 3 entries>
] :tables #<list o' stuff: 3 entries>
with 3 tables loaded. In the debug _expression_ buffer you can also press SPC to open up a given line that is itself a list or object.
My assumption is you won't get 3 items in the output above on MAC and will need to edebug `srecode-load-tables-for-mode'.
There is also a command `data-debug-edebug-expr' you can bind to some key in edebug. I used to have it on E, but that seems to be something else these days.
The important bit is what files are listed (start of srecode-load-tables-for-mode) which should include the 2 app files, and later in the same function if any of those files fail to load.
As you may have guessed, the sequence is working for me on my Ubuntu box. I also hope you like the data-debug feature. Normally the basics in Emacs are fine, but for complex data structures, being able to walk through an instance of a variable is critical for understanding how some of the code might be misbehaving if you're not sure which part of the data structure to look at.
Hope this helps
Eric