From barry at python.org Sun Mar 3 19:09:44 2019 From: barry at python.org (Barry Warsaw) Date: Sun, 3 Mar 2019 16:09:44 -0800 Subject: [Python-mode] lean navigation In-Reply-To: <266412f7-4fe3-c457-b10d-7e673ebde0df@online.de> References: <266412f7-4fe3-c457-b10d-7e673ebde0df@online.de> Message-ID: <823A6260-FC09-4AD0-B155-AC76AE9D8A51@python.org> Hi Andreas. Thanks for continuing to work on this library. Honestly, I haven?t noticed any performance problems in a long time. python-mode.el continues to work great for me. -Barry > On Dec 29, 2018, at 03:01, Andreas R?hler wrote: > > Hi all, > > when a class has a large amount of defs inside, jumping to the end of > class might take some noticeable time. (Albeit don't see a bug report so > far.) > > For now, navigating Python source internally is done by > ?py-forward-statement? resp. ?py-backward-statement? - where > ?statement? means just ?section of code starting at its own indent?. > While this seems complete and reliable, it does several checks we > might get rid off in certain circumstances when speed matters. > > For example when jumping to the end from a known block-start, may > reason from the current indentation: any further start lesser/equal > indented can't be part of. > > This makes some assumptions WRT formatting and might fail in case of > uncommon or mixed formats using semicolons for example. As it's about > an editor here and not about a lexer/parser IMO the change might be > worth it. OTOH: how often exist these large classes? > > Maybe have a customizable boolean py-use-speed-navigation-p? > Just a RFC, > > Cheers, > Andreas > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From andreas.roehler at online.de Tue Mar 5 02:04:25 2019 From: andreas.roehler at online.de (=?UTF-8?Q?Andreas_R=c3=b6hler?=) Date: Tue, 5 Mar 2019 08:04:25 +0100 Subject: [Python-mode] lean navigation In-Reply-To: <823A6260-FC09-4AD0-B155-AC76AE9D8A51@python.org> References: <266412f7-4fe3-c457-b10d-7e673ebde0df@online.de> <823A6260-FC09-4AD0-B155-AC76AE9D8A51@python.org> Message-ID: <874a6000-8aa9-b292-eb5e-5ec3af48880e@online.de> On 04.03.19 01:09, Barry Warsaw wrote: > Hi Andreas. Thanks for continuing to work on this library. > Honestly, I haven?t noticed any performance problems in a long time. python-mode.el continues to work great for me. Great. Indeed it should happen only very seldom. > > -Barry > >> On Dec 29, 2018, at 03:01, Andreas R?hler wrote: >> >> Hi all, >> >> when a class has a large amount of defs inside, jumping to the end of >> class might take some noticeable time. (Albeit don't see a bug report so >> far.) >> >> For now, navigating Python source internally is done by >> ?py-forward-statement? resp. ?py-backward-statement? - where >> ?statement? means just ?section of code starting at its own indent?. >> While this seems complete and reliable, it does several checks we >> might get rid off in certain circumstances when speed matters. >> >> For example when jumping to the end from a known block-start, may >> reason from the current indentation: any further start lesser/equal >> indented can't be part of. >> >> This makes some assumptions WRT formatting and might fail in case of >> uncommon or mixed formats using semicolons for example. As it's about >> an editor here and not about a lexer/parser IMO the change might be >> worth it. OTOH: how often exist these large classes? >> >> Maybe have a customizable boolean py-use-speed-navigation-p? >> Just a RFC, >> >> Cheers, >> Andreas >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: