Andy Wingo <wi...@igalia.com> writes: > On Tue 05 Apr 2016 11:47, l...@gnu.org (Ludovic Courtès) writes: > >> Andy Wingo <wi...@igalia.com> skribis: >> [...] >>> >>> Sorry to tell you mixed signals, but did you consider Ludovic's >>> suggestion to use `package-field-location' ? >> >> I mentioned it mostly as a possible source of inspiration, but I think >> it cannot be used as-is here. > > Why not? Using that, you could limit the edit to the field and not the > whole package. Anyway, just a thought. > >> The trick to determine the boundaries of the ‘package’ form looks >> reasonable to me. Yes, I copy the `goto' function from `package-field-location' and happily notice that after do a `read' it's at the end location of the object. Without more thinking :-)
> In that case I think the ideal is something like "edit-expression", > which takes a source location that starts an expression, uses "read" to > advance to the end of the expression, then edits the intervening string > using whatever but verifies that the result can still be read as one > expression. Having recorded the absolute byte positions of the start > and end of the expression, you can then create the output by doing an > efficient bytevector read of the prologue, then display the string for > the edited expression, then the bytevector tail. > > Again, just a thought! Feel free to incorporate or not as you like, > 宋文武 :) Indeed this is better! To create the output from bytevector, it's using `get-bytevector-n' to read and `utf8->string' to write, right? And I think `edit-expression' could be: --8<---------------cut here---------------start------------->8--- (define (edit-expression source-properties proc) "Edit the object specified by SOURCE-PROPERTIS using PROC, which should be a procedure that take the original object and returns a new one." ...) --8<---------------cut here---------------end--------------->8--- I'll try it :-)