From andreas.roehler at online.de Fri Aug 2 08:02:12 2019 From: andreas.roehler at online.de (=?UTF-8?Q?Andreas_R=c3=b6hler?=) Date: Fri, 2 Aug 2019 14:02:12 +0200 Subject: [Python-mode] Fwd: Simplifying python-mode.el In-Reply-To: <5E71F3A5-8238-4D8F-AF6C-F2416E8EF888@python.org> References: <341c849a-3338-6018-203f-c98b5af13b7b@online.de> <3dc7ab00-b91e-bcd5-a4a9-24edb3e08bbd@online.de> <5E71F3A5-8238-4D8F-AF6C-F2416E8EF888@python.org> Message-ID: <1e1281a1-dbb8-cda4-2151-ca55b12ea069@online.de> Hi Barry, didn't see your post earlier, sorry for the delay. No, stuff you mentioned will remain. It's only about the switch/no-switch split/no-split fine-grained commands. IMO splitting and switching are ruled better by setting these two options instead of breeding out a myriad of commands. Cheers, Andreas On 16.07.19 00:23, Barry Warsaw wrote: > I personally only tend to use py-execute-region (C-c |) and py-execute-buffer (C-c C-c). Are you proposing to change or remove those? > > -Barry > >> On Jul 13, 2019, at 23:16, Andreas R?hler wrote: >> >> -------- Forwarded Message -------- >> Subject: Simplifying python-mode.el >> Date: Sat, 13 Jul 2019 09:56:32 +0200 >> From: Andreas R?hler >> To: Barry Warsaw >> >> >> Hi Barry, hi all, >> >> consider to reduce the amount of commands starting with `py-execute-...` >> >> Such things like py-execute-block-ipython-dedicated-switch. >> >> It would remain >> >> py-execute-block-ipython >> >> running in dedicated buffer when called with C-u >> >> For switch and split options there are already >> >> py-switch-buffers-on-execute-p and >> >> py-split-window-on-execute >> >> Just FYI. >> >> Any objections? >> >> Cheers, >> >> >> Andreas >> >> >> >> >> _______________________________________________ >> Python-mode mailing list >> Python-mode at python.org >> https://mail.python.org/mailman/listinfo/python-mode From andreas.roehler at online.de Fri Aug 2 08:08:20 2019 From: andreas.roehler at online.de (=?UTF-8?Q?Andreas_R=c3=b6hler?=) Date: Fri, 2 Aug 2019 14:08:20 +0200 Subject: [Python-mode] python-mode.el partial rewrite In-Reply-To: <6B2194E5-B387-4745-B27F-0F4051F5D256@python.org> References:

<28e70af3-a744-4ccf-05c7-a51acf7d639a@online.de> <6B2194E5-B387-4745-B27F-0F4051F5D256@python.org> Message-ID: On 16.07.19 00:45, Barry Warsaw wrote: > Hi Andreas, > > I don?t have any strong opinions, except that I do use python-mode.el in a kind of weird way. I never byte compile it, always loading from the .el in my emacs init files. That's fine. So I do, but for a different reason: Byte-compiled files are not compatible between versions of Emacs, while sources are to great extent. BTW that change is checked in already. Shouldn't make any difference for users. > I got into this habit ages ago when VCSes couldn?t automatically byte compile files when you updated your local repos (and Emacs .elc files aren?t like Python?s .pyc files, since they don?t get auto-generated when the .el file is newer). > > -Barry > >> On Jul 12, 2019, at 00:09, Andreas R?hler wrote: >> >> Thanks Barry, >> >> next question: >> >> we have a lot of commands which are convenient occasionally, however most of them will never be used but take a lot of space. To make the core of python-mode.el readable again think to construct it on the fly according to something like >> >> (defcustom py-known-shells >> (list "ipython" >> "ipython2.7" >> "ipython3" >> "jython" >> "python" >> "python2" >> "python3" >> "pypy" >> ) >> "A list of available shells instrumented for commands. >> Expects its executables installed"))... >> >> This list might be shrink or extended at will. >> >> Two backsides: a slightly larger loading time and source of callers like ?py-execute-section-ipython3? will not be visible for users. >> >> WDYT? Any objections? >> >> Cheers, >> >> Andreas >> >> >> >> >> On 11.07.19 23:22, Barry Warsaw wrote: >>> Great, thanks for all your great work on the module. I?ve updated to 639532b and will play with this for a while. >>> >>> -Barry >>> >>>> On Jul 10, 2019, at 01:14, Andreas R?hler wrote: >>>> >>>> Hi Barry, hi all, >>>> >>>> should have fixed IPython completion and fontification, also #31, >>>> >>>> which caused some changes. Maybe check it out. >>>> >>>> Cheers, >>>> >>>> Andreas >>>> >>>>