>>> simplifying forms as below should ease maintenance and speed up execution. >> To what extent does it preserve compatibility? > Don't see anything incompatible for the moment.
I actually mentionned obvious incompatibilities in the email to which you reply. > With `beginning-of-defun-function', > `end-of-defun-function' python-mode for example > https://launchpad.net/python-mode > may set its own function and M-x beginning-of-defun then > will work still - which is not the case presently and my point of > depart here. I do not understand the above paragraph. >> Apparently it makes beginning-of-defun-raw ignore >> beginning-of-defun-function, and it calls end-of-defun-function with one >> argument contrary to the current situation where it's called without >> any argument. > An argument is useful here: as a repeat or specifier. I was pointing out incompatibilities. Also the current way end-of-defun-function is defined, it does not need a repeat because it only jumps from the beginning of a defun to its end (i.e. it doesn't do the same as end-of-defun). >> Which performance problem is it trying to solve? > All which useless code execution causes. > Regard the lines of code saved that way to have an approximation. This is much too general: OT1H it's not true (larger code is not necessarily slower), OTOH (and more importantly) it doesn't help me understand which specific performance problem this is aiming to address. > open-paren-in-column-0-is-defun-start is purely redundant, as the > regexp may specify that - and indeed does already(?) its just that > what I read with "^\\s(" Again, please move this discussion to a separate thread. > Mentioned code of a end-of-defun-function in lisp.el is a bug. > Suggest to cancel it. I do not know which code nor which bug you talking about. Your code? Emacs's code? > Let the -raw functions do everything needed for emacs-lisp. AFAICT, that's already the way it's designed (that's why it doesn't set the mark, for example). > Funcalls of beginning-of-defun-function, end-of-defun-function should > be reserved for progmodes. I have no idea what you mean by "progmodes". > BTW if mode-specific, probably it should be introduced as a local var > from the very beginning? I'm not sure I understand. Are you suggesting we (make-varible-buffer-local 'beginning-of-defun-function)? Stefan _______________________________________________ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
