Re: Don't move to eol in end-of-defun?

[Filipp Gunbin]

On 07/08/2022 00:24 -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. ]]]
>
>   > The problem is that e-o-d moves point somewhere else _before_ it calls
>   > end-of-defun-function, and that somewhere else can easily be in a
>   > different (nested) defun.
>
> Is there a case which is incorrect _now_?  If so, what case is it,
> and what happens now in that case?

Yes, my example from previous messages.

>   > I think Filipp is asking for the coding of end-of-defun to be revisited.
>
> Code can be changed if it is broken, but the question behind that
> needs to be, "What is the right thing in this case?"

It's not broken, but rather clearly wasn't intended for nested defuns.
AFAICS, cc-mode overrides beginning/end-of-defun completely.

In my mode, I implemented just beginning/end-of-defun-function, while
using standard beginning/end-of-defun functions, and it works well
except for this case (and, yes, one more rare bug during narrowing, I'm
yet to investigate it).

Currently cc-mode and my implementation for Java work differently: as
Alan said, cc-mode goes outside the enclosing block, while I stay
inside.  I find it convenient to think about nested things in this way:
C-M-a and C-M-e should behave as if we were narrowed to the current
enclosing block, like if its contained methods/whatever were top-level.

>   > In these circumstances, for C-M-a to go to the outermost "defun"
>   > wouldn't be useful.
>
> Yes, we do need to be able to have outer groupings which we designate
> as "does not count as a defun", so that things inside it which look like
> defuns do count as  defuns.
>
> This requires a way for the programmer to mark them so that C-M-a
> mostly ignores them.
>
> However, any old nested function definition shouldn't be treated as a
> defun.

In Java, you can have "local" classes, these are classes defined and
used inside a method:

class C {

  void foo() {
    class D {
      void bar() {
      }
    }

    D d = new D();
    ...
  }
}

So I chose to "honestly" parse & handle context right from the start.

Filipp