[sc-dev] questions about scel

[Justin Glenn Smith <noisesmith@xxxxxxxxx>]

As I continue to attempt to map some of the data flow in scel, I have a few questions. I should preface by saying that I accept the likelihood that anything I describe as an error or problem is a misunderstanding on my part - I am sharing these observations not as a critique but in the process of trying to understand how scel is designed and used, in order to better contribute to the project.

Is it the case that sc and emacs are communicating via two channels, stdin/stdout of sc (via emacs standard make-process) and simultaneously via a fifo? If so, why? Or is the fifo instead of the stdin/stdout route - and if so, why that?

In ScelDocument: init, initFromPath and prInitFromEmacs instance methods all set the checkCurrent variable to the same anonymous function, immediately before calling it. No method relies on the existing value (every method that uses it sets it first) and every time it is set, it is set to the same value. Similarly there is the instance variable cFuncs which is completely clobbered by the only methods that call it, other methods append values to it, but never call it, and will never get called, since the value gets clobbered before getting used in every usage case. I am guessing that these are signs that the class is in kind of an intermediate under construction state - or is there a logic here I am missing? Neither of these instance variables exist in the Document class, nor do they get called or set by any class other than ScelDocument itself. Are they there for use by some Quark?

Also in ScelDocument init and initFromPath directly call an EmacsDocument instance's prNewFromString and prNewFromPath instance methods respectively. This makes me think that these instance methods are either misnamed or being misused. Or is this an sc idiom for a "friend" class?

If I am parsing the code for EmacsDocument properly the string, currentLine currentBlock and currentWord instance methods are defined by quoted lisp code, rather than calling an elisp function via a token sent to elisp - title_, front, unfocusedFront, syntaxColorize, selectRange, prisEditable, removeUndo, string_ and prclose use this latter method, which I think is the right way to do it. This prevents sending code that has to be parsed and then evaluated for each call (saving a small amount of bandwidth, a small amount of cpu usage, and most importantly leaving the elisp code in a place and format where it can be much more easily read and edited). The EmacsBuffer and EmacsWidget classes do the same thing.

EmacsInterface is being initialized twice, once by Emacs and once by EmacsDocument, one immediately after the other. It could be that I am missing at the moment the reason that this has to be done, do let me know if I am.

On the elisp side of things, my one observed problem so far is that sclang-post-buffer is accessed in a variety of different ways - sometimes it is accessed via the constant string (ie. in sclang-start), and sometimes via sclang-get-post-buffer (ie. in sclang-init-post-buffer) and then everywhere else what seems to me "the right way" - through the with-sclang-post-buffer macro. Actually sclang-init-post-buffer accesses postbuffer via both of the latter two techniques in succession, which is redundant since with-sclang-post-buffer is calling sclang-get-post-buffer anyway it seems it should really be one or the other not both that are used. I was playing around with making a modification where the "real" postbuffer would be a hidden buffer, not accessible by normal buffer selection methods, and the postbuffer shown to the user would be an indirect buffer (to fix the "what happens when the user closes the postbuffer" issue). I was having a number of issues, which could have been
 caused by my misuse / misunderstanding of the emacs indirect buffer feature, or could have been caused by the various ways that the postbuffer is being accessed / potentially created. Or some third problem that I do not understand, of course :).

I have attached my updated diagram that I am editing as I read through the source (still very incomplete, and any inaccuracies likely reflect my failure to understand the code). I am sure it would have taken less time to use or put together an automatic call / access dataflow diagram than it is taking to make one, but I am learning quite a bit in the process of doing it by hand.

Also, who knew we had ascii slider widgets! I intend to look a bit further into that, and maybe make a nice looking unicode variation (I am sure there is some set of unicode symbols that could be combined to make a really sweet looking slider out there).

I am seeing so far a few places where my ext-scel elisp modifications are redundant to existing functions and methods, and I plan to try to integrate them into the existing functionality instead of making parallel code with the same intended usage.

Thanks in advance for any answers, feedback, or disagreement you may have that would help me better understand (and eventually, hopefully, improve) this code.