Quantcast

Document.current.currentLine returns nothing

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Document.current.currentLine returns nothing

hellomynameisphil
Hi all,

I am working on a code-generation framework for SuperCollider ( https://github.com/philthomson/trackgen ) and running into an issue.

The way things work at the moment is that I have a document which I evaluate, then open a new document and use a function to insert randomly generated code from a template (a string with some random elements which is interpreted using the .interpret method of String) into the new document.

I am not able to insert code at the current line, because it seems Document.current.currentLine returns nothing. From the documentation, it was my expectation that it would return the current line in the current document as a String.

Here is some sample code:

(
~ins = { |insertion|
    var doc = Document.current;
    doc.insertText(insertion, doc.currentLine);
    insertion.interpret;
};
);

~test = "{ SinOsc.ar(" ++ (250.rand + 250) ++ ") }.play;";

~ins.value(~test);

My expectation was that the last line of the above code should insert a function with a SinOsc with a randomized frequency into the current line, but the code is always inserted at the beginning of the document no matter where the cursor is. Changing 'doc.insertText(insertion, doc.currentLine);' to 'doc.insertText(insertion, 10000);' appends at the end (as long as the document is less than 10000 lines), but this isn't really what I want. I also tried 'doc.insertText(insertion, doc.currentLine.asInteger);', and that doesn't work either.

Is my expectation based on an incorrect understanding of Document.current.currentLine? Is there a bug? Is there a better way to do what I want to do?

Phil

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Document.current.currentLine returns nothing

ddw_music
hellomynameisphil wrote
I am working on a code-generation framework for SuperCollider ( https://github.com/philthomson/trackgen ) and running into an issue.

The way things work at the moment is that I have a document which I evaluate, then open a new document and use a function to insert randomly generated code from a template (a string with some random elements which is interpreted using the .interpret method of String) into the new document.

I am not able to insert code at the current line, because it seems Document.current.currentLine returns nothing.
'currentLine' does indeed return the current line as a string. But 'insertText' expects the position to be given as an integer.

You don't need the current line -- what you need is *the position of* the current line. 'currentLine' gives you the contents, not the position. So it's the wrong method to use for this context.

I'm browsing over the Document class interface, and it looks like there is no easy, single-call way to do this. As far as I can see, you'll have to start at the document's selectionStart, scan backward (with getChar) until you find a newline or beginning of the document, and scan forward to the next newline / end of document.

The class interface here is certainly incomplete: 'selectLine' does indeed select an entire line, but you have to know the line number -- and Document has no method to determine the line number. ??? You *can* ask Document for the character index in the document (selectionStart), but there is no method selectLineAtIndex(charIndex).

So I'm afraid you're stuck doing it "by hand," writing a couple of 'while' loops in SC to do the things that the class doesn't know how to do for you.

> My expectation was that the last line of the above code should insert a function with a SinOsc with a randomized frequency into the current line, but the code is always inserted at the beginning of the document no matter where the cursor is.

Oh, that's a bug. If you pass a string, it should throw a wrong-type error. Instead, it's converting to 0 and failing silently. Silent failures are one of the things the devs are trying to track down and squash. I'll open an issue for that.

hjh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Document.current.currentLine returns nothing

ddw_music
ddw_music wrote
> My expectation was that the last line of the above code should insert a function with a SinOsc with a randomized frequency into the current line, but the code is always inserted at the beginning of the document no matter where the cursor is.

Oh, that's a bug. If you pass a string, it should throw a wrong-type error. Instead, it's converting to 0 and failing silently. Silent failures are one of the things the devs are trying to track down and squash. I'll open an issue for that.
Actually, it does throw the error (see below). So I have no idea why you're getting the text at the beginning, instead of the proper error.

Maybe your SC is out of date?

hjh

Document.current.insertText("hello", Document.current.currentLine)

ERROR: Primitive '_ScIDE_SetDocTextMirror' failed.
Wrong type.
RECEIVER:
Instance of Document {    (0x622ae38, gc=EC, fmt=00, flg=00, set=04)
  instance variables [16]
  ... snip ...
}
CALL STACK:
        MethodError:reportError   0x2f0e858
                arg this = <instance of PrimitiveFailedError>
        Nil:handleError   0x29a68f8
                arg this = nil
                arg error = <instance of PrimitiveFailedError>
        Thread:handleError   0x6378bf8
                arg this = <instance of Thread>
                arg error = <instance of PrimitiveFailedError>
        Object:throw   0x2f88398
                arg this = <instance of PrimitiveFailedError>
        Object:primitiveFailed   0x29a66e8
                arg this = <instance of Document>
        Document:prSetTextMirror   0x6433338
                arg this = <instance of Document>
                arg quuid = '{efdb33f9-73f8-463f-afd8-a832c8902eaa}'
                arg text = "hello"
                arg start = "Document.current.insertText(..."
                arg range = 0
        Document:prSetText   0x5e2aa68
                arg this = <instance of Document>
                arg text = "hello"
                arg action = nil
                arg start = "Document.current.insertText(..."
                arg range = 0
                var funcID = nil
        Document:insertText   0x2abc1f8
                arg this = <instance of Document>
                arg string = "hello"
                arg index = "Document.current.insertText(..."
        Interpreter:interpretPrintCmdLine   0x5e37e48
                arg this = <instance of Interpreter>
                var res = nil
                var func = <instance of Function>
                var code = "Document.current.insertText(..."
                var doc = nil
                var ideClass = <instance of Meta_ScIDE>
        Process:interpretPrintCmdLine   0x7a37878
                arg this = <instance of Main>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Document.current.currentLine returns nothing

brian heim
> but there is no method selectLineAtIndex(charIndex)

Isn't that what getSelectedLines(charIndex, 0) does? It takes a given char index in the document text and returns a String copied from the line containing that char index. Maybe I'm misunderstanding.

To do what james is suggesting re: scanning to find the range limits of the current line, you could easily adapt the existing implementation of getSelectedLines:

    getSelectedLines { | rangestart = -1, rangesize = 0 |
        var start, end, str, max;
        str = this.string;
        max = str.size;
        start = rangestart;
        end = start + rangesize;
        while {
            str[start] !== Char.nl and: { start >= 0 }
        } { start = start - 1 };
        while {
            str[end] !== Char.nl and: { end < max }
        } { end = end + 1 };
        ^str.copyRange(start + 1, end);
    }

In fact, this code should be refactored into interface functions (endOfLine(index) and startOfLine(index) or something similar). I might get on that tomorrow.

-Brian

On Mon, Feb 6, 2017 at 7:29 PM, ddw_music <[hidden email]> wrote:
ddw_music wrote
>> My expectation was that the last line of the above code should insert a
>> function with a SinOsc with a randomized frequency into the current line,
>> but the code is always inserted at the beginning of the document no
>> matter where the cursor is.
>
> Oh, that's a bug. If you pass a string, it should throw a wrong-type
> error. Instead, it's converting to 0 and failing silently. Silent failures
> are one of the things the devs are trying to track down and squash. I'll
> open an issue for that.

Actually, it does throw the error (see below). So I have no idea why you're
getting the text at the beginning, instead of the proper error.

Maybe your SC is out of date?

hjh

Document.current.insertText("hello", Document.current.currentLine)

ERROR: Primitive '_ScIDE_SetDocTextMirror' failed.
Wrong type.
RECEIVER:
Instance of Document {    (0x622ae38, gc=EC, fmt=00, flg=00, set=04)
  instance variables [16]
  ... snip ...
}
CALL STACK:
        MethodError:reportError   0x2f0e858
                arg this = <instance of PrimitiveFailedError>
        Nil:handleError   0x29a68f8
                arg this = nil
                arg error = <instance of PrimitiveFailedError>
        Thread:handleError   0x6378bf8
                arg this = <instance of Thread>
                arg error = <instance of PrimitiveFailedError>
        Object:throw   0x2f88398
                arg this = <instance of PrimitiveFailedError>
        Object:primitiveFailed   0x29a66e8
                arg this = <instance of Document>
        Document:prSetTextMirror   0x6433338
                arg this = <instance of Document>
                arg quuid = '{efdb33f9-73f8-463f-afd8-a832c8902eaa}'
                arg text = "hello"
                arg start = "Document.current.insertText(..."
                arg range = 0
        Document:prSetText   0x5e2aa68
                arg this = <instance of Document>
                arg text = "hello"
                arg action = nil
                arg start = "Document.current.insertText(..."
                arg range = 0
                var funcID = nil
        Document:insertText   0x2abc1f8
                arg this = <instance of Document>
                arg string = "hello"
                arg index = "Document.current.insertText(..."
        Interpreter:interpretPrintCmdLine   0x5e37e48
                arg this = <instance of Interpreter>
                var res = nil
                var func = <instance of Function>
                var code = "Document.current.insertText(..."
                var doc = nil
                var ideClass = <instance of Meta_ScIDE>
        Process:interpretPrintCmdLine   0x7a37878
                arg this = <instance of Main>



--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Document-current-currentLine-returns-nothing-tp7630562p7630564.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/



--
_______________________________
Brian Heim
<a href="tel:(507)%20429-6468" value="+15074296468" target="_blank">507-429-6468

B.M. '14 University of Texas at Austin
M.M. '16 Yale School of Music
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Document.current.currentLine returns nothing

ddw_music
brian heim wrote
> but there is no method selectLineAtIndex(charIndex)

Isn't that what getSelectedLines(charIndex, 0) does? It takes a given char
index in the document text and returns a String copied from the line
containing that char index. Maybe I'm misunderstanding.
Interesting, but unwittingly, this demonstrates why the Document interface is both confusing and incomplete. getSelectedLines accepts the kind of input I was talking about (a character index into the document), and it does *something* with the line spanning the index... but it doesn't do the *desired* thing with it. It copies the string from the document, but Phil needs a line to be selected so that selectedString_ can overwrite the text.

A proper interface would have:

- Methods to get the line's bounds (as indices);
- A method to copy the string from those indices;
- A method to select between those indices.
- (Optional) A method to replace the text between those indices (although this might not be necessary, because it's easy to do selectSomePartOfDoc(...).selectedString_("blah blah")).

To be consistent, every possible type of selection that Document supports should do all three. Range selection (by index and size) is pretty well supported, but the line-based interface?

- Line bounds? Nope. Missing.

- Copy lines? Yes, but doesn't allow you access to the bounds.

- Select lines? Sort of... selectLine exists, but its argument is incompatible with every other Document method (and Document provides no interface to obtain a meaningful number to put into this method!). So selectLine is currently pretty much useless as it is.

I'm pretty sure I don't have time to fix it, but if you're going to re-factor, those are some ideas on completing what is a weak part of this class's interface.

            str[start] !== Char.nl and: { start >= 0 }
BTW, why are we indexing the array *before* checking whether the index is in bounds? It will "work" but the logic is cleaner this way:

            start >= 0 and: { str[start] !== Char.nl }

Same for 'end'.

hjh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Document.current.currentLine returns nothing

Julian Rohrhuber-3
>
>
> Interesting, but unwittingly, this demonstrates why the Document interface
> is both confusing and incomplete.

Most of the Document interface was never properly reviewed and I always found it inconsistently named. Would it be a good idea perhaps to completely redo this? We could keep the old interface in a Quark, and a class Document2.


signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Document.current.currentLine returns nothing

thor-3

Hi Julian,

I think that's a great idea. I've been meaning to port ixi lang to SC Qt, but I have the feeling I don't have time to deal with all the problems that I foresee.

There has been some good work on this lately, I believe. Is it now possible to give individual lines of text different Font colour?

Also, I think it would be ideal if the string manipulation interface in TextView and Document would be the same.

Cheers,
Thor
 


> On 7 Feb 2017, at 10:40, Julian Rohrhuber <[hidden email]> wrote:
>
>>
>>
>> Interesting, but unwittingly, this demonstrates why the Document interface
>> is both confusing and incomplete.
>
> Most of the Document interface was never properly reviewed and I always found it inconsistently named. Would it be a good idea perhaps to completely redo this? We could keep the old interface in a Quark, and a class Document2.
>



_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Document.current.currentLine returns nothing

Scott Wilson
In reply to this post by Julian Rohrhuber-3
Please do this. IIRC, the current state of affairs is the result of some discussions about how the interface should be reworked when this was reimplemented, which never arrived at a consensus. This was after a long gap of no Document, so I doubt this would cause many problems.

S.

> On 7 Feb 2017, at 10:40, Julian Rohrhuber <[hidden email]> wrote:
>
>>
>>
>> Interesting, but unwittingly, this demonstrates why the Document interface
>> is both confusing and incomplete.
>
> Most of the Document interface was never properly reviewed and I always found it inconsistently named. Would it be a good idea perhaps to completely redo this? We could keep the old interface in a Quark, and a class Document2.
>


_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Document.current.currentLine returns nothing

brian heim
James, just so I'm getting this right, is this the current situation? :

We have exactly two approaches to indexing into documents: char-based and line-based
We want methods that will translate cleanly between those two (what line am I in for a given char index?; what char bounds do I have for a given line?)
We also want a `line` version of as many char-based methods as possible (these would be trivial given that we can now easily translate between those concepts)

Some of these methods (like a method that counts the lines in a given text), may actually be more appropriate as methods on String IMO. But we can discuss the details on the dev list.

> Also, I think it would be ideal if the string manipulation interface in TextView and Document would be the same.

Absolutely agree

> the current state of affairs is the result of some discussions about how the interface should be reworked when this was reimplemented, which never arrived at a consensus

Scott, do you know where I could find any of those discussions? I've been looking at #1208, #2314.

Since this is a larger endeavor than refactoring 2 methods out of existing code, I'll probably wait until later this week or maybe this weekend to work on it.

Brian

On Tue, Feb 7, 2017 at 9:11 AM, Scott Wilson <[hidden email]> wrote:
Please do this. IIRC, the current state of affairs is the result of some discussions about how the interface should be reworked when this was reimplemented, which never arrived at a consensus. This was after a long gap of no Document, so I doubt this would cause many problems.

S.

> On 7 Feb 2017, at 10:40, Julian Rohrhuber <[hidden email]> wrote:
>
>>
>>
>> Interesting, but unwittingly, this demonstrates why the Document interface
>> is both confusing and incomplete.
>
> Most of the Document interface was never properly reviewed and I always found it inconsistently named. Would it be a good idea perhaps to completely redo this? We could keep the old interface in a Quark, and a class Document2.
>





--
_______________________________
Brian Heim
507-429-6468

B.M. '14 University of Texas at Austin
M.M. '16 Yale School of Music
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Document.current.currentLine returns nothing

Scott Wilson

On 7 Feb 2017, at 14:59, brian heim <[hidden email]> wrote:

Scott, do you know where I could find any of those discussions? I've been looking at #1208, #2314.

I took a quick look. There are several Document related PRs, and there also a bunch of list threads. I can’t find the specific API discussion I was thinking of, but to be honest I don’t think it matters. The old pre-IDE Document was an odd mix of subclasses, redirects, and clusterclass, with no real parity across platforms and editors. The IDE version is a bit more stripped down, but has not been a 100% reimplementation (well, Cocoa had rich text documents, for instance).

So I think it makes sense to clean house and implement something sensible, with a possible compatibility Quark as Julian suggested. Beyond the API decisions, I think the main thing needed is a clear decision about how this works across different platforms/editors (which of course may offer different functionality!), and what should be there for a cl SC. In the past there have been issues with extensions that referenced Document causing compilation to fail, so there have been requests for a stub.

If it were up to me, I'd say agree a minimum interface, which could be defined in an abstract superclass, in which methods could do nothing if appropriate or throw SubclassResponsibilityErrors in proper Smalltalk style. Then this should all be clearly documented (no pun intended) so that Quark and Common authors know what’s reasonable for portable code.

In any case, I apologise for my part in leaving this unfinished!

S.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Document.current.currentLine returns nothing

ddw_music
In reply to this post by brian heim
> We have exactly two approaches to indexing into documents: char-based and line-based

Right now, only char-based is complete. Line-based exists in a single method (selectLine) and there is no other support for it.

> We want methods that will translate cleanly between those two (what line am I in for a given char index?; what char bounds do I have for a given line?)

If we're going to have both, that would be essential.

> We also want a `line` version of as many char-based methods as possible (these would be trivial given that we can now easily translate between those concepts)

Pretty much just getting and setting strings... Offhand, I can't think of anything else we would want to do with it.

Something else I just noticed: Document has a 'textChangedAction', but TextView doesn't. For cross-compatibility, it should. I'm going to file a separate issue for that -- this would be extremely useful for a live-coding GUI I've been working on, which currently breaks down if I hit ctrl-z (undo).

hjh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Document.current.currentLine returns nothing

brian heim
Re Scott:
 
what should be there for a cl SC

I'm trying not to miss anything in this discussion — is "cl SC" a typo or jargon I haven't learned yet?
 
If it were up to me, I'd say agree a minimum interface, which could be defined in an abstract superclass, in which methods could do nothing if appropriate or throw SubclassResponsibilityErrors in proper Smalltalk style. Then this should all be clearly documented (no pun intended) so that Quark and Common authors know what’s reasonable for portable code.

I agree completely.

Re James:

We have exactly two approaches to indexing into documents: char-based and
line-based
 
Right now, only char-based is complete. Line-based exists in a single method
(selectLine) and there is no other support for it.

Yep! I was just making sure that's all we were talking about so I can wrap my head around it. I was thinking word-counting would be another way of indexing, but I want to keep it simple for now.

Something else I just noticed: Document has a 'textChangedAction', but
TextView doesn't. For cross-compatibility, it should. I'm going to file a
separate issue for that -- this would be extremely useful for a live-coding
GUI I've been working on, which currently breaks down if I hit ctrl-z
(undo).

Just saw the issue—thanks for that :)

-Brian


On Tue, Feb 7, 2017 at 8:49 PM, ddw_music <[hidden email]> wrote:
> We have exactly two approaches to indexing into documents: char-based and
line-based

Right now, only char-based is complete. Line-based exists in a single method
(selectLine) and there is no other support for it.

> We want methods that will translate cleanly between those two (what line
> am I in for a given char index?; what char bounds do I have for a given
> line?)

If we're going to have both, that would be essential.

> We also want a `line` version of as many char-based methods as possible
> (these would be trivial given that we can now easily translate between
> those concepts)

Pretty much just getting and setting strings... Offhand, I can't think of
anything else we would want to do with it.

Something else I just noticed: Document has a 'textChangedAction', but
TextView doesn't. For cross-compatibility, it should. I'm going to file a
separate issue for that -- this would be extremely useful for a live-coding
GUI I've been working on, which currently breaks down if I hit ctrl-z
(undo).

hjh



--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Document-current-currentLine-returns-nothing-tp7630562p7630584.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.




--
_______________________________
Brian Heim
507-429-6468

B.M. '14 University of Texas at Austin
M.M. '16 Yale School of Music
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Document.current.currentLine returns nothing

Scott Wilson

On 8 Feb 2017, at 02:18, brian heim <[hidden email]> wrote:

I'm trying not to miss anything in this discussion — is "cl SC" a typo or jargon I haven't learned yet? 

Sorry, I have a bad habit of abbreviating! Comes from actively resisting British loquaciousness...

cl is command line, i.e. no editor attached. The ontological status of a Document there is up for debate! Julian?

S.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Document.current.currentLine returns nothing

brian heim
Ah, of course. Thanks :)

Just wanted to update on this—I spent most of this weekend (well, really all of it) building and testing #2704, so I didn't have time to tackle Document. Anyone else is more than welcome to start on it; otherwise, I'll hopefully get to it this next weekend.

-Brian

On Wed, Feb 8, 2017 at 5:25 AM, Scott Wilson <[hidden email]> wrote:

On 8 Feb 2017, at 02:18, brian heim <[hidden email]> wrote:

I'm trying not to miss anything in this discussion — is "cl SC" a typo or jargon I haven't learned yet? 

Sorry, I have a bad habit of abbreviating! Comes from actively resisting British loquaciousness...

cl is command line, i.e. no editor attached. The ontological status of a Document there is up for debate! Julian?

S.



--
_______________________________
Brian Heim
507-429-6468

B.M. '14 University of Texas at Austin
M.M. '16 Yale School of Music
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Document.current.currentLine returns nothing

Julian Rohrhuber-3
In reply to this post by Scott Wilson

> On 08.02.2017, at 11:25, Scott Wilson <[hidden email]> wrote:
>
>
>> On 8 Feb 2017, at 02:18, brian heim <[hidden email]> wrote:
>>
>> I'm trying not to miss anything in this discussion — is "cl SC" a typo or jargon I haven't learned yet?
>
> Sorry, I have a bad habit of abbreviating! Comes from actively resisting British loquaciousness...
>
> cl is command line, i.e. no editor attached. The ontological status of a Document there is up for debate! Julian?


A Document (as opposed to a mere “document”) is the place where programming happens. It is therefore the crossroads of demands of the programmer and the program. Often neglected as such and degraded to a mere file, it becomes the storage place for text. In the sclang style interactive programming, it implements a number of concepts, such as program location, selection, interpretation, text modification, which should be symmetrically and systematically accessible by programmer and program.

Document is also a place where literate programming happens, that is where code and non-code coexist. Traditionally, this meant also the possibility of rich text editing, a feature that has been temporarily lost.

Being the “loop” part of the read-eval-print-loop, the post window is also a Document.

Optionally, a Document could integrate other modalities of display than text, and other ordering of text than a line-based one. This isn’t important now, but the design shouldn’t exclude such options in the future.





_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Document.current.currentLine returns nothing

Scott Wilson
:-)

> On 13 Feb 2017, at 19:41, Julian Rohrhuber <[hidden email]> wrote:
>
>
>> On 08.02.2017, at 11:25, Scott Wilson <[hidden email]> wrote:
>>
>>
>>> On 8 Feb 2017, at 02:18, brian heim <[hidden email]> wrote:
>>>
>>> I'm trying not to miss anything in this discussion — is "cl SC" a typo or jargon I haven't learned yet?
>>
>> Sorry, I have a bad habit of abbreviating! Comes from actively resisting British loquaciousness...
>>
>> cl is command line, i.e. no editor attached. The ontological status of a Document there is up for debate! Julian?
>
>
> A Document (as opposed to a mere “document”) is the place where programming happens. It is therefore the crossroads of demands of the programmer and the program. Often neglected as such and degraded to a mere file, it becomes the storage place for text. In the sclang style interactive programming, it implements a number of concepts, such as program location, selection, interpretation, text modification, which should be symmetrically and systematically accessible by programmer and program.
>
> Document is also a place where literate programming happens, that is where code and non-code coexist. Traditionally, this meant also the possibility of rich text editing, a feature that has been temporarily lost.
>
> Being the “loop” part of the read-eval-print-loop, the post window is also a Document.
>
> Optionally, a Document could integrate other modalities of display than text, and other ordering of text than a line-based one. This isn’t important now, but the design shouldn’t exclude such options in the future.
>
>
>
>
>
> _______________________________________________
> sc-users mailing list
>
> info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/


_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Document.current.currentLine returns nothing

brian heim
FYI, I started on a PR for this here: https://github.com/supercollider/supercollider/pull/2718
Let's migrate discussion there.

Also, that was an excellent treatise, Julian. :)

Regards,
Brian

On Wed, Feb 15, 2017 at 4:58 AM, Scott Wilson <[hidden email]> wrote:
:-)

> On 13 Feb 2017, at 19:41, Julian Rohrhuber <[hidden email]> wrote:
>
>
>> On 08.02.2017, at 11:25, Scott Wilson <[hidden email]> wrote:
>>
>>
>>> On 8 Feb 2017, at 02:18, brian heim <[hidden email]> wrote:
>>>
>>> I'm trying not to miss anything in this discussion — is "cl SC" a typo or jargon I haven't learned yet?
>>
>> Sorry, I have a bad habit of abbreviating! Comes from actively resisting British loquaciousness...
>>
>> cl is command line, i.e. no editor attached. The ontological status of a Document there is up for debate! Julian?
>
>
> A Document (as opposed to a mere “document”) is the place where programming happens. It is therefore the crossroads of demands of the programmer and the program. Often neglected as such and degraded to a mere file, it becomes the storage place for text. In the sclang style interactive programming, it implements a number of concepts, such as program location, selection, interpretation, text modification, which should be symmetrically and systematically accessible by programmer and program.
>
> Document is also a place where literate programming happens, that is where code and non-code coexist. Traditionally, this meant also the possibility of rich text editing, a feature that has been temporarily lost.
>
> Being the “loop” part of the read-eval-print-loop, the post window is also a Document.
>
> Optionally, a Document could integrate other modalities of display than text, and other ordering of text than a line-based one. This isn’t important now, but the design shouldn’t exclude such options in the future.
>
>
>
>
>
> _______________________________________________
> sc-users mailing list
>
> info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/


_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/



--
_______________________________
Brian Heim
507-429-6468

B.M. '14 University of Texas at Austin
M.M. '16 Yale School of Music
Loading...