* Shinmera
can't wait to do (v:output-here (swank:make-editor-stream))
<Shinmera>
trace output would also be nice to have in extra buffers
<Shinmera>
though would probably be better named swank:make-buffer-stream or something.
<scymtym>
the other way around would also be cool: (read-line (swank:make-buffer-input-stream "buffer name"))
<Shinmera>
ideally the stream would be bidirectional of course :)
<scymtym>
for testing parsers and such
<Shinmera>
ah, yea
<scymtym>
it could even move point/mark around to indicate FILE-POSITION
_whitelogger has joined #slime
aerique has quit [Ping timeout: 268 seconds]
<luis>
Shinmera: make-buffer-stream was my first idea, but I was trying to be editor agnostic somehow.
<luis>
fiddlerwoaroof: some great ideas for your pet feature here :-)
<luis>
scymtym: so, read-line would move the point, right?
<scymtym>
luis: probably as an optional behavior, but yeah
<luis>
scymtym: the alternative would be to copy the buffer contents at stream creation time, right?
<luis>
I guess it'd be best to mark the file-position with an auxiliary pointer (or some other visual way) instead of the normal pointer, otherwise it'd too easy to mess with the file-position by accident.
<scymtym>
true. i haven't thought about it too much
<luis>
scymtym: in any case, it's a great idea.
<Shinmera>
luis: even then usually editors have more than one "document"
<Shinmera>
plus swank already has eval-in-emacs :)
<scymtym>
emacs' eshell can do the output direction with echo "hi" > #<buf> ; echo "hi again" >> #<buf>
<scymtym>
the second command suggests something like (without-to-buffer (stream "buf" :if-exists :append) …)
<luis>
How worried are we about Lisp code being able to write to arbitrary buffers? eval-in-emacs is protected by a elisp-side variable.
<scymtym>
an (always|never|ask)-style customization variable seems in order
<Shinmera>
luis: If it requests a new buffer it should always be allowed (by default), and otherwise ask/deny by default.
<Shinmera>
At least in my opinion.
<luis>
What if such buffers need to be created on the Emacs side, and SWANK can ony write/read to/from such pre-existing buffers?
<scymtym>
i agree with Shinmera. writing to/reading from existing buffers seems more dangerous
<Shinmera>
the only abuse I can see in opening new buffers is flooding emacs, but then there's way easier ways to make things crash
<scymtym>
but all of this only matters if the lisp is sandboxed, right? otherwise it could do anything without emacs already (maybe except for stealing buffer content that is only stored encrypted on disk)
<Shinmera>
read/writing existing buffers could be useful for some things, but dangerous in general since it could touch data you don't want it to
<Shinmera>
scymtym: you could be connecting remotely for instance
<scymtym>
Shinmera: yes, that's one of the cases i was thinking of
scymtym has quit [Ping timeout: 268 seconds]
pesite has joined #slime
cage_ has quit [Remote host closed the connection]
pesite has quit [Remote host closed the connection]
scymtym has joined #slime
anamorphic_ has joined #slime
<fiddlerwoaroof>
I see I already have users :)
<fiddlerwoaroof>
The current setup requires mapping a buffer to a target and then creating a stream that sends output tot the target.
<fiddlerwoaroof>
So, I guess you could add a "new target" message that takes a target name and returns a target to lisp
<fiddlerwoaroof>
And then, on the lisp side, you add a stream that hides the target stuff as much as possible
<anamorphic_>
Is there perhaps a charter to grab all of Sly's differences?
<luis>
fiddlerwoaroof: yep, I'm getting excited about the feature, actually.
<luis>
anamorphic_: I wouldn't say all, but many, yes, of course.
<luis>
anamorphic_: what's your favorite Sly feature?
<anamorphic_>
Stickers I guess
<anamorphic_>
I don't quite understand some Sly benefits like real comint repl tbh
<luis>
anamorphic_: João is an Emacs contributor and is keen on writing idiomatic code. It might not have much of an immediate benefit for end users.
<luis>
Regarding stickers, I'm working on better support for breakpoints and stepping, I think stickers will be one of the features of that general functionality. So, I see breakpoints as something where we can break (and possibly step) but also trace (into the repl, the trace dialog or a sticker). Maybe we need a better name than "breakpoint", I'm not su
<luis>
re.
anamorphic_ has quit [Quit: anamorphic_]
anamorphic_ has joined #slime
<luis>
anamorphic_: anyway, I have no idea when this improved breakpoint support will cease to be vapourware, so if you'd like to cherry-pick Sly's stickers into SLIME, you're quite welcome to open a pull request!
<anamorphic_>
OK I'm a complete CL noob, but I'll have a go!