parenthesis highlighting

[Jan Groenewald]

Hi

Has there been any progress on this?
http://www.mail-archive.com/sage-s...@googlegroups.com/msg03975.html

One of the often heard comments from lecturers is that they
are wasting time on basic syntax, when students mismatch
parenthesis. In the simplest instance, when a closing ] or )
is typed it helps to highlight the correct (nested or not)
matching left one.

regards,
Jan
--
.~.
/V\ Jan Groenewald
/( )\ www.aims.ac.za
^^-^^

[William Stein]

On Fri, Sep 11, 2009 at 1:27 AM, Jan Groenewald <j...@aims.ac.za> wrote:
>
> Hi
>
> Has there been any progress on this?
> http://www.mail-archive.com/sage-s...@googlegroups.com/msg03975.html
>
> One of the often heard comments from lecturers is that they
> are wasting time on basic syntax, when students mismatch
> parenthesis. In the simplest instance, when a closing ] or )
> is typed it helps to highlight the correct (nested or not)
> matching left one.
>
> regards,
> Jan

I've added that to this list

http://wiki.sagemath.org/SageUsability

William

[Tom Boothby]

Working with the limited tools at my disposal (this will all go away
with BeSpin, if they know what they're doing), I introduce a hotkey
which finds the first open paren / brace / bracket and closes it at
your current cursor location:

http://trac.sagemath.org/sage_trac/ticket/3646

This is *almost* done. For some reason, I didn't see J. Palmieri's
most recent reply until now, but there's a very easy fix.

The problem with your suggestion is that highlighting something in a
cell is rather difficult since we use textareas and not franken-divs
as you see in the WSYIWYG html editors. We've tried to use a few of
those, but they have way too much CPU / RAM overhead. We played with
the emacs (?) style where the cursor jumps to the paren for a
half-second or so, but this was rife with problems, too.

On Fri, Sep 11, 2009 at 1:27 AM, Jan Groenewald <j...@aims.ac.za> wrote:
>

[Jason Grout]

Tom Boothby wrote:
> Working with the limited tools at my disposal (this will all go away
> with BeSpin, if they know what they're doing), I introduce a hotkey
> which finds the first open paren / brace / bracket and closes it at
> your current cursor location:
>
> http://trac.sagemath.org/sage_trac/ticket/3646
>
> This is *almost* done. For some reason, I didn't see J. Palmieri's
> most recent reply until now, but there's a very easy fix.
>
> The problem with your suggestion is that highlighting something in a
> cell is rather difficult since we use textareas and not franken-divs
> as you see in the WSYIWYG html editors. We've tried to use a few of
> those, but they have way too much CPU / RAM overhead. We played with
> the emacs (?) style where the cursor jumps to the paren for a
> half-second or so, but this was rife with problems, too.

> \

What about changing it for half a second or so to some character, like
&? In a sense, think of it as highlighting. So when you cursor over a
closing parenthesis, the opening one changes briefly to an & to let you
know where it is.

This might be a horrible idea---I'm just throwing it out there in the
interest of brainstorming.

That said, I would *really* like to eventually support the
"franken-divs". That would open up lots and lots of possibilities. I
know we've tried various content-editable divs for text cells
unsuccessfully. Maybe our own very-lightweight solution would be best.

How do you see BeSpin changing things? Isn't that pretty heavy-weight?

Jason

[Jan Groenewald]

Hi

On Fri, Sep 11, 2009 at 12:36:00PM -0500, Jason Grout wrote:
>I'm just throwing it out there in the
> interest of brainstorming.

Two more ideas:

1. a by default OFF feature, which can somewhere be set to
on, to prevent the CPU/RAM problems. Probably will trip up
inexperienced users who will leave it on though.

2. a completely non-automatic feature, which only runs once
when you click somwhere, "check parenthesis", which then checks
all or perhaps selected cells.

I have no idea how feasible these are.

[Tom Boothby]

On Fri, Sep 11, 2009 at 10:36 AM, Jason Grout
<jason...@creativetrax.com> wrote:
>
> Tom Boothby wrote:
>> Working with the limited tools at my disposal (this will all go away
>> with BeSpin, if they know what they're doing), I introduce a hotkey
>> which finds the first open paren / brace / bracket and closes it at
>> your current cursor location:
>>
>> http://trac.sagemath.org/sage_trac/ticket/3646
>>
>> This is *almost* done.  For some reason, I didn't see J. Palmieri's
>> most recent reply until now, but there's a very easy fix.
>>
>> The problem with your suggestion is that highlighting something in a
>> cell is rather difficult since we use textareas and not franken-divs
>> as you see in the WSYIWYG html editors.  We've tried to use a few of
>> those, but they have way too much CPU / RAM overhead.  We played with
>> the emacs (?) style where the cursor jumps to the paren for  a
>> half-second or so, but this was rife with problems, too.
>> \
>
> What about changing it for half a second or so to some character, like
> &?  In a sense, think of it as highlighting.  So when you cursor over a
> closing parenthesis, the opening one changes briefly to an & to let you
> know where it is.
>
> This might be a horrible idea---I'm just throwing it out there in the
> interest of brainstorming.

My first interpretation of the idea was "oh that's terrible", but on
re-reading, it might be OK. That said, I *really* hate things that
interrupt the flow of typing. AFAIK, console apps get around this by
buffering the input, and crapping it out all at once after the
highlighting is done -- this is much harder in the browser where we
don't have explicit control over every key.

>
> That said, I would *really* like to eventually support the
> "franken-divs".  That would open up lots and lots of possibilities.  I
> know we've tried various content-editable divs for text cells
> unsuccessfully.  Maybe our own very-lightweight solution would be best.
>
> How do you see BeSpin changing things?  Isn't that pretty heavy-weight?

I was hoping that since it's done by mozilla devs, that it would be
lightweight enough for us to use.

>
> Jason
>
>
> >
>

[Tom Boothby]

On Fri, Sep 11, 2009 at 11:14 AM, Jan Groenewald <j...@aims.ac.za> wrote:
>
> Hi
>
> On Fri, Sep 11, 2009 at 12:36:00PM -0500, Jason Grout wrote:
>>I'm just throwing it out there in the
>> interest of brainstorming.
>
> Two more ideas:
>
> 1. a by default OFF feature, which can somewhere be set to
> on, to prevent the CPU/RAM problems. Probably will trip up
> inexperienced users who will leave it on though.

The aforementioned CPU/RAM problems are intractable in the multi-cell
mode. Having more than three or four syntax-highlighting franken-divs
will just crash your browser. Perhaps if you have a few dozen gigs of
RAM, it won't crash because it will slow to a crawl before filling up
all available memory.

>
> 2. a completely non-automatic feature, which only runs once
> when you click somwhere, "check parenthesis", which then checks
> all or perhaps selected cells.

That's what the ctrl-0 in #3646 does.

[William Stein]

On Fri, Sep 11, 2009 at 11:20 AM, Tom Boothby <tomas....@gmail.com> wrote:
>
> On Fri, Sep 11, 2009 at 11:14 AM, Jan Groenewald <j...@aims.ac.za> wrote:
>>
>> Hi
>>
>> On Fri, Sep 11, 2009 at 12:36:00PM -0500, Jason Grout wrote:
>>>I'm just throwing it out there in the
>>> interest of brainstorming.
>>
>> Two more ideas:
>>
>> 1. a by default OFF feature, which can somewhere be set to
>> on, to prevent the CPU/RAM problems. Probably will trip up
>> inexperienced users who will leave it on though.
>
> The aforementioned CPU/RAM problems are intractable in the multi-cell
> mode.  Having more than three or four syntax-highlighting franken-divs
> will just crash your browser.  Perhaps if you have a few dozen gigs of
> RAM, it won't crash because it will slow to a crawl before filling up
> all available memory.

That is a bit of an exageration, but a fun one :-) One can change
back and forth so that at any given moment only the currently edited
cell is the "franken-div" and no others are. That said, I think you
and I (Booth and I) tried that once and even that simply didn't feel
snappy enough. Snappiness is extremely important in the Sage
notebook, IMHO, and we should do our best to make it even more snappy
than it is, not less snappy.

William

>>
>> 2. a completely non-automatic feature, which only runs once
>> when you click somwhere, "check parenthesis", which then checks
>> all or perhaps selected cells.
>
> That's what the ctrl-0 in #3646 does.
>
>>
>> I have no idea how feasible these are.
>>
>> Jan
>>
>> --
>>   .~.
>>   /V\     Jan Groenewald
>>  /( )\    www.aims.ac.za
>>  ^^-^^
>>
>> >
>>
>
> >
>

--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

[Jason Grout]

William Stein wrote:
> On Fri, Sep 11, 2009 at 11:20 AM, Tom Boothby <tomas....@gmail.com> wrote:
>> On Fri, Sep 11, 2009 at 11:14 AM, Jan Groenewald <j...@aims.ac.za> wrote:
>>> Hi
>>>
>>> On Fri, Sep 11, 2009 at 12:36:00PM -0500, Jason Grout wrote:
>>>> I'm just throwing it out there in the
>>>> interest of brainstorming.
>>> Two more ideas:
>>>
>>> 1. a by default OFF feature, which can somewhere be set to
>>> on, to prevent the CPU/RAM problems. Probably will trip up
>>> inexperienced users who will leave it on though.
>> The aforementioned CPU/RAM problems are intractable in the multi-cell
>> mode. Having more than three or four syntax-highlighting franken-divs
>> will just crash your browser. Perhaps if you have a few dozen gigs of
>> RAM, it won't crash because it will slow to a crawl before filling up
>> all available memory.
>
> That is a bit of an exageration, but a fun one :-)

Indeed! I just opened up 6 TinyMCE instances (which are exactly these
"franken-divs" that we are talking about), and things seemed pretty
snappy still. There was a CPU spike when the TinyMCE initialized, but
input seemed very responsive. Keep in mind that only one of these
content-editable divs will be changing at a time.

Why would having more than one content-editable div increase the memory
that much? Presumably there is a global shared library of javascript
functions that provide all the actual guts of the editing, so there
won't be that much memory needed to instantiate any single editor.

Jason

[Tom Boothby]

On Fri, Sep 11, 2009 at 1:35 PM, Jason Grout
<jason...@creativetrax.com> wrote:
>
> William Stein wrote:
>> On Fri, Sep 11, 2009 at 11:20 AM, Tom Boothby <tomas....@gmail.com> wrote:
>>> On Fri, Sep 11, 2009 at 11:14 AM, Jan Groenewald <j...@aims.ac.za> wrote:
>>>> Hi
>>>>
>>>> On Fri, Sep 11, 2009 at 12:36:00PM -0500, Jason Grout wrote:
>>>>> I'm just throwing it out there in the
>>>>> interest of brainstorming.
>>>> Two more ideas:
>>>>
>>>> 1. a by default OFF feature, which can somewhere be set to
>>>> on, to prevent the CPU/RAM problems. Probably will trip up
>>>> inexperienced users who will leave it on though.
>>> The aforementioned CPU/RAM problems are intractable in the multi-cell
>>> mode.  Having more than three or four syntax-highlighting franken-divs
>>> will just crash your browser.  Perhaps if you have a few dozen gigs of
>>> RAM, it won't crash because it will slow to a crawl before filling up
>>> all available memory.
>>
>> That is a bit of an exageration, but a fun one :-)
>
>
> Indeed!  I just opened up 6 TinyMCE instances (which are exactly these
> "franken-divs" that we are talking about), and things seemed pretty
> snappy still.  There was a CPU spike when the TinyMCE initialized, but
> input seemed very responsive.  Keep in mind that only one of these
> content-editable divs will be changing at a time.

MCE is not the problem -- the one I'm referring to (the name escapes
me at the moment) was a full-blown code editor -- it had syntax
highlighting as you go, a custom undo buffer, the works. And it blew
up any browser that I tried it on if you have more than a couple of
them on screen -- even if the actual editor part was backgrounded.

> Why would having more than one content-editable div increase the memory
> that much?  Presumably there is a global shared library of javascript
> functions that provide all the actual guts of the editing, so there
> won't be that much memory needed to instantiate any single editor.

You'd think so... but keep in mind that a syntax-highlighting
frankendiv works by putting every word in a separate DOM object. The
result is exceptionally massive DOM trees that quickly fill all
available memory. Now add to that jsMath and jQuery which frequently
walk the entire DOM tree, often running regular expressions on the
contents -- this takes up all available processor time. This *could*
be done right with the tools that are available to us (the
javascript-using community), but it hasn't been done right yet, and I
do not believe that there are easy drop-in solutions (we're not
inventing the wheel, right?) for this yet. I'm hoping that BeSpin
will be the silver bullet.

>
> Jason
>
>
> >
>