On Fri, May 8, 2020 at 3:49 AM Richard Stallman wrote: > Thank you for taking back that word. It hurt my feelings. My apologies, again > Or perhaps "Would have a significant drawback"? That I can agree with > you about. Still, it may be the best choice available under the > circumstances. I agree. Under the current circumstances. But we can work to change the circumstances. > was never to use it nontrivially. Thus I decided, when writing Emacs > Lisp to, to avoid conflicts by means of name prefixes, and not have > packages at all. > However, the state of the art may have advanced since then. It has indeed evolved since the 1980's. Most implementations of Common Lisp now have something called "package local nicknames", which many find advantageous. There are proponents and adversaries. I'm one of the proponents, and if you wish I can sing you the joys of the CL package system. But that can be for later. Currently, I count around 7 different implementations and even more vapourware. The debate over which to choose is likely to be very lengthy. In the end we can even choose more than one system. But we should keep our eyes on the prize, as they say, and resolve the s.el and dash.el (and also f.el) situation in the shorter term, so that those free programs can join our ranks without hurting us, our existing users, or their existing users. > This week you said there was a kind of namespace system for Lisp that > works well and avoids those problems. If that is true, it could be a > good solution. Indeed I said so: I was referring to a simple shorthand system. In this system, there are no profound changes to how symbols are organized in Emacs. Things can have different names in different contexts, much as "RMS" means something different in Electrical Engineering or in this mailing list. > Another obstacle for my reading those messages was that you were > responding to other people's questions, which were not the same > questions that I need to understand. > > Can you show me programmer's intro to using a package system of the > sort you're advocating? I think I could tell what I need to know from > that. Yes, that's a good idea. So our goal is to use the problematic s.el library without having it pollute our namespace, right? To do that, we first load the library shorthand.el (attached to this message) into our Emacs. Then, we must change s.el minimally. Its contents are (very truncanted): ;;; s.el --- The long lost Emacs string manipulation library. ;; Author: Magnar Sveen (defun s-collapse-whitespace (s) "Convert all adjacent whitespace characters to a single space." ...) (defun s-lines (s) "Splits S into a list of strings on newline characters." ...) (provide 's) ;;; s.el ends here, We need to ask the author to add a few lines to the end of the file and maybe also change the file name: ;;; magnar-string.el --- Now with 99% less namespace pain (defun s-collapse-whitespace (s) ...) (defun s-lines (s) ...) (provide 'magnar-string) ;;; magnar-string.el ends here, ;; Local Variables: ;; shorthand-shorthands: (("^s-" . "magnar-string-")) ;; End: Theoretically, we could avoid this step altogether and "guess" the shorthand from a list of known problematic cases. Now, Richard, when you load the new magnar-string.el file into your Emacs namespace won't be polluted with those two names. Instead, the the two symbols will be called `magnar-string-lines' and `magnar-string-collapse-whitespace'. In your hypothetical "foobarbaz.el" you can now: (require 'magnar-string) (defun f-test () (interactive) (message (cadr (s-lines "this\nworks")))) ;; Local Variables: ;; shorthand-shorthands: (("^s-" . "magnar-string-") ("^f" . "foobarfaz")) ;; End: Again, by loading foobarbaz.el you will have created the function `foobarbaz-test', despite having typed `f-test'. > After that, would you be willing to talk with me by voice so I can > understand enough to see whether this is a good solution? Yes. What voice system do you prefer? I live in GMT, btw. João PS: I attach to this message the shorthand.el file mentioned above, followed by the modified magnar-string.el. Please note that shorthand.el is EXPERIMENTAL. If you want to try it, you should read it beforehand (it's less than 50 lines) and load it into a separate Emacs.