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

[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. ]]]

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

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

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

  >   CC Mode has C-M-a moving to the previous start of
  > defun at the current level of namespace/class/struct nesting, or the
  > next level outwards when we bump up against the defining
  > namespace/class/struct start.  C-M-e works likewise.

Can that method be used in this language too?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)