libera/#commonlisp - IRC Chatlog
Search
9:10:35
fiddlerwoaroof
The standard seems to restrict operations on vectors to reordering items, in both cases
9:12:04
jackdaniel
that said all depends on your definition of being "ruined" - sometimes you don't want to modify the original sequence order (in this case a vector)
9:12:21
jackdaniel
then calling sort on it may be undesired, because the original order will be ruined
9:28:06
pjb
(let ((list (list 5 4 3 1 2))) (list list (sort list #'<))) #| --> (#1=(5) (1 2 3 4 . #1#)) |#
15:52:07
gamaliel
Hi, I'm relatively new to Lisp, and was wondering if there was some way to wrap docstrings when documenting my functions. For now I am using (concatenate 'string "<doc-piece1>" ... "<doc-piece-n>") and it seems awfully clunky.
15:55:51
gamaliel
Sorry, I meant, it places the cursor directly on the first column of the code after the newline instead of respecting the indentation of the previous line.
15:56:40
gamaliel
So, if I start on the 8th space to write my docstring, placing newline moves the rest of the docstring to the 1st space.
15:58:05
semz
if you want to get rid of the linebreaks entirely for aesthetic reasons or want to indent your docstrings in the source without that showing up in the docstring itself, you could do #.(format nil "your docstring here~<newline> bottom text"), which results in "your docstring herebottom text".
15:58:27
semz
~<newline> is a format command that ignores the newline and all whitespace at the beginning of the next line
16:04:02
gamaliel
Ok, so to be clear, for writing a docstring I'd wrap it around #.(format nil "<my-docstring-text-piece1>~<newline><my-doc-string-text-piece2>") and add enters, spaces, etc. for manually indenting. Format would then take care of eliminating all extra space.
16:05:41
_death
gamaliel: the indentation makes sense, because the text starts after the first double quote
16:05:41
edgar-rft
gamalie: If you start the doctring on the 8th space in your code and also indent all following lines in the docstring by 8 spaces, then when the docstring gets printed the first line will start at line position 0 (because the docstring starts with the double quotes) and all subsequent lines will be printed with an indentation of 8 spaces. This is probably not what you want.
16:07:34
semz
gamaliel: Pretty much, although keep in mind that ~<newline> by itself won't add a space between the concatenated pieces (you'd have to put one before the ~<newline>). You can test this without the #. in the REPL, it's just a format call after all
16:08:06
semz
actually I suppose you can test it with the #. in the REPL as well, it makes no difference
16:10:02
beach
gamaliel: Here is what we do: https://github.com/robert-strandh/SICL/blob/master/Code/Conditions/Portable-condition-system/docstrings-english-conditions.lisp
16:11:23
beach
gamaliel: The ~@<newline> FORMAT directive means that initial space on the next line is ignored, so the lines of the documentation string are aligned in the left column even though the lines in the code are indented.
16:53:38
fiddlerwoaroof
I recently used a function to trim leading whitespace up to a sentinel character in docstrings
19:05:42
pjb
gamaliel: when I type ( d e f u n SPC foo SPC ( ) RET " h e l l o RET I get: https://termbin.com/g2aju with | being the cursor.
19:06:12
pjb
gamaliel: If typing RET on the closing " gets you out of the string, then you could use instead C-q C-j to insert a newline.