Parse inline scheme using per-expression port (issue 557330043 by address@hidden)

[dak]

Ok, that should probably have been stressed somewhat stronger before:
have you checked the preexisting Guilev2 work in branches that Harm
pointed you to?

The problem you are addressing here seems to be the same as the one
tackled in commit c0a8eec034b94be14c7665e2d4c8a94fae111b78 , namely
commit c0a8eec034b94be14c7665e2d4c8a94fae111b78 (origin/dev/guilev2)
Author: David Kastrup <address@hidden>
Date:   Sun Sep 21 18:40:06 2014 +0200

    Source_file::init_port: Keep GUILEv2 from redecoding string input

diff --git a/lily/source-file.cc b/lily/source-file.cc
index 5a94927a7f..5ad9c4c6e8 100644
--- a/lily/source-file.cc
+++ b/lily/source-file.cc
@@ -152,7 +152,11 @@ Source_file::init_port ()
   // we do our own utf8 encoding and verification in the parser, so we
   // use the no-conversion equivalent of latin1
   SCM str = scm_from_latin1_string (c_str ());
-  str_port_ = scm_mkstrport (SCM_INUM0, str, SCM_OPN | SCM_RDNG,
__FUNCTION__);
+  scm_dynwind_begin ((scm_t_dynwind_flags)0);
+  // Why doesn't scm_set_port_encoding_x work here?
+  scm_dynwind_fluid (ly_lily_module_constant
("%default-port-encoding"), SCM_BOOL_F);
+  str_port_ = scm_open_input_string (str);
+  scm_dynwind_end ();
   scm_set_port_filename_x (str_port_, ly_string2scm (name_));
 }

Now it is a valid question why this isn't, GUILEV2-guarded, already in
the main code base.  Maybe we should integrate all of the already
existing Guilev2 work into master with priority in order to avoid
duplicate work.

https://codereview.appspot.com/557330043/