From: Richard Stallman <rms@gnu.org>
To: Filipp Gunbin <fgunbin@fastmail.fm>
Cc: emacs-devel@gnu.org
Subject: Re: Don't move to eol in end-of-defun?
Date: Fri, 05 Aug 2022 23:41:39 -0400 [thread overview]
Message-ID: <E1oKAh1-0003XF-NW@fencepost.gnu.org> (raw)
In-Reply-To: <m2iln85a4f.fsf@fastmail.fm> (message from Filipp Gunbin on Thu, 04 Aug 2022 17:58:08 +0300)
[[[ 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. ]]]
> We have nested defuns here.
A "defun" in Emacs is not the same thing as a function definition
(or class definition).
class C {
void foo() {
}
}
has two nested definitions, but only the outermost one counts as a
defun in Emacs parlance.
A defun is a construct which is top-level, or appears locally to be.
In Lisp that usually means an open-paren in column 0. In some other
languages, there are other ways to find defuns.
> I just want to make movement to eol conditional, with default value
> meaning "like before", to not break anything.
Doing it that way might be ok. At any rate, no disaster. But it
leaves the question, should we really try to support nested defuns?
It is a can of worms.
--
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)
next prev parent reply other threads:[~2022-08-06 3:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-27 12:40 Don't move to eol in end-of-defun? Filipp Gunbin
2022-07-30 23:40 ` Daniel Martín
2022-07-31 22:31 ` Filipp Gunbin
2022-08-01 17:50 ` Alan Mackenzie
2022-08-01 20:49 ` Filipp Gunbin
2022-08-01 22:01 ` Filipp Gunbin
2022-08-03 3:46 ` Richard Stallman
2022-08-03 12:37 ` Filipp Gunbin
2022-08-04 4:04 ` Richard Stallman
2022-08-04 14:58 ` Filipp Gunbin
2022-08-06 3:41 ` Richard Stallman [this message]
2022-08-06 9:33 ` Alan Mackenzie
2022-08-07 4:24 ` Richard Stallman
2022-08-08 14:29 ` Filipp Gunbin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1oKAh1-0003XF-NW@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=fgunbin@fastmail.fm \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).