On Tue, 22 Jan 2019 14:47 -05:00, andr...@itship.ch wrote: > In the end everyone should use whatever fits that person the best, > we don't need one way to rule them all. > > - beneroth
Exactly. Well said, beneroth. I too am an emacs user. I use tj's picolisp-mode. I'm glad other people are writing picolisp modes/packages for emacs -- the more the merrier. Thanks, Alexis. Now back to the original topic. As I see it, it was: On Mon, 21 Jan 2019 06:43 -05:00, Jean-Christophe Helary wrote: > There are currently 2 picolisp modes for emacs, one is distributed > with picolisp and the other is on melpa. Is there a reason for that? Yes, there is a reason. I and many others value diversity in software. I would like as many choices as are available to do picolisp work in emacs. I enjoy learning about the advantages and disadvantages of one over the other, in other words, I like considering the design choices made by the authors and as how they relate to users' needs/requirements. Maybe I'd like to weigh in with a mode I write myself some day -- I don't now, as I, like beneroth, am happy with the tools I have now -- nevertheless, I know this is a viable option too. (beneroth said it best on irc; "well I guess most people in the picolisp community ended up here because they value other things [more] than ease of access"; yes, I think most people here are hackers and system tweakers.) I'm only saying this because I am reading what's implied by people like milkypostman (in that gh discussion): that there should be ONE WAY that we should all coalesce around and, otherwise, that diversity (often labeled "fragmentation" by its detractors) should be stamped out, in some sense. (I haven't heard this here, thankfully.) I couldn't disagree more. On Mon, 21 Jan 2019 08:14 -05:00, Jean-Christophe Helary wrote: > As far as emacs is concerned, we have melpa to manage our packages > and in the picolisp case we have the Debian based distributions that > only have access to the old mode and is not aware of the melpa > package, This is not a problem, as your/my emacs setup is orthogonal to this concern. This is especially true if, as I do, you do *not* believe that melpa is the standard (and pretty-much sole) way of managing emacs packages in your setup. It certainly has become a /defacto/ standard (not THE standard: such a thing does not exist), but ultimately, the way we configure emacs really determines how it runs. I caution all people who *only* use melpa for packages -- if you do, you will miss other packages (the ones that are not on melpa ofc). Internet searches like Google are your friend here. That is also why, for instance, `use-package` was written to allow users to source packages from pretty much anywhere on the intertubes, not *just* melpa (or even other ELPA-like services). > the rest of the world that has access to the melpa package and is > not aware of the distribution package (or would not bother since the > file is so old). That's not necessarily true. I use many off-melpa packages, some are old and still work fine for me. > That's messy. Define "mess". ;) > Considering that the melpa package is very actively maintained and > supports the doc set, and that the distribution maintainers are not > active, shouldn't we prefer a more standard "emacsy" way of dealing > with the emacs mode and prefer what is on melpa (while eventually > adding missing stuff from the distribution to the melpa archive)? I think those are good reasons for *you* to prefer Alexis's version and I wouldn't argue with you (they are indeed great reasons; to which I would also add Alexis's use of pilIndent instead of elisp code). But saying that "*we* [should] prefer" it and that there should be "*a* [meaning, one] standard 'emacsy' way ..."? No, I don't agree. On Tue, 22 Jan 2019 10:06 -05:00, Jean-Christophe Helary wrote: > Maybe it would be better to refer to available packages in the > documentation and let people use the one they like ? This is a good idea. Still, it's not easier than keeping things the way they are. As I believe you said: not a simple decision. For those people having trouble with their emacs setup (for programming and interaction with picolisp), what the system installs should not be bothering your emacs setup as long as your local packages (usually under ~/.emacs.d) are ahead of the system ones on the `load-path`. Also, picolisp executables and libs could be installed, by the distro package manager, on one system in a different location (path) than on another system. To solve this: either tweak your local emacs setup to point to the new location or, better yet, install picolisp yourself in a (your, that is) standard location. The latter is what I do -- then I don't have to change anything. Distro package managers are not going to keep up with the latest changes/versions anyway (not in general); so that's another reason I wouldn't count on them to install picolisp. As I told people on irc, I look forward to checking out Alexis's picolisp-mode when I get some time. Looks interesting and useful. This was just my long-winded way of saying what beneroth concisely said: "we don't need one way to rule them all." Just my 2 cents. Cheers, --Rick -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
