It's great but I can not change the style of text, mtext become block.

thanks.

The function is very efficient, I thought it was going to change all types of blocks.
But I can only select blocks of text as an attribute.
Text blocks and dynamic blocks are not modified.
How I can change the routine so you can select them?

Thank you.

Typing this on my phone so I apologize for being brief.

In some languages you break a program into several files -i.e. You'd put all your "support functions" into other files other then the main programming logic (where you keep the meat of your program). This keeps your main program very clean -i.e. You don't have to worry yourself about the "unimportant (tried and true)" when reading/writing and maintaining your program. I wrote a utility to replicate this method for the lisp language. The utility is mostly in an "unmaintained" status now but I cannot imagine any new features that would ever need be added to it so it should be very useful as it is.

https://www.theswamp.org/index.php?topic=37700.0

At the risk of repeating advice given  ....

You'll probably spend 10 times as long reading code as you will writing it, so make sure it's readable FOR YOU.

Functionally it doesn't matter a rats tail. Aesthetically it will matter to YOU. ( or it should )

At this stage you should have read enough code to know what you like the look of and know what is easy to read .. use that experience.

My recommendation is to use one of the formatting styles available in the VLIDE.
If you post code that has an unusual, unique set-out style chances are I'll ignore it (as in not bother to read it) or re-format it in the IDE I'm using.

If you stay with programming you'll get more benefit from breaking your code down into smaller individual functions and using suitable function and variable names than you will by worrying about formatting.

Something that is important to me is to ensure that the reader gets a chance to take a breath when reading my code.

Regards,

Hi Grrr, I'll just say what I think so don't consider it as must... I tend to use just 2 spaces when structuring loops and blocks of codes... I use Notepad ++ for quickly move blocks from left margin (edge) of code using setting of 2 spaces as TAB formatting... I don't see why Lee Mac uses 4 spaces and in your example there is also plenty of room, so it's just personal structuring habit... Although it's not necessity like irneb stated it's quicker to close brackets in the same line of paragraph, but I don't like it much - then I don't see code elegant structured in blocks and I tend to avoid such situations... Notepad ++ have also ability to mark open bracket with closing one so it's easy to see where the problem may occur... Also when checking for parentheses it's nice to use sometimes VLIDE editor and mark blocks of code from end up to beginning of code... Then you can bump into unbalanced matching of brackets more reliably... But beside nice look of coding that's not the most important thing when coding bigger lisps... The most important thing is that the routine works as expected... There are quite lot of thing that may happen when debugging : typo mistakes, evaluation of variable as nil which will produce error in next coded syntax, sometime it's good to step from parametric programming - I mean using formulas to numerical coding, and sometimes it's totally opposite you need to convert hard coded numbers into parametric formulas... For me it's the hardest bug to find where was wrong evaluation when last break point is inside sub function, so you can't step backwards to see when sub function was called ( was it early or somewhere in the middle of code or the problem appeared near end of routine )... For this you have to have intuition and experience to have correct assumption and to find where the problem was... Almost all codes that have considerable length won't work from first testing attempt... So the most important thing is that when you coded much to be concentrate and patient - not to give up and leave bug to be unsolved... You have to be very persistent in debugging and like others stated it's important to know where to put break points while checking problematic portion of code... Animation option is useful too, but more important is to be sure what routine is doing from beginning to the end and to spot where such problematic portion of code was written to correctly set break point before it, then use inspect tool and watch window with all necessary variables filled in window and analyze what returns are... Sometime the problem is in sub function that is correct but for different routine and in your new routine it needed to be modified to suit different algorithm processing... And so much more can be discussed on it, but like MP stated and I agree 100% with it when it works, it works and beauty of coding may be or not pretty to someone or not, but functionality isn't questionable when it works as it should...