Hi Jean-Christophe! Trying to clear up maybe some confusion (and I had already started composing this too long ago :).
On Wed, 23 Jan 2019 00:17 -05:00, Jean-Christophe Helary wrote: > 1) On debian and related distributions, the picolisp official mode is > installed by default Just to be clear, there is no "picolisp official mode" or even "official picolisp mode". Certainly, Alex does not claim this; he is only including a version of picolisp-mode in the picolisp distro for the user's convenience. He started doing this probably way before there was even an emacs package manager. :) Back then (were dinosaurs roaming the earth then, Alex? :), this was the way to distribute that for visibility sake (and I'll bet that was the first picolisp-mode too). At any rate, please don't think that the picolisp-mode in the picolisp distro is "official" in any sense. It's more like a remnant. It should probably stay there solely because it is not hosted (in a permanent sense) anywhere else AFAIK. At any rate, it's not "official." > and in fact, there is no mention of that mode in the emacs package > manager when you look for it, When you say "there is no mention of that mode in the emacs package manager when you look for it", if you mean that you can't see it when you look at the list generated by `package-list-packages`, that would be correct, since those packages are registered with an ELPA service (like melpa) and the picolisp-mode in the picolisp distro is not registered with any ELPA service AFAIK (nor does it need to be IMO). This might be a good place to mention that melpa isn't: (1) the only ELPA-like service/archive and (2) it is not the only way to install emacs packages. I mentioned this in one of my other emails today. And, I include some detail on this below. > so you have no idea that anything is installed until you load a > picolisp file. Well, if you load a picolisp source file (*.l) and you are in some picolisp-mode and you didn't cause that to happen by purposefully setting that up in your emacs configuration, then that is simply due to dumb luck. Any emacs user has to be sure to put the location (directory) of any packages on `load-path` and set up an association to *.l files. Just like when you login to a unix system, you should know where the programs are located and how to set up PATH (and other things) to get it working right, the same holds for emacs configurations. If you can't "see" a package / mode, that means that you have lost the handle on where things are located. That's on you. And that's also why I mentioned (in a previous email, again), that to stabilize that situation, I recommend to use the same emacs setup and install picolisp yourself to a "standard" (for you) directory (maybe under your $HOME) and that way you will know where everything is -- and it will Just Work(TM) with no further config tweaking. IOW, I recommend not to rely on your OS/distros package manager to install picolisp (they don't install them in consistent places from one distro to another, as you've noticed). > 2) Similarly, on Debian, the alternative picolisp mode from Alexis > is not listed in the emacs package manager. If "listed in the emacs package manager" means that you can see it in package-list-packages` output buffer, then *not* seeing it there means that your emacs configuration is *not* pointing to the melpa service -- check the `package-archives` variable -- (because we know that Alexis's package is registered on melpa) or your network connex to melpa was temporarily down. For instance, I can see it here now in my package-list-packages output: > picolisp-mode is an available package. > > Status: Available from melpa -- Install > Archive: melpa > Version: 20190105.720 > Commit: 39e54f31b5d10483aac2765bf5cc4ad92f9e4467 > Summary: Major mode for PicoLisp programming. > Homepage: https://github.com/flexibeast/picolisp-mode > Keywords: picolisp lisp programming > It may be because of a namespace issue, I have no idea. No. > 3) I don't know how all that works for other Linux distributions. It > could be the same, it could be different. Well, at least for emacs, it (emacs) works according to your personal emacs configuration (normally either in ~/.emacs.d/init.el or ~/.emacs). Please tell me that you have one of these and are not relying on the "fallback" emacs site/system configuration. If that were the case, that could be the cause of inconsistent emacs behavior from one platform to the next. > 4) On my Mac, from where I can only ssh to my Raspbian picolisp, I > have access to the melpa picolisp package and I discovered that this > was not the same as the one distributed with picolisp when I noticed > differences in behavior that caused a bit of confusion (no access to > docs, etc.) Yes. This is OK, i.e., there are different versions / forks of picolisp-mode. Pick the one you like. > There are a number of ways to solve all that in order of > "completeness" and "complexity": There seems to be no systemic problem and thus nothing to solve, except for your personal emacs configuration, if I'm reading your email correctly. > I) Document the situation in the picolisp distribution (that won't > solve the fact that Alexis' mode is not visible in Debian's emacs, > but at least people will know the issue), that's an easy and > costless thing to do: edit the wiki and the Readme file. I could do > that. I suppose we could mention that there are a few choices of emacs major modes for picolisp programming and even a rundown of their functionality / capability. Sounds good. Please do that if you have time. Thanks. > II) make Alexis' mode visible in melpa even when running Debian. I'm > in touch with the Debian packager for picolisp Alexis's mode is already in melpa. Maybe what you need is the right setup to get melpa packages listed in the `package-list-packages` output. This is what I have in my emacs configuration and it works on whatever OS I'm on. (setq package-archives '(("gnu" . "http://elpa.gnu.org/packages/";) ("org" . "http://orgmode.org/elpa/";) ("melpa" . "http://melpa.org/packages/";) ("melpa-stable" . "http://stable.melpa.org/packages/";))) You probably don't need the org one or the melpa-stable one. (See the other two sources (actually, they're called "archives"; I called them "services" earlier)? The one labeled "gnu" is the original ELPA where authors registered packages before mepla came along. melpa is the bigger archive now by far.) > If that's only a namespace issue the solution would probably require > to modify either the picolisp official emacs mode name or Alexis'. Not needed / necessary. > a- Considering that the distribution mode is not visible in emacs > package system, changing its name would be transparent since calling > the mode is made automatically with emacs hooks. Only when calling > the mode manually would things differ, in which case the user should > only remember the new mode name and we're done. Also, it's a one > time install that is handled by Linux distribution packagers and > users generally don't have to bother. Again, not necessary. If you like the picolisp distro's picolisp-mode, you just copy that into a directory, put that directory on `load-path` and use the same config bits to load that package. Here's mine that I use for tj's picolisp-mode, if it helps. (use-package picolisp ;; Source: https://github.com/tj64/picolisp-mode.git :load-path "~/.emacs.d/contrib/picolisp-mode" :mode ("\\.l\\'" . picolisp-mode) :config (require 'inferior-picolisp) (add-hook 'picolisp-mode-hook (lambda () (setq picolisp-program-name "/opt/bin/pil")))) I just `git clone`d tj's package under ~/.emacs.d/config and used the above settings. No melpa or emacs package manager was necessary. > b- Changing Alexis' mode name requires administrative work on > Melpa's side, it requires users to manually change the mode, updates > would not be automatic, etc. That's another reason why Alexis should *not* rename his package nor should he remove it from melpa. Alexis and the melpa people got that right IMO. > III) make sure that all the goodies that are in the picolisp mode > are available in Alexis' mode and make Alexis' mode the distribution > default. That includes inferior-picolisp.el. That requires Alexis to > work on making sure that there is full compatibility. Right, that's up to Alexis and anybody willing to help him. > I checked the paredit patch provided with picolisp, it only adds a > "paredit-delete-leading-whitespace" function in various places. It > is probably useful, and why not propose it for inclusion in paredit > proper ? If it is not accepted, there is probably a way to trigger > that behavior without having to patch paredit (a hook in the > picolisp mode ?) but I don't know. idk either. I don't use paredit. > IV) Not strictly related, but the picolisp-wiki-mode could be > transformed into a melpa package. That would be especially useful if > "picolisp-wiki" (the server-side code) were packaged in Linux > distributions so as to offer a usable wiki solution at large. That > would also contribute to increasing picolisp's visibility. I'm out on that too. I just type in the wiki source with no help from an editor. I hope that some of this info helped. Please forgive me if I seemed in any way lecturing. I just don't really know your skill level with emacs or admin stuff. Cheers, --Rick -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
