beginning-of-defun (again)

beginning-of-defun (again)

[Andreas Röhler]

  Hi guys,

maybe it's time to have a reasonable default-behavior of 
beginning-of-defun in Emacs Lisp.

IMO there is no reason for stuff like

open-paren-in-column-0-is-defun-start

A function resp. top-level-form starts if the beginning of a list is 
followed by a respective keyword.
The list of keywords being customizable seems a plus :)

Cheers,

Andreas

Re: beginning-of-defun (again)

[Oleh Krehel]

Hi Andreas,

Andreas Röhler <andreas.roehler@online.de> writes:

> maybe it's time to have a reasonable default-behavior of
> beginning-of-defun in Emacs Lisp.

I think it works pretty well as is.

> open-paren-in-column-0-is-defun-start

It's a strange variable that doesn't seem to do anything.  The only
relevant setting is 0 or non-zero (the default). Setting it to 0 seems
to do nothing. Maybe someone could explain what it actually does.

> A function resp. top-level-form starts if the beginning of a list is
> followed by a respective keyword.
> The list of keywords being customizable seems a plus :)

There's no reason for a defun to not start on a newline.  And there's
nothing else that makes "(" be on a new line, except for rare cases in
docstrings, where it can be escaped.  So it seems that the problem is
already solved in a good way, without having to customize anything.

    Oleh

Re: beginning-of-defun (again)

[David Kastrup]

Oleh Krehel <ohwoeowho@gmail.com> writes:

> Hi Andreas,
>
> Andreas Röhler <andreas.roehler@online.de> writes:
>
>> maybe it's time to have a reasonable default-behavior of
>> beginning-of-defun in Emacs Lisp.
>
> I think it works pretty well as is.
>
>> open-paren-in-column-0-is-defun-start
>
> It's a strange variable that doesn't seem to do anything.

Huh?

> The only relevant setting is 0 or non-zero (the default).

Huh?!?  The only relevant settings are nil and non-nil.

> Setting it to 0 seems to do nothing. Maybe someone could explain what
> it actually does.

Speeds up syntax highlighting by giving it anchor points.  If you
encounter

(

in a file, that counts as the start of some list even without looking
whether it might be part of something like

   "This is a string and it continues
(on the next line..."

or

(list
(missing-indentation

or something like that.

>> A function resp. top-level-form starts if the beginning of a list is
>> followed by a respective keyword.
>> The list of keywords being customizable seems a plus :)
>
> There's no reason for a defun to not start on a newline.

But there's a reason for non-defuns to start on a newline.

> And there's nothing else that makes "(" be on a new line, except for
> rare cases in docstrings, where it can be escaped.

In Elisp perhaps, but that variable is equally valid in Scheme.  And
rewrapping a comment string might move a ( to the start of a line
without auto-escaping it in the process.  Though the frequency of this
happening to me when editing Scheme files has decreased to a degree
where I suspect Emacs to be actively avoiding it these days.

> So it seems that the problem is already solved in a good way, without
> having to customize anything.

-- 
David Kastrup

Re: beginning-of-defun (again)

[Oleh Krehel]

David Kastrup <dak@gnu.org> writes:

> Oleh Krehel <ohwoeowho@gmail.com> writes:
>
>> Hi Andreas,
>>
>> Andreas Röhler <andreas.roehler@online.de> writes:
>>
>>> maybe it's time to have a reasonable default-behavior of
>>> beginning-of-defun in Emacs Lisp.
>>
>> I think it works pretty well as is.
>>
>>> open-paren-in-column-0-is-defun-start
>>
>> It's a strange variable that doesn't seem to do anything.
>
> Huh?

Please give an example then. I'm not able to see a difference when it's
unset.

>> The only relevant setting is 0 or non-zero (the default).
>
> Huh?!?  The only relevant settings are nil and non-nil.

The only relevant use is:

  if (!open_paren_in_column_0_is_defun_start)
    {
      find_start_value = BEGV;
      find_start_value_byte = BEGV_BYTE;
      goto found;
    }

Note that it's not checked against Qnil. It may be that Qnil is
conveniently defined to be 0 though, I'm not sure.

> Speeds up syntax highlighting by giving it anchor points.  If you
> encounter
>
> (
>
> in a file, that counts as the start of some list even without looking
> whether it might be part of something like

I see. I wonder what the speed-up factor is. For example in org.el.

>>> A function resp. top-level-form starts if the beginning of a list is
>>> followed by a respective keyword.
>>> The list of keywords being customizable seems a plus :)
>>
>> There's no reason for a defun to not start on a newline.
>
> But there's a reason for non-defuns to start on a newline.

I call these defuns anyway.

Re: beginning-of-defun (again)

[David Kastrup]

Oleh Krehel <ohwoeowho@gmail.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Oleh Krehel <ohwoeowho@gmail.com> writes:
>>
>>> Hi Andreas,
>>>
>>> Andreas Röhler <andreas.roehler@online.de> writes:
>>>
>>>> maybe it's time to have a reasonable default-behavior of
>>>> beginning-of-defun in Emacs Lisp.
>>>
>>> I think it works pretty well as is.
>>>
>>>> open-paren-in-column-0-is-defun-start
>>>
>>> It's a strange variable that doesn't seem to do anything.
>>
>> Huh?
>
> Please give an example then. I'm not able to see a difference when it's
> unset.
>
>>> The only relevant setting is 0 or non-zero (the default).
>>
>> Huh?!?  The only relevant settings are nil and non-nil.
>
> The only relevant use is:
>
>   if (!open_paren_in_column_0_is_defun_start)
>     {
>       find_start_value = BEGV;
>       find_start_value_byte = BEGV_BYTE;
>       goto found;
>     }
>
> Note that it's not checked against Qnil. It may be that Qnil is
> conveniently defined to be 0 though, I'm not sure.

open_paren_in_column_0_is_defun_start is a C variable.  You were talking
about open-paren-in-column-0-is-defun-start which is a Lisp variable.
It is defined using DEFVAR_BOOL:

    @code{DEFVAR_BOOL} makes a C variable of type @code{int} visible in
    Lisp with a value that is either @code{t} or @code{nil}.  Note that
    variables defined with @code{DEFVAR_BOOL} are automatically added to
    the list @code{byte-boolean-vars} used by the byte compiler.

>> Speeds up syntax highlighting by giving it anchor points.  If you
>> encounter
>>
>> (
>>
>> in a file, that counts as the start of some list even without looking
>> whether it might be part of something like
>
> I see. I wonder what the speed-up factor is.

Can be significant depending on the file.

> For example in org.el.
>
>>>> A function resp. top-level-form starts if the beginning of a list is
>>>> followed by a respective keyword.
>>>> The list of keywords being customizable seems a plus :)
>>>
>>> There's no reason for a defun to not start on a newline.
>>
>> But there's a reason for non-defuns to start on a newline.
>
> I call these defuns anyway.

Then you should be happy with the default setting.

-- 
David Kastrup

Re: beginning-of-defun (again)

[David Kastrup]

Oleh Krehel <ohwoeowho@gmail.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Oleh Krehel <ohwoeowho@gmail.com> writes:
>>
>>> Hi Andreas,
>>>
>>> Andreas Röhler <andreas.roehler@online.de> writes:
>>>
>>>> maybe it's time to have a reasonable default-behavior of
>>>> beginning-of-defun in Emacs Lisp.
>>>
>>> I think it works pretty well as is.
>>>
>>>> open-paren-in-column-0-is-defun-start
>>>
>>> It's a strange variable that doesn't seem to do anything.
>>
>> Huh?
>
> Please give an example then. I'm not able to see a difference when it's
> unset.

<URL:http://git.savannah.gnu.org/cgit/lilypond.git/commit/scm/define-grob-properties.scm?id=51172615f31aa2af30c0343b92f1cc372ef0ce91>

This is a Scheme file containing a large structure with multiline
strings.  Occasionally when working with this file, I have to reformat
strings which happened to have "(" after a newline after other people
worked on the file, in order to keep Emacs from misinterpreting the
context.  Such misinterpretation looks ugly in fontification and is a
real nuisance if you want to add several lines of new material and have
Emacs indent it since Emacs will not indent within "strings" (and when
it lost count of "..." pairs, that means everywhere where you'd want
it).

-- 
David Kastrup

Re: beginning-of-defun (again)

[Andreas Röhler]

  On 29.10.2015 14:47, David Kastrup wrote:
> Oleh Krehel<ohwoeowho@gmail.com>  writes:
>
>> David Kastrup<dak@gnu.org>  writes:
>>
>>> Oleh Krehel<ohwoeowho@gmail.com>  writes:
>>>
>>>> Hi Andreas,
>>>>
>>>> Andreas Röhler<andreas.roehler@online.de>  writes:
>>>>
>>>>> maybe it's time to have a reasonable default-behavior of
>>>>> beginning-of-defun in Emacs Lisp.
>>>> I think it works pretty well as is.
>>>>
>>>>> open-paren-in-column-0-is-defun-start
>>>> It's a strange variable that doesn't seem to do anything.
>>> Huh?
>> Please give an example then. I'm not able to see a difference when it's
>> unset.
> <URL:http://git.savannah.gnu.org/cgit/lilypond.git/commit/scm/define-grob-properties.scm?id=51172615f31aa2af30c0343b92f1cc372ef0ce91>
>
> This is a Scheme file containing a large structure with multiline
> strings.  Occasionally when working with this file, I have to reformat
> strings which happened to have "(" after a newline after other people
> worked on the file, in order to keep Emacs from misinterpreting the
> context.  Such misinterpretation looks ugly in fontification and is a
> real nuisance if you want to add several lines of new material and have
> Emacs indent it since Emacs will not indent within "strings" (and when
> it lost count of "..." pairs, that means everywhere where you'd want
> it).
>

Below some benchmarks - don't know how to read the results BTW, it took 
several seconds each.
No idea WRT diff between two test rows.

In any case didn't feel a significant diff between pps-based un-compiled 
approach considered reliable and the built-in.
GNU Emacs 24.4.1 (i586-pc-linux-gnu, GTK+ Version 3.14.5) of 2015-03-07 
on binet, modified by Debian

ar-beginning-of-defun is available here:
http://bazaar.launchpad.net/~a-roehler/s-x-emacs-werkstatt/trunk/view/head:/gnu-emacs-fixes.el

;;;;;;;;;;

(bod-test 'ar-beginning-of-defun 99999)"Elapsed time: 0.001541s"
(bod-test 'ar-beginning-of-defun 99999)"Elapsed time: 0.001197s"
(bod-test 'ar-beginning-of-defun 99999)"Elapsed time: 0.001845s"
(bod-test 'ar-beginning-of-defun 99999)"Elapsed time: 0.001326s"

(bod-test 'beginning-of-defun 99999)"Elapsed time: 0.002036s"
(bod-test 'beginning-of-defun 99999)"Elapsed time: 0.001215s"
(bod-test 'beginning-of-defun 99999)"Elapsed time: 0.001478s"
(bod-test 'beginning-of-defun 99999)"Elapsed time: 0.001699s"

;;;; tests some times later

(bod-test 'ar-beginning-of-defun 99999)"Elapsed time: 0.003947s"
(bod-test 'ar-beginning-of-defun 99999)"Elapsed time: 0.008513s"
(bod-test 'ar-beginning-of-defun 99999)"Elapsed time: 0.004473s"
(bod-test 'ar-beginning-of-defun 99999)"Elapsed time: 0.004457s"

(bod-test 'beginning-of-defun 99999)"Elapsed time: 0.004883s"
(bod-test 'beginning-of-defun 99999)"Elapsed time: 0.004741s"
(bod-test 'beginning-of-defun 99999)"Elapsed time: 0.004179s"
(bod-test 'beginning-of-defun 99999)"Elapsed time: 0.004660s"

;;;;;;;;;;

(defun bod-test (func repeat)
   (interactive)
   (let ((undo-outer-limit 999999999))
     (set-buffer (get-buffer-create (concat (prin1-to-string func) 
"-bm-test")))
     (erase-buffer)
     (dotimes (i repeat) (insert "(defun foo1 (&optional beg end)
   \" \"
   (interactive \"\*\")
   (let ((beg (cond (beg)
                    ((use-region-p)
                     (region-beginning))
                    (t (point-min))))
         (end (cond (end (copy-marker end))
                    ((use-region-p)
                     (copy-marker (region-end)))
                    (t (copy-marker (point-max))))))
     (save-excursion
       (goto-char beg))
     (when (interactive-p) (message \"%s %s\" beg end))))
"))
     (benchmark repeat
            (progn
          (beginning-of-line)
          (funcall func)
          ;; (message "%s" (point))
      ))))

;;;

Re: beginning-of-defun (again)

[Andreas Röhler]

  On 29.10.2015 12:52, Oleh Krehel wrote:
> Hi Andreas,
>
> Andreas Röhler<andreas.roehler@online.de>  writes:
>
>> maybe it's time to have a reasonable default-behavior of
>> beginning-of-defun in Emacs Lisp.
> I think it works pretty well as is.
>

Unfortunatly not. When started from inside a string, which has an open 
paren at column 0, the default will stop there.
Try from "bar":

(defun foo ()
   (insert "
(bar)"))

>> open-paren-in-column-0-is-defun-start
> It's a strange variable that doesn't seem to do anything.  The only
> relevant setting is 0 or non-zero (the default). Setting it to 0 seems
> to do nothing. Maybe someone could explain what it actually does.
>
>> A function resp. top-level-form starts if the beginning of a list is
>> followed by a respective keyword.
>> The list of keywords being customizable seems a plus :)
> There's no reason for a defun to not start on a newline.

Modes should honor the syntax, not impose conventions.

>   And there's
> nothing else that makes "(" be on a new line, except for rare cases

There is a plenty of rare cases, notably when meta-programming, i.e. if 
code is delivered by strings for insertion.

> in
> docstrings, where it can be escaped.  So it seems that the problem is
> already solved in a good way, without having to customize anything.
>
>      Oleh

Re: beginning-of-defun (again)

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 140 bytes --]

I have a feeling that this is related to being unable to instrument edebug
in defuns nested in macro forms like use-package. Is that right?

[-- Attachment #2: Type: text/html, Size: 158 bytes --]

Re: beginning-of-defun (again)

[John Wiegley]

>>>>> Oleh Krehel <ohwoeowho@gmail.com> writes:

> There's no reason for a defun to not start on a newline.

This is not true. In my init.el where I use use-package, here are the counts:

    defuns starting at column 0:          24
    defuns not starting at column 0:     120

We shouldn't generalize based on our own usage patterns.

John

Re: beginning-of-defun (again)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > There's no reason for a defun to not start on a newline.

  > This is not true. In my init.el where I use use-package, here are the counts:

  >     defuns starting at column 0:          24
  >     defuns not starting at column 0:     120

A miscommunication is visible here.  You're talking about whether they
_do_ start in column 0, and Oleh was talking about whether they _must_
not start in column 0.

Is there a specific practical reason why it is important for the
defuns in init.el not to start in column 0?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: beginning-of-defun (again)

[John Wiegley]

>>>>> Richard Stallman <rms@gnu.org> writes:

> Is there a specific practical reason why it is important for the defuns in
> init.el not to start in column 0?

They are within macros controlling whether they are evaluated or compiled or
not, based on available packages on the system.

I'm not particularly disturbed by the fact that beginning-of-defun doesn't
work for these functions, however. I was just saying that we shouldn't make
assumptions.

John

Re: beginning-of-defun (again)

[Oleh Krehel]

John Wiegley <johnw@newartisans.com> writes:

>>>>>> Richard Stallman <rms@gnu.org> writes:
>
>> Is there a specific practical reason why it is important for the defuns in
>> init.el not to start in column 0?
>
> They are within macros controlling whether they are evaluated or compiled or
> not, based on available packages on the system.

If they are within macros, they're data and not defuns in my mind. For
me, a defun is a top-level expression with "(" at column 0.  It doesn't
even need to define something callable (like `defun' or `defmacro'), so
a `defcustom' statement is a defun for purposes of `beginning-of-defun'.

> I'm not particularly disturbed by the fact that beginning-of-defun doesn't
> work for these functions, however.

Nor it should, unless we hook up a static code analyzer to Emacs and
make `beginning-of-defun' use that data:

(defun semantic-beginning-of-defun ()
  (interactive)
  (semantic-mode 1)
  (let ((tag-starts
         (mapcar
          (lambda (x)
            (semantic-tag-start x))
          (cl-remove-if-not
           (lambda (x)
             (eq (semantic-tag-class x) 'function))
           (semantic-fetch-tags))))
        pt)
    (while (and tag-starts (< (car tag-starts) (point)))
      (setq pt (pop tag-starts)))
    (goto-char pt)))

But it would be silly to use the above approach unless
`semantic-fetch-tags' is made somehow very fast and very smart.
The column 0 heuristic is a perfectly fine and fast alternative.

Besides, guess where the above function would bring me from this
situation (| is the point):

(defun ...)
(defvar ...)
(defvar ...)
(defvar ...|)

Would anyone actually want that behavior on "C-M-a", which is basically
(re-search-backward "(defun") at this point?

Re: beginning-of-defun (again)

[John Wiegley]

>>>>> Oleh Krehel <ohwoeowho@gmail.com> writes:

> If they are within macros, they're data and not defuns in my mind. For me, a
> defun is a top-level expression with "(" at column 0. It doesn't even need
> to define something callable (like `defun' or `defmacro'), so a `defcustom'
> statement is a defun for purposes of `beginning-of-defun'.

I realize you think this, Oleh; what I'm saying is that not everyone does.

As I mentioned, I'm fine with using column 0 as a heuristic. However, there
are use cases where it is confusing (I *still* hit C-M-x on nested defun's,
and find myself surprised that it does something else; and this despite
knowing the nature of the beast full well, and after many years of experience
of it not working).

Some people see "defun" and think this establishes a sort of syntactic entity
with regard to Emacs commands relating to defuns. What we're talking about is
a technical distinction that makes life easier for us -- and not about users
who find it confusing.

Since the decision is to go with the status quo, is there anything to discuss?

John

Re: beginning-of-defun (again)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Is there a specific practical reason why it is important for the defuns in
  > > init.el not to start in column 0?

  > They are within macros controlling whether they are evaluated or compiled or
  > not, based on available packages on the system.

I don't follow how that affects what column the openparen can be in.
Could you show what this looks like?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: beginning-of-defun (again)

[Alan Mackenzie]

Hello, Richard.

On Fri, Oct 30, 2015 at 07:13:56PM -0400, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

>   > > Is there a specific practical reason why it is important for the defuns in
>   > > init.el not to start in column 0?

>   > They are within macros controlling whether they are evaluated or compiled or
>   > not, based on available packages on the system.

> I don't follow how that affects what column the openparen can be in.
> Could you show what this looks like?

I think what John's saying is that in circumstances such as:

(eval-and-compile
  (defmacro foo ......
  ....
  ))

, the beginning of the defun (here a defmacro) for foo isn't at column
0, because Emacs Lisp Mode's indentation puts it to column 2.  So a
C-M-a will not find "(defmacro foo ...", which is sometimes irritating,
particularly when there are several de\(fun\|macro\)s within one
eval-and-compile.

> -- 
> Dr Richard Stallman
> President, Free Software Foundation (gnu.org, fsf.org)
> Internet Hall-of-Famer (internethalloffame.org)
> Skype: No way! See stallman.org/skype.html.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: beginning-of-defun (again)

[John Wiegley]

>>>>> Alan Mackenzie <acm@muc.de> writes:

> I think what John's saying is that in circumstances such as:
> (eval-and-compile
>   (defmacro foo ......
>   ....
>   ))

> , the beginning of the defun (here a defmacro) for foo isn't at column 0,
> because Emacs Lisp Mode's indentation puts it to column 2. So a C-M-a will
> not find "(defmacro foo ...", which is sometimes irritating, particularly
> when there are several de\(fun\|macro\)s within one eval-and-compile.

Yes, Alan has it pretty much exactly, only it's use-package instead of
eval-and-compile. Same difference, though.

John

Re: beginning-of-defun (again)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > (eval-and-compile
  >   (defmacro foo ......
  >   ....
  >   ))

The problem occurs because the "(defmacro" line is indented.
It ought to start at column zero so that the defmacro form
will be treated as a defun.

This is the way our convention is meant to be used:
so as to get the results you want.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: beginning-of-defun (again)

[Alan Mackenzie]

Hello, Andreas.

On Thu, Oct 29, 2015 at 12:24:48PM +0100, Andreas Röhler wrote:
>   Hi guys,

> maybe it's time to have a reasonable default-behavior of 
> beginning-of-defun in Emacs Lisp.

> IMO there is no reason for stuff like

> open-paren-in-column-0-is-defun-start

Unfortunately, there is.  Setting it to nil ensures accurate recognition
of non-nested parens, though this can be slow, sometimes very slow.
Setting it to non-nil makes it fast, but sometimes so inaccurate it
looks like a bug.

> A function resp. top-level-form starts if the beginning of a list is 
> followed by a respective keyword.

Not necessarily: how does Emacs know whether something looking like a
"top-level-form" is actually at the top level or not?  When
open-paren-in-column-0-is-defun-start is non-nil, it need scan no
further back than the first such paren encountered.  When
o-p-i-c-0-i-d-s is nil, it must scan all the way from the beginning of
the file.

> The list of keywords being customizable seems a plus :)

This would not work in all modes.

> Cheers,

> Andreas

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: beginning-of-defun (again)

[Andreas Röhler]

  On 29.10.2015 13:46, Alan Mackenzie wrote:
> Hello, Andreas.
>
> On Thu, Oct 29, 2015 at 12:24:48PM +0100, Andreas Röhler wrote:
>>    Hi guys,
>> maybe it's time to have a reasonable default-behavior of
>> beginning-of-defun in Emacs Lisp.
>> IMO there is no reason for stuff like
>> open-paren-in-column-0-is-defun-start
> Unfortunately, there is.  Setting it to nil ensures accurate recognition
> of non-nested parens,

Sorry, Alan, but if there is no syntax expecting a start in column 0, 
there is no reason to assume that.

Relying on such means working in some cases, in other not. You won't 
want that.


>   though this can be slow, sometimes very slow.
> Setting it to non-nil makes it fast, but sometimes so inaccurate it
> looks like a bug.
>
>> A function resp. top-level-form starts if the beginning of a list is
>> followed by a respective keyword.
> Not necessarily: how does Emacs know whether something looking like a
> "top-level-form" is actually at the top level or not?

Top-level here is the beginning of a not nested list.
Remains to set the keywords more or less restrictive.

>    When
> open-paren-in-column-0-is-defun-start is non-nil, it need scan no
> further back than the first such paren encountered.  When
> o-p-i-c-0-i-d-s is nil, it must scan all the way from the beginning of
> the file.
>
>> The list of keywords being customizable seems a plus :)
> This would not work in all modes.
>

The default can't work in all modes but be reliable in Emacs Lisp.

Re: beginning-of-defun (again)

[David Kastrup]

Andreas Röhler <andreas.roehler@online.de> writes:

>  On 29.10.2015 13:46, Alan Mackenzie wrote:
>> Hello, Andreas.
>>
>> On Thu, Oct 29, 2015 at 12:24:48PM +0100, Andreas Röhler wrote:
>>>    Hi guys,
>>> maybe it's time to have a reasonable default-behavior of
>>> beginning-of-defun in Emacs Lisp.
>>> IMO there is no reason for stuff like
>>> open-paren-in-column-0-is-defun-start
>> Unfortunately, there is.  Setting it to nil ensures accurate recognition
>> of non-nested parens,
>
> Sorry, Alan, but if there is no syntax expecting a start in column 0,
> there is no reason to assume that.
>
> Relying on such means working in some cases, in other not. You won't
> want that.

If Emacs becomes too slow for useful work otherwise, that's no
alternative to it sometimes making assumptions leading to bad
highlighting.

-- 
David Kastrup

Re: beginning-of-defun (again)

[Andreas Röhler]

  On 29.10.2015 14:31, David Kastrup wrote:
> Andreas Röhler<andreas.roehler@online.de>  writes:
>
>>   On 29.10.2015 13:46, Alan Mackenzie wrote:
>>> Hello, Andreas.
>>>
>>> On Thu, Oct 29, 2015 at 12:24:48PM +0100, Andreas Röhler wrote:
>>>>     Hi guys,
>>>> maybe it's time to have a reasonable default-behavior of
>>>> beginning-of-defun in Emacs Lisp.
>>>> IMO there is no reason for stuff like
>>>> open-paren-in-column-0-is-defun-start
>>> Unfortunately, there is.  Setting it to nil ensures accurate recognition
>>> of non-nested parens,
>> Sorry, Alan, but if there is no syntax expecting a start in column 0,
>> there is no reason to assume that.
>>
>> Relying on such means working in some cases, in other not. You won't
>> want that.
> If Emacs becomes too slow for useful work otherwise, that's no
> alternative to it sometimes making assumptions leading to bad
> highlighting.
>

Where it was proven Emacs is slow WRT an reasonable implementation, if 
such a thing doesn't exist?
AFAIK the current buggy one predates parse-partial-sexp and that part 
was never reconsidered WRT pps since.

Slow is the current "re-search-backward (if defun-prompt-regexp" stuff, 
which might be replaced by calls to pps + keyword.

Re: beginning-of-defun (again)

[David Kastrup]

Andreas Röhler <andreas.roehler@online.de> writes:

>  On 29.10.2015 14:31, David Kastrup wrote:
>> Andreas Röhler<andreas.roehler@online.de>  writes:
>>
>>>   On 29.10.2015 13:46, Alan Mackenzie wrote:
>>>> Hello, Andreas.
>>>>
>>>> On Thu, Oct 29, 2015 at 12:24:48PM +0100, Andreas Röhler wrote:
>>>>>     Hi guys,
>>>>> maybe it's time to have a reasonable default-behavior of
>>>>> beginning-of-defun in Emacs Lisp.
>>>>> IMO there is no reason for stuff like
>>>>> open-paren-in-column-0-is-defun-start
>>>> Unfortunately, there is.  Setting it to nil ensures accurate recognition
>>>> of non-nested parens,
>>> Sorry, Alan, but if there is no syntax expecting a start in column 0,
>>> there is no reason to assume that.
>>>
>>> Relying on such means working in some cases, in other not. You won't
>>> want that.
>> If Emacs becomes too slow for useful work otherwise, that's no
>> alternative to it sometimes making assumptions leading to bad
>> highlighting.
>>
>
> Where it was proven Emacs is slow WRT an reasonable implementation, if
> such a thing doesn't exist?

It's not more than 2 years ago or so that I had
open-paren-in-column-0-is-defun-start set to nil for a while.  I reset
it eventually since it caused holdups in scheme-mode (which, being based
on lisp-mode, is one of the most modern modes) when working on LilyPond.
Possibly also for working on Elisp.

I don't remember the details completely, but I do remember that I had
usability reasons to reset it again to its default value.

> AFAIK the current buggy one predates parse-partial-sexp and that part
> was never reconsidered WRT pps since.

parse-partial-sexp is not exactly new.

-- 
David Kastrup

Re: beginning-of-defun (again)

[Alan Mackenzie]

Hello, Andreas

On Thu, Oct 29, 2015 at 01:56:49PM +0100, Andreas Röhler wrote:
>   On 29.10.2015 13:46, Alan Mackenzie wrote:
> > On Thu, Oct 29, 2015 at 12:24:48PM +0100, Andreas Röhler wrote:
> >>    Hi guys,
> >> maybe it's time to have a reasonable default-behavior of
> >> beginning-of-defun in Emacs Lisp.
> >> IMO there is no reason for stuff like
> >> open-paren-in-column-0-is-defun-start
> > Unfortunately, there is.  Setting it to nil ensures accurate recognition
> > of non-nested parens,

> Sorry, Alan, but if there is no syntax expecting a start in column 0, 
> there is no reason to assume that.

> Relying on such means working in some cases, in other not. You won't 
> want that.

Note that o-p-i-c-0-i-d-s being non-nil doesn't mean that this is the
only way defun starts are recognised.  It is an additional facility in
addition to however else a major mode detects defun starts.


> >   though this can be slow, sometimes very slow.
> > Setting it to non-nil makes it fast, but sometimes so inaccurate it
> > looks like a bug.

> >> A function resp. top-level-form starts if the beginning of a list is
> >> followed by a respective keyword.
> > Not necessarily: how does Emacs know whether something looking like a
> > "top-level-form" is actually at the top level or not?

> Top-level here is the beginning of a not nested list.
> Remains to set the keywords more or less restrictive.

Like I said, without that variable, Emacs scans all the way from the
beginning of the buffer each time it needs to test the non-nestedness.
Sometimes this is what you want, sometimes not.  It's up to the user (or,
perhaps, the writer of the major mode) to set o-p-i-c-0-i-d-s
appropriately.

> >    When
> > open-paren-in-column-0-is-defun-start is non-nil, it need scan no
> > further back than the first such paren encountered.  When
> > o-p-i-c-0-i-d-s is nil, it must scan all the way from the beginning of
> > the file.

> >> The list of keywords being customizable seems a plus :)
> > This would not work in all modes.


> The default can't work in all modes but be reliable in Emacs Lisp.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: beginning-of-defun (again)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > A function resp. top-level-form starts if the beginning of a list is 
  > followed by a respective keyword.

That is not so.  Top level forms can call lots of functions.
A parenthesis in column zero is the best criterion to use.
It is simple and flexible; users can easily control it.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: beginning-of-defun (again)

[Andreas Röhler]

  On 30.10.2015 02:34, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>    >  A function resp. top-level-form starts if the beginning of a list is
>    >  followed by a respective keyword.
>
> That is not so.  Top level forms can call lots of functions.
> A parenthesis in column zero is the best criterion to use.
> It is simple and flexible; users can easily control it.
>

With emacs -Q, C-M-a from behind example below, stops at "(bar)", 
missing the beginning of function.

(defun foo ()
   (insert "
(bar)"))

Would call that buggy-by-design.
Whilst there is no need for this bug...

BTW how do you easily control it?

Re: beginning-of-defun (again)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > With emacs -Q, C-M-a from behind example below, stops at "(bar)", 
  > missing the beginning of function.

  > (defun foo ()
  >    (insert "
  > (bar)"))

Our convention is that you should write it this way:

   (defun foo ()
      (insert "
   \(bar)"))

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: beginning-of-defun (again)

[Andreas Röhler]

  On 31.10.2015 00:14, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>    >  With emacs -Q, C-M-a from behind example below, stops at "(bar)",
>    >  missing the beginning of function.
>
>    >  (defun foo ()
>    >     (insert "
>    >  (bar)"))
>
> Our convention is that you should write it this way:
>
>     (defun foo ()
>        (insert "
>     \(bar)"))
>

A convention which probably predates Aristoteles :)
Working-by-convention is rather a social thing...

That design was a real nuisance  when generating and writing functions 
on the fly.
Sure, it's possible to live with it. But why not remove that constraint, 
if possible?

Re: beginning-of-defun (again)

[David Kastrup]

Andreas Röhler <andreas.roehler@online.de> writes:

>  On 31.10.2015 00:14, Richard Stallman wrote:
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>>    >  With emacs -Q, C-M-a from behind example below, stops at "(bar)",
>>    >  missing the beginning of function.
>>
>>    >  (defun foo ()
>>    >     (insert "
>>    >  (bar)"))
>>
>> Our convention is that you should write it this way:
>>
>>     (defun foo ()
>>        (insert "
>>     \(bar)"))
>>
>
> A convention which probably predates Aristoteles :)
> Working-by-convention is rather a social thing...
>
> That design was a real nuisance  when generating and writing functions
> on the fly.
> Sure, it's possible to live with it. But why not remove that
> constraint, if possible?

Because reparsing every file from its beginning in order to indent the
current line is too expensive for large files?

The meaning of every Lisp file can be changed by putting

(setq everything "

at its beginning.  There really is no correct way to determine current
state apart from parsing from the start.  So we have a convention for an
"incorrect way" of avoiding parsing from the start.

-- 
David Kastrup

Re: beginning-of-defun (again)

[Andreas Röhler]

  On 31.10.2015 13:24, David Kastrup wrote:
> Andreas Röhler<andreas.roehler@online.de>  writes:
>
>>   On 31.10.2015 00:14, Richard Stallman wrote:
>>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>>> [[[ whether defending the US Constitution against all enemies,     ]]]
>>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>>
>>>     >   With emacs -Q, C-M-a from behind example below, stops at "(bar)",
>>>     >   missing the beginning of function.
>>>
>>>     >   (defun foo ()
>>>     >      (insert "
>>>     >   (bar)"))
>>>
>>> Our convention is that you should write it this way:
>>>
>>>      (defun foo ()
>>>         (insert "
>>>      \(bar)"))
>>>
>> A convention which probably predates Aristoteles :)
>> Working-by-convention is rather a social thing...
>>
>> That design was a real nuisance  when generating and writing functions
>> on the fly.
>> Sure, it's possible to live with it. But why not remove that
>> constraint, if possible?
> Because reparsing every file from its beginning in order to indent the
> current line is too expensive for large files?
>

Delivered some benchmark showing a reliable solution must not be slower.

> The meaning of every Lisp file can be changed by putting
>
> (setq everything "
>
> at its beginning.  There really is no correct way to determine current
> state apart from parsing from the start.  So we have a convention for an
> "incorrect way" of avoiding parsing from the start.
>

With the side-effect of creating a certain number of bugs - which are 
already inside, but not reported, because "configure..." would be the 
answer.

The current buggy behavior detects beginning-of-defun inside a string - 
which is not to cure by conventions.

Re: beginning-of-defun (again)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Sure, it's possible to live with it. But why not remove that constraint, 
  > if possible?

The column-0 convention is very useful because it
gives you control over which lists are treated as defuns,
by how you indent them.

If you write

(foo
  (defun x...))

Then the whole thing is treated as a defun.  But if you write

(foo
(defun x...))

then the (defun x ...) is treated as a defun.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.