Re: simplifying beginning-of-defun

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> 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