From: Eli Zaretskii <eliz@gnu.org>
To: Evgeni Kolev <evgenysw@gmail.com>
Cc: dev@rjt.dev, theo@thornhill.no, 61368@debbugs.gnu.org
Subject: bug#61368: [PATCH] Extend go-ts-mode with support for pre-filling return statements
Date: Thu, 09 Feb 2023 15:39:55 +0200 [thread overview]
Message-ID: <83357flzys.fsf@gnu.org> (raw)
In-Reply-To: <CAMCrgaUa26s2BM8EskKt5FTEyFqyioqx13abOFSMjcyShgG=Pg@mail.gmail.com> (message from Evgeni Kolev on Thu, 9 Feb 2023 13:47:01 +0200)
> From: Evgeni Kolev <evgenysw@gmail.com>
> Date: Thu, 9 Feb 2023 13:47:01 +0200
> Cc: 61368@debbugs.gnu.org, dev@rjt.dev, theo@thornhill.no
>
> > Instead of a command bound to a special key sequences, would it
> > perhaps make more sense to add some kind of "electric" behavior to
> > "normal" keys? Like perhaps typing RET after inserting "return" would
> > add the "context-aware return statement"? Then the user could turn on
> > the electric behavior with some minor mode, and get this behavior,
> > while avoiding the need to dedicate a key sequence.
> >
> > WDYT?
>
> Makes sense. I am familiar with electric-pair-mode. I see that it adds
> a hook in post-self-insert-hook. Is your suggestion to do something
> like this:
> - add hook in post-self-insert-hook
> - in the hook check if RET is typed after an "return"
> - if yes, replace the "return" with the "context-aware return
> statement", possibly using (yas-expand-snippet)
Yes, something like that. See electric.el for more examples.
> I'm wondering what customization options would make sense for users -
> changing the electric trigger from "return" RET to "ret" RET for
> example.
>
> Is there another major mode which can be used as an example for such
> electric behavior?
Electric modes are usually minor modes that let major modes customize
them by setting variables. Again, I think you will find examples in
electric.el.
next prev parent reply other threads:[~2023-02-09 13:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-08 15:27 bug#61368: [PATCH] Extend go-ts-mode with support for pre-filling return statements Evgeni Kolev
2023-02-08 16:30 ` Eli Zaretskii
2023-02-09 11:47 ` Evgeni Kolev
2023-02-09 13:39 ` Eli Zaretskii [this message]
2023-02-18 11:46 ` Evgeni Kolev
2023-02-18 12:14 ` João Távora
2023-02-20 8:54 ` Evgeni Kolev
2023-02-20 12:55 ` Eli Zaretskii
2023-02-22 14:36 ` Evgeni Kolev
2024-01-10 22:43 ` Stefan Kangas
2024-01-15 8:21 ` Evgeni Kolev
2024-01-15 8:39 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-15 11:40 ` João Távora
2023-02-08 19:20 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
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=83357flzys.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=61368@debbugs.gnu.org \
--cc=dev@rjt.dev \
--cc=evgenysw@gmail.com \
--cc=theo@thornhill.no \
/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).