I guess you could fairly easily write a macro that automatically created a lexical scope and added some prefixes to variable used within its body - Doug Hoyte's "Let over lambda" book has #CommonLisp examples of this kind of approach as way to cut down the syntactic overhead of using gensym in macros. Without much thought, I'd assume something similar could be done in #EmacsLisp
@The ol' tealeg 🐡 I'm thinking something a little more robust involving using a symbol's property list to store everything contained within that namespace.
I'm probably biting off more than I can chew at this point in my understanding of elisp, but I'm sure this idea will stick around in my brain until I have enough of an understanding to pull it (or something comparable) off.
...or I find some already existing thing that does what I want (which is more likely).
SBCL, for example, has the in-package macro set the value of the special variable *PACKAGE* which, I guess, would then ultimately get used in every definition and reference.
I haven't having looked at it, but I imagine that it mostly comes down to switching out in-buffer eval functions to those which are current-package aware. If you resolve and swap out all symbols with their "absolute" versions during definition, you should be able to call that code from different namespaces without problems.
@screwtape Oh come on you understand the situation perfectly ;) You can write hacks to make it look like there are namespaces, but at the end of the day, they are just hacks.
There has been multiple discussions about it on emacs-devel, and there is no way to get elisp out of the dark ages until the usual suspects are replaced. Which is not happening any time soon.
@screwlisp @Nicolas Martyanoff If you think I'd actually have anything interesting to say. I feel I can't really hold a candle to some of your previous guests. I'm just aimlessly noodling around with stuff.
Harald
in reply to Jonathan Lamothe • • •Currently there are two options which help for the underlying problem:
gnu.org/software/emacs/manual/…
gnu.org/software/emacs/manual/…
I use both here:
codeberg.org/harald/eglot-supp…
For the shorthands, check the last few lines of the file.
But, no doubt, some real namespace with an export/import convention would be great.
eglot-supplements/eglot-selran.el at main
Codeberg.orgThe ol' tealeg 🐡
in reply to Jonathan Lamothe • • •Jonathan Lamothe
in reply to The ol' tealeg 🐡 • •@The ol' tealeg 🐡 I'm thinking something a little more robust involving using a symbol's property list to store everything contained within that namespace.
I'm probably biting off more than I can chew at this point in my understanding of elisp, but I'm sure this idea will stick around in my brain until I have enough of an understanding to pull it (or something comparable) off.
...or I find some already existing thing that does what I want (which is more likely).
The ol' tealeg 🐡
in reply to Jonathan Lamothe • • •Vassil Nikolov
in reply to The ol' tealeg 🐡 • • •@tealeg
Just a sidenote, but `in-package' and Co. are Common Lisp things, not just SBCL's.
And `*package*' is mainly used by the reader.
#CommonLisp
The ol' tealeg 🐡
in reply to Vassil Nikolov • • •@vnikolov the specific macro expansion can differ though, right?
Really I was just quickly checking by doing `(macroexpand ‘(in-package foo))`, I never really thought much about the implementation before now.
Thuna
in reply to Jonathan Lamothe • • •Nicolas Martyanoff
in reply to Jonathan Lamothe • • •screwlisp
in reply to Nicolas Martyanoff • • •@galdor
Nicolas Martyanoff
in reply to screwlisp • • •@screwtape
Oh come on you understand the situation perfectly ;) You can write hacks to make it look like there are namespaces, but at the end of the day, they are just hacks.
There has been multiple discussions about it on emacs-devel, and there is no way to get elisp out of the dark ages until the usual suspects are replaced. Which is not happening any time soon.
screwlisp
in reply to Nicolas Martyanoff • • •@galdor
jlamothe did say the words introducing rudimentary...!
By the way, should I interview you ("interview") some time?
@me
Jonathan Lamothe
in reply to screwlisp • •