\n revisited

[john.uhden]

I didn't realize until today that (getstring) will replace single backslashes ("\") with doubles ("\\").

So here I am with my c:ADDSUFF routine trying to add block numbers below existing lot numbers as new-lines in a bundle of mtexts.

(setq suffix (getstring T "\nEnter suffix: "))

So I type in (without quotes) "\nBlock 130"

and I get back "\\nBlock 130"

which when strcating creates "Lot 26\nBlock 130" as one line.

The solution is...

(setq suffix (vl-string-subst "\n" "\\n" suffix))

before the strcat.

Now the vl-string-subst function works on only the first occurrence it finds, so if you have multiple "\n" new-lines to add you might want to use this oldie from when I was still just older-middle-aged...

;;------------------------------------------------
;; Function added 12-01-00 (not used anywhere yet)
(defun @strsubst_all (new old what / l n)
   (setq l (strlen new) n 0)
   (while (setq n (vl-string-search old what n))
      (setq what (vl-string-subst new old what n)
            n (+ n l)
      )
   )
   what
)

[Kent1Cooper]

\n is the newline code for AutoLisp prompts, but not what you get when you use Enter in mid-Mtext content.  In entity data:

In the text-contents slot in Properties, it shows with only the single backslash:

[john.uhden]

@Kent1Cooper
We've been through this before.
\n is also a soft return in MTEXT and in the alert function as well. Try
it yourself...
(alert "abc\n123\nDEF").
Also try (vlax-put object 'textstring "abc\n123\nDEF") on a Mtext
vla-object.
It works just like Shift+Enter in MS Word... it creates a line feed without
creating a new paragraph, which is handy when you have numbered paragraphs
or want to maintain line spacing different from paragraph spacing.
Just because the Properties dialogue doesn't show it, it doesn't mean it's
not there. But you will see it in the entity list (dxf 1).

The only issue I was trying to point out is that getstring is trying to
help thinking you would use a backslash only for typing in a file path, so
it adds a second backslash as is the AutoCAD standard for file path
delimiters. But I don't want a double backslash. I just want a new line.

[martti.halminen · Accepted solution]

(getstring) is actually working correctly according to normal Lisp escape-character rules. As a backslash is an escape character in lisp strings, removing any special properties from the next character but not getting included in the string itself (just in the printed representation of it), anything reading in characters to include in a string needs to escape a backslash with another, if you want get that included. 

_$ (strlen "\\n")
2
_$ (ascii "n")
110
_$ (strlen "\\")
1
_$ (ascii "\\")
92
_$ (strlen "\\n")
2
_$ (vl-string->list "\\n")
(92 110)

The problem here is that according to these rules "\n" should behave exactly like "n".

In any other lisp implementation I have seen that is true, but AutoLISP user interface behaves differently:

_$ (vl-string->list "\n")
(10)

In Common Lisp that would be:

CL-USER 18 > (map 'list #'char-code "\n")
(110)

 n doesn't have any special behaviour, so the result is the same without the escape character:

CL-USER 20 > (map 'list #'char-code "n")
(110)

So, what is happening that AutoLISP, when seeing "\n", immediately converts it to a Newline character instead of letting the next user of the string do that when intended. This breaks the normal Lisp print-read consistency - not the only place where AutoLISP does that.

[john.uhden · Accepted solution]

@Anonymous

(setq x (chr 10))
"\n"
Thank you for agreeing that it is a Newline character.
And, yes, it can be used in Mtext and the alert function.