This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: IDLE: Remove FormatParagraph's width setting from config dialog
Type: enhancement Stage: resolved
Components: IDLE Versions: Python 3.4, Python 3.5, Python 2.7
Status: closed Resolution: fixed
Dependencies: 3068 Superseder:
Assigned To: terry.reedy Nosy List: python-dev, taleinat, terry.reedy
Priority: normal Keywords: patch

Created on 2014-02-09 19:28 by taleinat, last changed 2022-04-11 14:57 by admin. This issue is now closed.

File name Uploaded Description Edit
taleinat.20140209.IDLE__Remove_format_paragraph_width_from_config_dialog.patch taleinat, 2014-02-09 19:28 initial patch (against branch 3.3; changeset 3e62c6c3977e) review
formatpara - 20577-34.diff terry.reedy, 2014-06-11 01:46 ready to apply review
formatpara - 20577-34-v2.diff taleinat, 2014-06-14 17:30 review
Messages (20)
msg210779 - (view) Author: Tal Einat (taleinat) * (Python committer) Date: 2014-02-09 19:28
Following up issue3068, this is a separate patch which moves the "paragraph reformat width" setting from the "general" tab in IDLE's config dialog to the relevant place in the extensions configuration.
msg220224 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-06-11 01:46
I updated the patch to match a change, since you posted this, from 70 to 72 in .def and 'maxformatwidth' to ' limit' in formatparagraph. I also added a 'guard' value of 72 in case GetOption returns None (as it did before I changed the option name). I checked that there is no instance of 'para' other than in 'param' in configDialog and ran the tests. I view the attached as ready to commit to 3.4 and merge to 3.5. In 2.7, the patch applies cleanly to the files other that configDialog. The problem there is  frameEncoding stuff in the context that is not present in 3.4 or the patch.  I would just hand edit the 2.7 file to delete the lines again.

Would you like to push this as your first commit?
msg220229 - (view) Author: Tal Einat (taleinat) * (Python committer) Date: 2014-06-11 02:14
Thanks for reviewing this Terry! See two small comments in the review of your patch.

Indeed, I would very much like for this to be my first commit. Thanks for the pointer WRT backporting to 2.7. Just to make sure, I should commit to 3.5 (default) and then backport to 3.4 and 2.7, correct?
msg220230 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-06-11 02:42
Backwards from default was the old, svn way. We hg we merge forward within 3.x. "ready to commit to 3.4 and merge to 3.5.". If you started with 3.5, then you would have to do a null merge of the 3.4 patch into 3.5. It is occasionally done when people decide to backport to maintenacne sometime later, but much nastier.

Feel free to ask any other questions.

Review: pep8, yes!.
msg220245 - (view) Author: Tal Einat (taleinat) * (Python committer) Date: 2014-06-11 08:33
What do you mean with the comment regarding pep8?
msg220281 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-06-11 16:09
"For flowing long blocks of text with fewer structural restrictions (docstrings or comments), the line length should be limited to 72 characters."
msg220286 - (view) Author: Tal Einat (taleinat) * (Python committer) Date: 2014-06-11 16:44
I'll be damned. 72 it is, then.

What about using the 'default' parameter for GetOption() instead of "or 72"?
msg220311 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-06-11 21:22
'yes!' meant please do so.
msg220570 - (view) Author: Tal Einat (taleinat) * (Python committer) Date: 2014-06-14 17:30
With very minor changes (just use default=72 instead of "or 72" and added a comment explaining why 72 is the default - see attached), I ran the entire test suite (which is a must according to the dev guide). On current default I'm getting consistent failures in test_tk and test_ttk_guionly, which don't seem related. At least I know I managed to include the tests which require a GUI.

Can I continue with committing the patch despite these failures? I guess I should report these failures separately?
msg220574 - (view) Author: Tal Einat (taleinat) * (Python committer) Date: 2014-06-14 18:48
Also, this seems like a small change. Should I mention it in Misc/NEWS?
msg220596 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-06-14 23:42
General rule: If the other failures happen without the patch, then go ahead. This is, unfortunately, all too common. If they only happen with the patch (extremely unlikely for this one), then try to find out why.

Yes, this change should have a NEWS item. However, I would not include it with your first patch. On my machine, hg has trouble properly merging changes to NEWS even when there are no real conflicts. I have a couple of other items for committed patches that I intend to push separately very soon and I would include this one if appropriate.
msg221931 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-06-30 01:16
Since you are busy, I am planning to commit this tomorrow so I can review the extension config patch with this in place.
msg221941 - (view) Author: Tal Einat (taleinat) * (Python committer) Date: 2014-06-30 06:05
I've been waiting to commit this for some time. I'd really like to do this myself, if you don't mind.

I'm just waiting for my SSH key to be added, which is taking a long time since apparently all three people who could do so are traveling and unable to help.
msg222717 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-07-11 02:33
Ned's comments on #20580,  msg222714,  reminded me that while each idlelib has its own set of default config files, one set of user files is shared across all installed versions of idle. So we have to be careful about what we do. With this patch, 3.4.2, for instance, could not read the user setting set with 3.4.1. And a setting written by 3.4.2 could not be read by 2.7.8. While I think that is tolerable, let's hold off on this until it is both needed and tested a bit more.
msg222719 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-07-11 03:01
This will at least need a What's New entry, though people do not expect new entries in maintenance releases.  I think we need an Idle What's New accessible from the help menu and announced on the splash screen. Unlike the standard What's New, it will get occasional entries during a release, and that (and PEP 434) explained at the top.
msg222732 - (view) Author: Tal Einat (taleinat) * (Python committer) Date: 2014-07-11 09:12
I don't think this is a major issue. Most users only use one version of IDLE with one version of Python.

IDLE's user config is indeed shared between all versions. This is an unfortunate design mistake, and could perhaps be fixed in 3.5.

Regarding this issue, we could skip 3.4 and include it only in 3.5. I think telling users "fix your IDLE config when switching from 3.4 to 3.5 as so" is reasonable. If we don't allow ourselves this, then without switching to having separate configs for each version of Python, we'll never be able to change anything in IDLE's configuration!
msg222764 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-07-11 16:58
The awkwardness of the config design is that idlelib/config-xyz.def files are separate for each version and shared across users (and systems) while .idlerc/config-xyz.def files are separate for each user (account) and shared across versions on the same machine.  #20580 is about at least using the existing system-specific sections. Ned also suggested the possibility of version-specific systems. Version specific files are also possible: config-xyz-34.def. 

I am willing to also tell users in 2.8.9 and 3.4.2 to reset any custom formatwidth setting. But we need a way to *tell* users that, even for 3.5. I would like to replace the useless "Type "copyright", "credits" or "license()" for more information." with "See HELP/NEWS for information about changes in each release."
msg222765 - (view) Author: Tal Einat (taleinat) * (Python committer) Date: 2014-07-11 17:09
So is that a go-ahead to commit to the 2.7 and 3.4 branches (as well as default)?
msg222786 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-07-11 19:57
What I meant was 'wait until we have an new announcement mechanism', which we very much need anyway, and then apply to all three. And that should have been 'Help/What's New' in the splash announcement. I opened #21961 for this and will try to have a minimal document is a day or so.
msg232725 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2014-12-16 08:22
New changeset 51de0da524b4 by Terry Jan Reedy in branch '2.7':
Issue #20577: move configuration of FormatParagraph extension to new extension

New changeset 3ffa8438d274 by Terry Jan Reedy in branch '3.4':
Issue #20577: move configuration of FormatParagraph extension to new extension
Date User Action Args
2022-04-11 14:57:58adminsetgithub: 64776
2014-12-16 08:37:16terry.reedysetstatus: open -> closed
assignee: terry.reedy
resolution: fixed
stage: commit review -> resolved
2014-12-16 08:22:32python-devsetnosy: + python-dev
messages: + msg232725
2014-10-02 17:32:20terry.reedysetdependencies: + IDLE - Add an extension configuration dialog
2014-07-11 19:57:46terry.reedysetmessages: + msg222786
2014-07-11 17:09:15taleinatsetmessages: + msg222765
2014-07-11 16:58:14terry.reedysetmessages: + msg222764
2014-07-11 09:12:25taleinatsetmessages: + msg222732
2014-07-11 03:01:05terry.reedysetmessages: + msg222719
2014-07-11 02:33:21terry.reedysetmessages: + msg222717
2014-06-30 06:05:41taleinatsetmessages: + msg221941
2014-06-30 01:16:03terry.reedysetmessages: + msg221931
2014-06-14 23:42:24terry.reedysetmessages: + msg220596
2014-06-14 18:48:32taleinatsetmessages: + msg220574
2014-06-14 17:30:49taleinatsetfiles: + formatpara - 20577-34-v2.diff

messages: + msg220570
2014-06-11 21:22:52terry.reedysetmessages: + msg220311
2014-06-11 16:44:02taleinatsetmessages: + msg220286
2014-06-11 16:09:21terry.reedysetmessages: + msg220281
2014-06-11 08:33:29taleinatsetmessages: + msg220245
2014-06-11 02:42:39terry.reedysetmessages: + msg220230
2014-06-11 02:14:19taleinatsetmessages: + msg220229
2014-06-11 01:46:14terry.reedysetfiles: + formatpara - 20577-34.diff

type: enhancement
versions: + Python 2.7, - Python 3.3
nosy: + terry.reedy

messages: + msg220224
stage: commit review
2014-02-09 19:28:36taleinatcreate