[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Filipp Gunbin
Subject: Re: Don't move to eol in end-of-defun?
Date: Mon, 08 Aug 2022 17:29:50 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]