Shift-click when creating a new cell.
One can "discover" this by reading the page that pops up when you
click "Help" in the upper right.
William
By the way, one annoying thing about tinymce is that there is no
"shift-click" on the iphone. And there is no double click. So it is
impossible to bring up the tinymce editor on the iphone.
This reminds me of the situation that lead to the little "evaluate"
link, which people actually rather like. Maybe something similar
should be added for tinymce.
William
At one point, I thought we could divide the current insert line into two
halves (maybe colored differently). One half would be for code input,
the other half for text cells.
What do you think?
Jason
I found it!
HTML Shift click between cells to create a new HTML cell. Double click
on existing HTML to edit it. Use $...$ and $$...$$ to include typeset
math in the HTML block.
-----
I think a "new user" might wonder what editing text has to do with
"HTML". But I guess this is the kind of question that you only need to
ask once.
Shouldn't there be a more visible way - similar to what you do to
create other new cells?
On Mon, Feb 16, 2009 at 11:59 AM, William Stein wrote:
Any suggestions?
William
I agree that this should be simple to implement. Can you file a trac
ticket for this feature and CC me on it (jason)?
Thanks,
Jason
What I was looking for was some king of highlighting as I hover the
mouse over the cell. Right now I see a blue bar where a new
computation would be inserted if I click the mouse. It appears right
at the start of each cell just *before* the input box and another
final one at the bottom of the page.
What might seem natural to *me* would be another color of bar, say a
red, just like the blue one but at the bottom of each input cell just
*after* the input cell and for good measure an extra initial one at
the top of the page. Of course these should only appear when moving
the mouse in the right location. The click a red bar would lead to
inserting an "HTML" block via TinyMCE. All it would take is just one
experiment by a user to know which input bar does what.
Well, that's my two-cents worth but I realize there may be several
other ways to accomplish something similar.
Regards,
Bill Page.
How about, in the spirit of the "evaluate" link being real text that
someone can read and immediately guess the function, we have the
new-cell bar, when someone mouses over it, show something like:
___________________________________________________________________
| new code cell | new text cell |
|_____________________________|___________________________________|
Of course, the text would be small (small enough that the new cell bar
wouldn't be much bigger than it is now).
Jason
I do not consider this the "best" but rather a "lowest common
denominator" kind of thing. I quite dislike the evaluate links
scattered down the page, although I have seen many times that this is
what almost every "new user" looks for first rather than discovering
that shift-enter does the same thing.
> This would put placement of the "new" function in the same place
> it always has been, for both code and text. And it would give the
> new user some idea of just what the blue bar is for anyway.
>
What if the bar included "evaluate" as well?
___________________________________________________________________
|______ evaluate ____|_____ new command _____|____ new text _____|
And an option to "auto hide" the bar. The bar would be visible by
default on new worksheets. If you clicked auto hide, then it would
only be visible when hovering over it with the mouse.
> Rather than "code," would "commands" make more sense to the new
> user without sounding too pedantic or simplified to the pros?
>
I don't think this has anything to do with sounding/looking "too
simplified". Simple is better and beautiful. This is about visual
design - creating something that both looks nice *and* works well - an
art that engineers (and apparently also mathematicians :-) often lack.
Regards,
Bill Page
A problem with this proposal is that the evaluate button and the new
command/text buttons put things in different places. If you have a cell
that has output, then the evaluate button is between the cell and its
output, and it changes the output. However, you probably don't want a
new cell (command or text) to come between the cell and its output. For
this reason, I don't like lumping these three things together in the
same horizontal space.
Jason
For some reason I do not associate the "where" with the location of
the button. To me it seems more like a menu item e.g. "edit/insert"
which in many applications occurs at the top of the page but affects
something inside. There is some "cursor" or concept of "current cell"
which determines where this happens.
Regards,
Bill Page.
>
> Also (this is now just wild speculation) would it ever be possible to
> make a new math cell *in the middle of a text cell*? That would be
> really awesome, let me tell you. Though perhaps impossible?
Can you give us a more specific use-case? You mean, you want to "split"
a text cell and in the split, make a new math cell?
>
> Similarly, current TinyMCE behavior does not seem to join two existing
> adjacent text cells together - which is not a bug, but just a little
> weird at times. Say for instance you had a math cell between two text
> areas and you delete the math cell; should the text areas join or not
> - or could they even? I feel like Jason addressed this a few months
> ago, but I can't remember any more.
Any adjacent text cells should merge after you close the page and
reopen, or after you click "edit" and then save your changes. So yes,
they will merge, but not immediately.
Jason
+1
If yes, then I agree that this would be very cool.
Of course there may be many different ways/modes in which one can use
the notebook, but here is a possible use-case:
One might start with simply describing the computation that one
intends to do. For that purpose one would just enter a text cell
immediately and start writing. Then some time later you might go back
and begin the actual calculations. Say, at some point in the narrative
you decide you need to define a variable. So you just click
"insert/Sage" and the text box splits, saves and closes both parts
leaving you in a code box between these two sections to enter the
commands. I expect it would be quite normal to iterate in this manner
by double-clicking on the remaining text section that follows the
command to continue revising the text and then at some point split it
again for another computation. That way, the text editing mode becomes
the primary mode for the user, escaping only to perform computations
and/or to save the resulting worksheet.
Regards,
Bill Page.
That is a good idea.
This could be implemented by having a button in the palette on the top to insert
a new "math" cell. The cell itself could just be some special HTML
(maybe with a comment) that gets post-processed by Sage and turned
into an input cell. See the attached "Picture 1" -- that what it
might look like right after one clicks the "insert a new math cell"
button. Then "Picture 2" is what it looks like after one clicks the
save button.
William
My guess is that it would be much easier to implement the earlier
proposal: a ctrl-; or something would split the text cell at the cursor
position and create a new code cell in the middle.
This way, we don't have to duplicate all of the functionality
improvements that are going into code cells, like tab completion, etc.
How about this:
If you are in a text cell:
* ctrl-; splits the text cell, puts in a new math cell, and focuses on
the math cell.
If you are in a math cell:
* ctrl-; splits the math cell, focusing on the second math cell
* ctrl-shift-; splits the math cell, inserts a new text cell between
them, and focuses on the text cell.
I actually find that last case one that comes up often for me. I'm
writing code for my class as a sequence of steps, then I want to explain
it. So I would just go to a place in the code I'd like to put in a
note, press ctrl-shift-;, and type my note.
Jason
In the example given by William the "new math cell" in text mode is
not "live", i.e. it does not contain any actual commands (yet). The
"special HTML" to which William referred is only an empty marker.
After clicking Save from TinyMCE, the cursor is positioned at the
newly created math cell and only then does the user begin to enter
Sage commands. So tab completion, etc. in TinyMCE never arises.
Of course it is tempting to allow commands to be entered instead the
special HTML construct while still in TinyMCE and I think it might
also be tempting (even necessary and desireable?) to allow more than
one such special HTML construct to be inserted before clicking Save.
I suppose that this design proposed by William is at least in part
motivated by some ideas about what might be simple to implement as an
extension of the current code base. But I have to admit that I find it
just a little more "obtuse" for the user. It raises the obvious
question about why actually command input might not be allowed inside
TinyMCE.
>
> How about this:
>
> If you are in a text cell:
> * ctrl-; splits the text cell, puts in a new math cell, and focuses on
> the math cell.
>
> If you are in a math cell:
> * ctrl-; splits the math cell, focusing on the second math cell
> * ctrl-shift-; splits the math cell, inserts a new text cell between
> them, and focuses on the text cell.
>
> I actually find that last case one that comes up often for me. I'm
> writing code for my class as a sequence of steps, then I want to
> explain it. So I would just go to a place in the code I'd like to put
> in a note, press ctrl-shift-;, and type my note.
>
Except for the mysterious ctrl-shift- key combinations, I still like
this idea better. Besides these "hidden" key short-cuts, I presume
that these same functions would be available from a mouse click?
I also like you idea of splitting math cells in an analogous manner!
Regards,
Bill Page.