Hi,<br><br><div class="gmail_quote">On Sun, Jan 22, 2012 at 10:29 PM, Fernando Perez <span dir="ltr">&lt;<a href="mailto:fperez.net@gmail.com">fperez.net@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi John,<br>
<div class="im"><br>
On Sun, Jan 22, 2012 at 7:11 PM, John Fawcett &lt;<a href="mailto:fawce@quantopian.com">fawce@quantopian.com</a>&gt; wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; I think the long-form edit case is very promising. It borders on full blown<br>
&gt; development, and seems to imply the eventual unification of the cellular<br>
&gt; edit style with the file-oriented style of a typical editor. Is that the<br>
&gt; idea? (Aside: i signed up for <a href="http://c9.io" target="_blank">c9.io</a> based on the Ace editor project, and it<br>
&gt; is the best online IDE I&#39;ve tried - they have tabbed editors btw).<br>
<br>
</div>The way I think about it (and others may disagree) is that I want the<br>
development features that are relevant to interactive-focused<br>
workflows.  In that regard, I don&#39;t focus on competing with tools like<br>
Microsoft&#39;s amazing Visual Studio Python plugin or PyCharm, that do<br>
very impressive amounts of project management and introspection, at<br>
what is surely a high cost of development complexity for their<br>
authors.  So things like sophisticated completion for incomplete<br>
classes (that requires difficult background analysis of code as it&#39;s<br>
typed) or multi-file refactoring are well outside of our scope.<br>
<br>
But while working interactively on code/data problems, I do want solid<br>
editing support.  For years many of us have worked with $EDITOR +<br>
ipython-terminal for this class of problems, but with the notebook<br>
moving us closer to the browse full-time, I also want an editing<br>
experience that is as close to that of a full-time editor as is<br>
reasonable given our resources.  Basically I don&#39;t want an editor that<br>
I curse at while I work if I&#39;m in a browser working remotely and<br>
firing up an editor local to the files is impractical/impossible.<br>
<div class="im"><br></div></blockquote><div>This makes a lot of sense to me. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
&gt; - I tried selecting a block in a cell, and it seemed like tab did indent,<br>
&gt; and shift-tab de-indented. Is that what you meant by indentation support?<br>
<br>
</div>Yes, but for me it doesn&#39;t work correctly. On Firefox 9 neither indent<br>
nor dedent work correctly, as only some lines get indented (meaning<br>
the code gets mangled). On Chrome only indent seems to work.  On this<br>
front, Ace works fine.</blockquote><div><br></div><div>Both CM and Ace are working for me in Chrome with indent and dedent, but sounds like Ace wins on this point. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
&gt; - the total lack of docstring support in CM is annoying, maybe it is<br>
&gt; feasible to patch CM to support it properly?<br>
<br>
</div>Certainly an option, the question is, given our limited resources,<br>
whether it&#39;s worth our time instead of just using Ace (which handles<br>
this right).  Obviously having two editors has its own issues, so it&#39;s<br>
a valid question.<br>
<div class="im"><br>
&gt; - CM has a decent demo of search/replace, that I think is as good as Ace:<br>
&gt; <a href="http://codemirror.net/demo/search.html" target="_blank">http://codemirror.net/demo/search.html</a><br>
<br>
</div>That looks pretty decent, I seem to remember trying it a while ago and<br>
finding it much poorer; perhaps they&#39;ve improved recently.  I would<br>
want that to be available in *all* cells all the time, actually!<br></blockquote><div><br></div><div>definitely!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
&gt; My free advice (which is worth what you pay for it :) ) is to aim to have<br>
&gt; one editor for cell and long-form editing. It seems like getting the<br>
&gt; docstring and indentation support in CM would have to be compared to getting<br>
&gt; Ace to support multiple editors on one page.<br>
<br>
</div>I *think* for Ace, the hundreds-of-editors option isn&#39;t very<br>
realistic, or would at least require a fairly large restructuring of<br>
their code b/c that&#39;s a use case that is very far from their original<br>
design intention.  So the question is probably more whether we can<br>
make CM fill all our needs, or find a good way to live with both that<br>
is as seamless as possible for the users.<br>
<br></blockquote><div><br></div><div>Yup, good point.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I agree that having only one editor to deal with would be the ideal<br>
solution all around, both easier for IPython developers and users.<br>
Perhaps as both Ace and CM mature one of them will fit that bill.<br>
Thanks for the thoughtful feedback!<br>
<br></blockquote><div><br></div><div>Thanks for taking the time to reply!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
<br>
f<br>
</blockquote></div><br>