Here's the circumstances that brought this up. I was helping a new programming student walk through some example code, having him both type manually as well as copy + paste from the site and we would talk it over.
When it came time to run the module, we ran into a few typos, a few indentation errors, a capitalization error, no problem, easy fixes. But the script kept failing on two points: one, it claimed that we were using non-ascii and needed to declare the file as UTF-8. Two, it continued to say there was an indentation error after we'd checked it closely. I eventually exported the file to vim, but there were no indentation problems. What we ended up doing, was to delete the offending line and type it manually on a new line. This ended up being much more complicated than it needed to be, in my opinion. A big reason why I enjoy Python is the emphasis on simplicity. We were trying to do a simple task. I think IDLE could add value here by providing convenience features to get a script back to a simple state, both by fixing indentation as well as resetting to a dead-simple charset, do deal with things like accented characters or stylized curly-quotes. Simple is good and I think IDLE could help simplify here. That's the overall intent of my suggestions. On Thu, Mar 27, 2014 at 5:00 PM, Terry Reedy <tjre...@udel.edu> wrote: > On 3/27/2014 1:10 AM, Sean Felipe Wolfe wrote: >> >> Hey everybody, >> >> I was working with a new programmer today and ran into a couple issues >> which I'd love to see IDLE be able to address: >> >> 1) non-asciii charcters: Strip all non-ascii characters. I've found >> copy/paste on sample code from a website, sometimes picks up spurious >> non-ascii bits. > > > The problem I have had is spurious ascii chars, such as line #s or prompts. > There is a proposal for an option to auto-strip '>>>' and '...' prompts. I > would like a way to strip line numbers in text lines. There is a separate > proposal to add line #s *beside* but not in text lines. > > In Py 3, Python code *is* unicode, so non-ascii chars may be an essential > part of the code. If copying picks up non-code, it seems to me that this > would be the fault of the user selection, the presentation format making > selection of only code impossible (as with the Idle shell and some > line-numbered windows), the browser, or the website. What case are you > referring to? > > Also, see below. > > >> It would be great to have a pull-down menu function >> >> which forces the script to save only ascii and discard the rest. > > > If you mean save to disk, that would be wrong. Modifying text in an edit > window should be separate from saving. > > >> Maybe there is already a way to do this? > > > I am sure not. > > >> 2) Fix indentation: it would be great to have the equivalent of vim's >> "gg=G" sequence to automatically fix indentation issues. > > > How do you expect a non-vim user to have any idea what you mean? > > >> I thought we had this already actually? > > > There are indent related options on the preference dialog and editor format > menu. Without knowing what you want ... > > There is a proposal to add a generic extension that could run 3rd party code > analyzers on the contents of an edit window and display results in an output > window. Your post suggests that a useful (and simpler) enhancement would be > a generic way to apply a line-transformation function to all the lines of a > block (default = whole file). All the options listed on the editor format > menu (except reformat paragraph) fit the following pattern. (I believe the > ones that do not say 'region' only modify the whole file.) > > def replace_lines(func, file_slice) > for line in file_slice: > <replace line with func(line)> > > I believe both of your requests also fit this pattern. > > I do not know whether any of the existing functions use a common loop like > the above, but the visible enhancement would be to load funcs from a file > that users can edit. Then users like you could extend Idle simply by adding > line transformation functions that do exactly what you want, without waiting > for someone like be to be persuaded to add it and without writing a > full-blown extension like idlelib/FormatParagraph.py, which is much harder > than writing just the transform function. This would be much more powerful > than adding a macro recording facility. > > Such an enhancement should also make it easy to bring up an argument input > box, such as with Format / Tabify Region. > > -- > Terry Jan Reedy > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev@python.org > https://mail.python.org/mailman/listinfo/idle-dev -- A musician must make music, an artist must paint, a poet must write, if he is to be ultimately at peace with himself. - Abraham Maslow _______________________________________________ IDLE-dev mailing list IDLE-dev@python.org https://mail.python.org/mailman/listinfo/idle-dev
