unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "João Távora" <joaotavora@gmail.com>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: Adam Porter <adam@alphapapa.net>,
	emacs-devel <emacs-devel@gnu.org>,
	Dmitry Gutov <dgutov@yandex.ru>
Subject: Re: Better way to require with shorthands/renamed symbols
Date: Mon, 27 Sep 2021 17:59:34 +0100	[thread overview]
Message-ID: <CALDnm51oQS0Gh8dxMmcuj1eeOoQm0WNBeL-Ye-r_kxn6528+eQ@mail.gmail.com> (raw)
In-Reply-To: <CADwFkmkka7fMyaQrsBW0sx_jdnObAcAu7ip7y2ziVW3rxkUoZg@mail.gmail.com>

On Mon, Sep 27, 2021 at 4:05 PM Stefan Kangas <stefankangas@gmail.com> wrote:

> > [...] Maybe we can somehoe have file-local
> > variables in other points of the file?
> > Would that suffice for you and Stefan now?
> Sure, if we can figure out how to do that in a clean way.

I don't think it's particularly hard to do cleanly.  Just think of how
file-local variables are already supported in the first line
of a file.

>  Otherwise, we are probably better off just leaving things as they are,
> rather than complicating things just for the sake of it.

Yes, "for the sake of it" is obviously bad.  But solving particular
problems that are well described is fine with me.  For example, I'd like
to be able to activate shorthands in certain parts of the buffer, just like
one switches to a package in Common Lisp.  But I'm a CL guy and like
packages.

On this topic, it has come to my attention that some people are sore
or frustrated about how this feature has somehow "defeated" their
preferred idea.  I think that doesn't make sense.  If those ideas aren't
happening it is not because of my work.

I hope people come forward and state what it is they would like to do
namespacing-wise in Elisp.  And then help everyone else think if it is
possible to actually implement it without impacting the existing tooling
(too much). Ideally, a prototype of this hypothetical feature be made.

> Maybe it's already fine as  it is, given the scope of the feature.

The Shorthands feature doesn't have any particular "scope", IMO. It
depends on the use you want to give it.  I believe it will be used for
importing `s.el` and `s.el`-dependent libraries into Emacs or *-ELPA
somehow. That's one application.

Personally, I plan on using it in newer Emacs28-only versions of my
packages: i hate typing/reading long prefixes. Maybe a clean Elisp
version can be developed for older Emacsen, I dunno (the first
version I did was Elisp only, but I don't remember if it worked fully
like this one).

João



  reply	other threads:[~2021-09-27 16:59 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210927003203.15806.29864@vcs0.savannah.gnu.org>
     [not found] ` <20210927003205.EF26620A5E@vcs0.savannah.gnu.org>
2021-09-27 11:10   ` Better way to require with shorthands/renamed symbols Stefan Kangas
2021-09-27 11:58     ` Dmitry Gutov
2021-09-27 12:54       ` Shorthands have landed on master (Was: Better way to require with shorthands/renamed symbols) João Távora
2021-09-27 13:06         ` Dmitry Gutov
2021-09-27 22:40         ` Shorthands have landed on master Philip Kaludercic
2021-09-27 22:58           ` João Távora
2021-09-28  7:15             ` Philip Kaludercic
2021-09-28  9:03               ` João Távora
2021-09-28  9:14                 ` Eli Zaretskii
2021-09-28  9:17                   ` João Távora
2021-09-28  9:22                 ` Philip Kaludercic
2021-09-28 23:37         ` Shorthands have landed on master (Was: Better way to require with shorthands/renamed symbols) Richard Stallman
2021-09-27 12:24     ` Better way to require with shorthands/renamed symbols João Távora
2021-09-27 12:55       ` Dmitry Gutov
2021-09-27 13:09         ` João Távora
2021-09-27 15:05           ` Stefan Kangas
2021-09-27 16:59             ` João Távora [this message]
2021-09-27 20:12               ` Stefan Kangas
2021-09-27 20:18                 ` João Távora
2021-09-28  1:53                   ` T.V Raman
2021-09-30  6:04                     ` Richard Stallman
2021-09-28  4:01                 ` Ihor Radchenko

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=CALDnm51oQS0Gh8dxMmcuj1eeOoQm0WNBeL-Ye-r_kxn6528+eQ@mail.gmail.com \
    --to=joaotavora@gmail.com \
    --cc=adam@alphapapa.net \
    --cc=dgutov@yandex.ru \
    --cc=emacs-devel@gnu.org \
    --cc=stefankangas@gmail.com \
    /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).