Custom Macro Best Practice Question (Web-mode & Emmet-mode related)

I'm currently learning both emacs and webdev. I'm trying to not go too far down the emacs configuration and customization rabbit hole out of the gate so that I can actually progress on the odin project. But its too intriguing to not build out some automation and QoL implementations. A recent fix I implemented showed me the power of being able to quickly customize built in or added package functionality to be what I want it to be. But it raised the question on best practices for doing such things. The example in question was navigating tags with web-mode and emmet-mode both enabled. There is some built in navigation for elements but I found one bit confusing/inefficent. ex: I use ul>li\*5 to make a list with 5 items in it. It smartly jumps between the first <li></li>. I enter some text and use "C-c C-e n" to move to the next element. But its at the start of the next element i.e. before the < in <li>. So I wrote a very quick and dirty macro in lisp and bound it to "C-x t". You can see that very crude and terrible implementation below. My core question here is whether such an implementation is better as a macro that calls the web-mode-element-next command and makes adjustments from there or is it better to just go in and make changes to web-mode-element-next and call it normally. Granted I'll utimately make a better solution that moves the point to the end of tag after > probably finding the character with regex or something. I just don't know lisp well enough yet. &#x200B; **My next-tag function - very crude just showing a code structure sample.** (defun next-tag() (interactive) (web-mode-element-next) (forward-char) (forward-char) (forward-char) (forward-char)) (global-set-key (kbd "C-x t") 'next-tag)

You might like `search-forward` - and of course `search-backward`.

To respond to your question. I don't think this makes sense as a macro. Think of it this way: * macro - code that returns **code**. * procedure - code that performs actions and optionally returns a **value** of some kind. I'm not being precise here, just trying to get the general idea across. Think of a procedure as a name for a set of valid instructions. When you write a call to the procedure, your program executes those instructions. It can take arguments to make it more flexible and general but it's basically a way manage more complex sets instructions. A macro looks like a procedure but it actually generates code as if you had written the code yourself. Your program later executes that generated code. As well as generating code, a macro can also take existing code as its argument and transform that code. Again your program will execute the generated and/or transformed code the same as if you had written in place of a macro call. It gets more complex because a macro can **also** execute code the same way a procedure does. In fact that's what makes macros so powerful and special, you can put complex logic and actions in a macro. That doesn't change the fact that the result of a macro call is code for your program to execute.