From andrea.crotti.0 at gmail.com Mon Mar 9 18:26:22 2015 From: andrea.crotti.0 at gmail.com (andrea crotti) Date: Mon, 9 Mar 2015 17:26:22 +0000 Subject: [Python-mode] Python help buffer In-Reply-To: References: <54AD278F.4090203@online.de> <54AD8B90.2060004@online.de> Message-ID: Hi again Andreas and all. I'm still having this issue with the documentation buffer popping up all the time.. I'm using now python-mode version: python-mode-20150221.1223/ from Melpa. So doing the dirty trick (defun py-help-at-point nil) kind of works but now causes other issues, so I'd rather just fix it once for all. I've been trying to understand how that function is triggered in the first place but can't find it, and it must be something different between Emacs 24 and Emacs 25 because it doesn't happen on the 24.. Any idea where to look for? 2015-01-07 19:48 GMT+00:00 andrea crotti : > 2015-01-07 19:40 GMT+00:00 Andreas R?hler : >> On 07.01.2015 18:50, andrea crotti wrote: >>> >>> 2015-01-07 12:33 GMT+00:00 Andreas R?hler : >>>> >>>> Hi Andrea, >>>> >>>> From Emacs -Q, loading python-mode.el by hand, does it still happen? >>>> >>>> Andreas >>>> >>> >>> I realised to my surprise that I was not actually using the version >>> from ELPA but a version in my disk. >>> Anyway I now downloaded from ELPA (marmalade) 6.13 started Emacs 25 >>> with -Q and evaluated manually the python-mode.el buffer. >>> >>> It still happens, so I bet the problem is something with Emacs 25 that >>> auto call something that didn't use to call before? >>> >> >> It would really make sense to check with emacs -Q, load python-mode.el, open >> some .py file. >> > > Yes sorry maybe I was not clear, I've done exactly that and it still happens.. From andreas.roehler at online.de Tue Mar 10 09:22:41 2015 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Tue, 10 Mar 2015 09:22:41 +0100 Subject: [Python-mode] Python help buffer In-Reply-To: References: <54AD278F.4090203@online.de> <54AD8B90.2060004@online.de> Message-ID: <54FEA9D1.1020301@online.de> On 09.03.2015 18:26, andrea crotti wrote: > Hi again Andreas and all. > I'm still having this issue with the documentation buffer popping up > all the time.. > I'm using now python-mode version: > python-mode-20150221.1223/ > from Melpa. > > So doing the dirty trick (defun py-help-at-point nil) kind of works > but now causes other issues, so I'd rather just fix it once for all. > > I've been trying to understand how that function is triggered in the > first place but can't find it, and it must be something different > between Emacs 24 and Emacs 25 because it doesn't happen on the 24.. Hi Andrea, this rather indicates a bug in Emacs25. Any reason to use the bleeding edge? BTW latest pretest 24.4.91.1 runs nicely here. Cheers From andrea.crotti.0 at gmail.com Wed Mar 11 20:41:25 2015 From: andrea.crotti.0 at gmail.com (andrea crotti) Date: Wed, 11 Mar 2015 19:41:25 +0000 Subject: [Python-mode] Python help buffer In-Reply-To: <54FEA9D1.1020301@online.de> References: <54AD278F.4090203@online.de> <54AD8B90.2060004@online.de> <54FEA9D1.1020301@online.de> Message-ID: 2015-03-10 8:22 GMT+00:00 Andreas R?hler : > On 09.03.2015 18:26, andrea crotti wrote: >> >> Hi again Andreas and all. >> I'm still having this issue with the documentation buffer popping up >> all the time.. >> I'm using now python-mode version: >> python-mode-20150221.1223/ >> from Melpa. >> >> So doing the dirty trick (defun py-help-at-point nil) kind of works >> but now causes other issues, so I'd rather just fix it once for all. >> >> I've been trying to understand how that function is triggered in the >> first place but can't find it, and it must be something different >> between Emacs 24 and Emacs 25 because it doesn't happen on the 24.. > > > Hi Andrea, > > this rather indicates a bug in Emacs25. Any reason to use the bleeding edge? > BTW latest pretest 24.4.91.1 runs nicely here. > > > Cheers Well there are some nice things in Emacs25 that I like (like improved rectangular editing) but I'm also fine with Emacs 24. However it might be also a combination of changes in Emacs25 and python-mode imho, this issue has been there for a long time it sounds strange that it's just an Emacs bug.. I would report a bug to Emacs but I can't understand for the life of me how this thing is triggered in the first place, I can write an email to the mailing list there and see what they say. From andreas.roehler at online.de Thu Mar 12 09:07:34 2015 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Thu, 12 Mar 2015 09:07:34 +0100 Subject: [Python-mode] Python help buffer In-Reply-To: References: <54AD278F.4090203@online.de> <54AD8B90.2060004@online.de> <54FEA9D1.1020301@online.de> Message-ID: <55014946.6030201@online.de> On 11.03.2015 20:41, andrea crotti wrote: > Well there are some nice things in Emacs25 that I like (like improved > rectangular editing) Understand. [ ... ] Maybe eldoc-mode is t? Try (eldoc-mode -1) From andreas.roehler at online.de Fri Mar 13 15:51:15 2015 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Fri, 13 Mar 2015 15:51:15 +0100 Subject: [Python-mode] Displaying symbols in customization buffer Message-ID: <5502F963.8090205@online.de> Hi Barry, hi all, currently most of symbols in customization buffer get splitted, resulting parts are capitalized. Would prefer to display it with real name, which permits searching it. Any opinion about that? Cheers, Andreas From barry at python.org Fri Mar 13 18:16:57 2015 From: barry at python.org (Barry Warsaw) Date: Fri, 13 Mar 2015 13:16:57 -0400 Subject: [Python-mode] Displaying symbols in customization buffer In-Reply-To: <5502F963.8090205@online.de> References: <5502F963.8090205@online.de> Message-ID: <20150313131657.31b1e232@marathon> On Mar 13, 2015, at 03:51 PM, Andreas R?hler wrote: >currently most of symbols in customization buffer get splitted, resulting parts are capitalized. > >Would prefer to display it with real name, which permits searching it. > >Any opinion about that? Isn't that just how customize works in Emacs? Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From barry at python.org Fri Mar 13 22:16:48 2015 From: barry at python.org (Barry Warsaw) Date: Fri, 13 Mar 2015 17:16:48 -0400 Subject: [Python-mode] Displaying symbols in customization buffer In-Reply-To: <5503324C.4090001@easy-emacs.de> References: <5502F963.8090205@online.de> <20150313131657.31b1e232@marathon> <5503324C.4090001@easy-emacs.de> Message-ID: <20150313171648.430dc982@marathon> On Mar 13, 2015, at 07:54 PM, Andreas R?hler wrote: >Currently it looks strange - see attachment. Agreed, but what can python-mode do about that? It's just the way Emacs' customize feature works. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From andreas.roehler at easy-emacs.de Fri Mar 13 22:37:46 2015 From: andreas.roehler at easy-emacs.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Fri, 13 Mar 2015 22:37:46 +0100 Subject: [Python-mode] Displaying symbols in customization buffer In-Reply-To: <20150313171648.430dc982@marathon> References: <5502F963.8090205@online.de> <20150313131657.31b1e232@marathon> <5503324C.4090001@easy-emacs.de> <20150313171648.430dc982@marathon> Message-ID: <550358AA.3080200@easy-emacs.de> On 13.03.2015 22:16, Barry Warsaw wrote: > On Mar 13, 2015, at 07:54 PM, Andreas R?hler wrote: > >> Currently it looks strange - see attachment. > > Agreed, but what can python-mode do about that? writing something like :tag "my-correct-py-symbol-name" in defcustom Cheers, Andreas From barry at python.org Fri Mar 13 22:36:41 2015 From: barry at python.org (Barry Warsaw) Date: Fri, 13 Mar 2015 17:36:41 -0400 Subject: [Python-mode] Displaying symbols in customization buffer In-Reply-To: <550358AA.3080200@easy-emacs.de> References: <5502F963.8090205@online.de> <20150313131657.31b1e232@marathon> <5503324C.4090001@easy-emacs.de> <20150313171648.430dc982@marathon> <550358AA.3080200@easy-emacs.de> Message-ID: <20150313173641.50071020@marathon> On Mar 13, 2015, at 10:37 PM, Andreas R?hler wrote: >writing something like > >:tag "my-correct-py-symbol-name" > >in defcustom I kind of wish Emacs did this by default, but that's a different discussion for a different forum. ;) Is it more helpful to python-mode users to add the tag or more confusing to Emacs users to see different behavior? It's up to you for Python mode! Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From andreas.roehler at easy-emacs.de Sat Mar 14 10:38:15 2015 From: andreas.roehler at easy-emacs.de (=?windows-1252?Q?Andreas_R=F6hler?=) Date: Sat, 14 Mar 2015 10:38:15 +0100 Subject: [Python-mode] Displaying symbols in customization buffer In-Reply-To: <20150313173641.50071020@marathon> References: <5502F963.8090205@online.de> <20150313131657.31b1e232@marathon> <5503324C.4090001@easy-emacs.de> <20150313171648.430dc982@marathon> <550358AA.3080200@easy-emacs.de> <20150313173641.50071020@marathon> Message-ID: <55040187.2060609@easy-emacs.de> On 13.03.2015 22:36, Barry Warsaw wrote: > On Mar 13, 2015, at 10:37 PM, Andreas R?hler wrote: > >> writing something like >> >> :tag "my-correct-py-symbol-name" >> >> in defcustom > > I kind of wish Emacs did this by default, but that's a different discussion > for a different forum. ;) > > Is it more helpful to python-mode users to add the tag or more confusing to > Emacs users to see different behavior? It's up to you for Python mode! > Hmm, you seem not that much convinced. Well, for me it's slightly confusing to see this capitalized split, which I must reconstruct into the original name in order to understand which one is at stake. Anyway, there is no hurry for this. BTW consider to reduce the number of customizations, replace some by defvar. Notably for handing-over string-codes, setup-codes, like py-eldoc-string-code does. Users being confident to change this will know about setq. Cheers, Andreas From barry at python.org Sat Mar 14 16:14:36 2015 From: barry at python.org (Barry Warsaw) Date: Sat, 14 Mar 2015 11:14:36 -0400 Subject: [Python-mode] Displaying symbols in customization buffer In-Reply-To: <55040187.2060609@easy-emacs.de> References: <5502F963.8090205@online.de> <20150313131657.31b1e232@marathon> <5503324C.4090001@easy-emacs.de> <20150313171648.430dc982@marathon> <550358AA.3080200@easy-emacs.de> <20150313173641.50071020@marathon> <55040187.2060609@easy-emacs.de> Message-ID: <20150314111436.60a66b05@limelight.wooz.org> On Mar 14, 2015, at 10:38 AM, Andreas R?hler wrote: >Hmm, you seem not that much convinced. Well, for me it's slightly confusing >to see this capitalized split, which I must reconstruct into the original >name in order to understand which one is at stake. It's not so much unconvinced as it is whether it's worth it to fix it in python-mode, when it's an Emacs feature. I really don't like it in *any* customize buffers, but I think it might be too weird to see it displayed nicer only in python-mode. Better I think to push a fix (or option?) upstream. >BTW consider to reduce the number of customizations, replace some by defvar. >Notably for handing-over string-codes, setup-codes, like py-eldoc-string-code >does. Users being confident to change this will know about setq. It probably does make sense to audit the knobs and see which ones are really useful for customizing. Or maybe split them into groups which I've seen in other modes. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From andreas.roehler at online.de Sat Mar 14 18:42:18 2015 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Sat, 14 Mar 2015 18:42:18 +0100 Subject: [Python-mode] Displaying symbols in customization buffer In-Reply-To: <20150314111436.60a66b05@limelight.wooz.org> References: <5502F963.8090205@online.de> <20150313131657.31b1e232@marathon> <5503324C.4090001@easy-emacs.de> <20150313171648.430dc982@marathon> <550358AA.3080200@easy-emacs.de> <20150313173641.50071020@marathon> <55040187.2060609@easy-emacs.de> <20150314111436.60a66b05@limelight.wooz.org> Message-ID: <550472FA.1070708@online.de> On 14.03.2015 16:14, Barry Warsaw wrote: > On Mar 14, 2015, at 10:38 AM, Andreas R?hler wrote: > >> Hmm, you seem not that much convinced. Well, for me it's slightly confusing >> to see this capitalized split, which I must reconstruct into the original >> name in order to understand which one is at stake. > > It's not so much unconvinced as it is whether it's worth it to fix it in > python-mode, when it's an Emacs feature. I really don't like it in *any* > customize buffers, but I think it might be too weird to see it displayed nicer > only in python-mode. Better I think to push a fix (or option?) upstream. > I'm afraid there are more serious issues worth raising upstream. Beside the matter doesn't show up that much in core, as splitting the prefix doesn't happen there. Also when choosing long self-explaining names, it turns bad. Will change it for convenience. Just wanted to ask first - as people tend to feel unhappy should something look different :) Best, Andreas From andreas.roehler at online.de Sun Mar 15 09:30:45 2015 From: andreas.roehler at online.de (=?windows-1252?Q?Andreas_R=F6hler?=) Date: Sun, 15 Mar 2015 09:30:45 +0100 Subject: [Python-mode] Displaying symbols in customization buffer In-Reply-To: <20150314111436.60a66b05@limelight.wooz.org> References: <5502F963.8090205@online.de> <20150313131657.31b1e232@marathon> <5503324C.4090001@easy-emacs.de> <20150313171648.430dc982@marathon> <550358AA.3080200@easy-emacs.de> <20150313173641.50071020@marathon> <55040187.2060609@easy-emacs.de> <20150314111436.60a66b05@limelight.wooz.org> Message-ID: <55054335.7040302@online.de> On 14.03.2015 16:14, Barry Warsaw wrote: [ ...] It probably does make sense to audit the knobs and see which ones are really > useful for customizing. Done. Cheers, Andreas