Some commentary on the code in LINE_DIV.lsp, just because some things caught my attention:
This part:
(cond ((or (minusp spaces1) (< spaces1 1)) "Spaces should be greater than 1")
allows 1 itself, which is meaningless, and since negative numbers are always less than any positive-number cut-off, it's testing for more things than it needs to. Also, it spells out a message that it does not convey to the User in any way. It should be something like:
(cond ((< spaces1 2) (prompt "Spaces should be greater than 1"))
This line:
(setvar 'osmode 16384)
is viable but curious -- most routines set it to 0. At 16384, Osnap is off and no modes are operative, which is redundant. At 0, Osnap is "on" but no modes are operative, so it's effectively off anyway.
This part:
(initget "Yes No")
(setq f (cond ((getkword "\nFLip lines [Yes/No] <No>: "))
("No")))
(cond ((wcmatch f "Yes,Y")
shows a misunderstanding of how (initget)/(getkword) work. If the User types an acceptable option, the (getkword) function returns the word from (initget) exactly as it is written there, whether the User types just the capitalized letter(s), in either upper or lower case, or more of the word. So the f variable can contain only either "Yes" [whether the User typed Y or y or Ye or yE or yeS or YEs or ....], or "No" [whether they typed N or n or nO or No or NO or no], or nil if they hit Enter, and if they type anything not conforming to the options, it will ask again. It will never contain "Y". So the last line there can be just:
(cond ((= f "Yes")
This line:
(T ())))))
shows a misunderstanding of how (cond) works. To create a "fallback" condition [the T] that does nothing is exactly the same as not creating that fallback condition at all. If none of the conditions before this are satisfied, it will do nothing anyway, without being "told" to do nothing. That line can be just:
))))
Kent Cooper, AIA