Re: picolisp-mode

[rick]

Hi Jean-Christophe!

On Wed, 23 Jan 2019 02:33 -05:00, Jean-Christophe Helary wrote:
> There is also a maintenance issue for the official mode. From what I 
> understand, there seems to be 3 different versions of that mode and the 
> authors are not active anymore (and have not been for 6 years)...

That's ok.  They are working fine for us for years anyway.  Many of us 
(including me) know elisp and can fix them, but honestly, there has never been 
an issue with them.

> In all honesty, if picolisp had not been maintained and updated for 6 
> years, would you consider using it ? I don't think you would.

I agree.  But also,. I would argue that that's not exactly an apples-to-apples 
comparison.  Editor configurations are much easier to work with and much less 
complex than language and virtual machine implementations.  I'll leave the 
latter to Alex. :)

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: picolisp-mode

[Jean-Christophe Helary]

Rick,

Thank you for explaining your position. My wording may have been clumsy but I 
agree with everything you write.

The discussion is not about changing anything for people who already use one or 
the other mode. It is about proposing something easy to use *and* not confusing 
to new comers.

Besides for the merits of the various modes and the merits of having multiple 
modes, I think there is a big documentation issue. It is easily fixable and 
since that information is on the wiki that's something I can fix.

Then there is literally a ressource visibility issue at least on Debian. This 
one is not easy to fix and requires information from the Debian packager. I can 
ask for more information and see if there is a relatively easy fix.

There is also a maintenance issue for the official mode. From what I 
understand, there seems to be 3 different versions of that mode and the authors 
are not active anymore (and have not been for 6 years)...

In all honesty, if picolisp had not been maintained and updated for 6 years, 
would you consider using it ? I don't think you would.

Jean-Christophe 

> On Jan 23, 2019, at 15:20, r...@tamos.net  wrote:
> 
> On Tue, 22 Jan 2019 16:11 -05:00, Alexis wrote:
>> Having said all that, if the PicoLisp community generally felt it
>> would be best to settle on the mode currently bundled with the
>> distribution as /the/ Emacs mode for PicoLisp, and wanted me to
>> remove my mode from MELPA - or at least, rename it - in order to
>> avoid confusion, i'd be fine with that as well. :-)
> 
> No! :) First of all, there is no /the/ emacs mode for picolisp.  At
> the very least, that is my personal opinion.  beneroth mentioned on
> irc that there are picolisp users who use each of the known (including
> yours) picolisp modes. I don't think that they believe there is a
> "/the/ mode". :)
> 
> Also, "No!' goes for renaming or removing your code on melpa.  Please
> do not do this.  It is unnecessary.  I believe that you and the melpa
> people resolved this correctly.  I don't think anybody here believes
> that you "stole" or "sneaked" your code into melpa before any of the
> previously written mode authors could (in the "mwahahaha!" style,
> twirling the end of your mustache :).  That would be silly.  Anyway,
> those authors had plenty of time to register their mode with melpa if
> they wanted to.  They didn't.  (And you honestly didn't know about the
> others.)  melpa is just not an essential; it's just a nice
> convenience.  I get that milkypostman wants melpa to "win mindshare"
> or whatever his goals and motives are -- he certainly seems to believe
> in /the/ way.  Hey, as long as I can still source packages from
> where-ever, the melpa people can do whatever they want.
> 
> Anyway, that was very admirable of you to consider the community
> though.  Thanks, man!
> 
> Cheers, --Rick
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe 
> 

Jean-Christophe Helary
---
http://mac4translators.blogspot.com  
@brandelune

Re: picolisp-mode

[rick]

On Tue, 22 Jan 2019 16:11 -05:00, Alexis wrote:
> Having said all that, if the PicoLisp community generally felt it
> would be best to settle on the mode currently bundled with the
> distribution as /the/ Emacs mode for PicoLisp, and wanted me to
> remove my mode from MELPA - or at least, rename it - in order to
> avoid confusion, i'd be fine with that as well. :-)

No! :) First of all, there is no /the/ emacs mode for picolisp.  At
the very least, that is my personal opinion.  beneroth mentioned on
irc that there are picolisp users who use each of the known (including
yours) picolisp modes. I don't think that they believe there is a
"/the/ mode". :)

Also, "No!' goes for renaming or removing your code on melpa.  Please
do not do this.  It is unnecessary.  I believe that you and the melpa
people resolved this correctly.  I don't think anybody here believes
that you "stole" or "sneaked" your code into melpa before any of the
previously written mode authors could (in the "mwahahaha!" style,
twirling the end of your mustache :).  That would be silly.  Anyway,
those authors had plenty of time to register their mode with melpa if
they wanted to.  They didn't.  (And you honestly didn't know about the
others.)  melpa is just not an essential; it's just a nice
convenience.  I get that milkypostman wants melpa to "win mindshare"
or whatever his goals and motives are -- he certainly seems to believe
in /the/ way.  Hey, as long as I can still source packages from
where-ever, the melpa people can do whatever they want.

Anyway, that was very admirable of you to consider the community
though.  Thanks, man!

Cheers, --Rick

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: picolisp-mode

[rick]

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

Re: picolisp-mode

[Jean-Christophe Helary]

> On Jan 23, 2019, at 6:00, Alexis  > wrote:
> 
> Having said all that, if the PicoLisp community generally felt it would be 
> best to settle on the mode currently bundled with the distribution as /the/ 
> Emacs mode for PicoLisp, and wanted me to remove my mode from MELPA - or at 
> least, rename it - in order to avoid confusion, i'd be fine with that as 
> well. :-)

Just to make sure that there is no confusion :)

I am the one who raised the issue and I can't seriously be called "the picolisp 
community" ;)

And the issue I raised is the following (repeating myself, just to make sure we 
are all on the same page):

1) On debian and related distributions, the picolisp official mode is installed 
by default and in fact, there is no mention of that mode in the emacs package 
manager when you look for it, so you have no idea that anything is installed 
until you load a picolisp file. It also could be that the paredit patch is 
applied, it could be that the picolisp-wiki mode is installed as well, but 
there is no visible trace of that.

2) Similarly, on Debian, the alternative picolisp mode from Alexis is not 
listed in the emacs package manager. It may be because of a namespace issue, I 
have no idea.

3) I don't know how all that works for other Linux distributions. It could be 
the same, it could be different.

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.)

There are a number of ways to solve all that in order of "completeness" and 
"complexity":

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.

II) make Alexis' mode visible in melpa even when running Debian. I'm in touch 
with the Debian packager for picolisp so I can ask if that's a namespace issue 
or something else. If that's only a namespace issue the solution would probably 
require to modify either the picolisp official emacs mode name or Alexis'.

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.

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.

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.

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.

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 useable 
wiki solution at large. That would also contribute to increasing picolisp's 
visibility.

Jean-Christophe Helary
---
http://mac4translators.blogspot.com  
@brandelune

Re: PicoLisp v. MicroPython ?

[Joh-Tob Schäg]

well there is MicroPicoLisp which aims for the low ram embedded space. PicoLisp 
itself depends on some Unix abstractions which are not present in all systems 
but MicroPicoLisp should be fine.


  Ursprüngliche Nachricht  
Von: hbak...@pipeline.com
Gesendet: 23. Januar 2019 01:06
An: picolisp@software-lab.de
Antworten: picolisp@software-lab.de
Betreff: PicoLisp v. MicroPython ?

MicroPython (micropython.org) is apparently an
implementation of Python intended for *bare metal*
implementations.

Is PicoLisp aiming for some of the same applications?


-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PicoLisp v. MicroPython ?

[George Orais]

Hi Henry,

From what I know, these are the options for PicoLisp:
1. PilOS
2. miniPicoLisp
3. And the one Im still working on which is PilMCU.

There is also another Lisp which is similar to this: uLisp



BR,
geo

> On Jan 23, 2019, at 8:58 AM, Henry Baker  wrote:
> 
> MicroPython (micropython.org) is apparently an
> implementation of Python intended for *bare metal*
> implementations.
> 
> Is PicoLisp aiming for some of the same applications?
> 
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

PicoLisp v. MicroPython ?

[Henry Baker]

MicroPython (micropython.org) is apparently an
implementation of Python intended for *bare metal*
implementations.

Is PicoLisp aiming for some of the same applications?


-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: picolisp-mode

[Alexis]

andr...@itship.ch writes:


I greatly enjoy using paredit, which works well.
I have not tried out the other emacs modules for picolisp, and I 
don't
know if the one in MELPA works well with paredit, which I see as 
the

essential feature for an emacs picolisp-mode.


i myself don't use paredit - i've tried it, and have made an 
effort to use it, but in the end i found it to be much more of a 
hindrance than a help[1]. So i don't have any experience with 
paredit's interactions with my mode.



If the MELPA package supports paredit


Could you please explain what it means to "support paredit"? i 
certainly wouldn't want my mode to get in the way of people who 
want to use paredit.



and the other features of the
picolisp-mode coming with picolisp, ideally by also supporting 
the

nice tools from the vim/vip editors


Could you please elaborate on this? Which tools in particular are 
you thinking of?



Different users might find different versions, but I would not
consider it impossible or even difficult to get to the things 
you

want.
In the end everyone should use whatever fits that person the 
best, we

don't need one way to rule them all.


*nod* i very much agree. Whilst i definitely see the benefits of 
there being only one 'picolisp-mode', i also feel that there are 
benefits to having than one set of functionality available. Take 
the vc/magit situation as an example: vc and magit have quite 
different approaches to providing a UI to git, and that allows 
different users to choose the approach that works better for 
them.


Having said all that, if the PicoLisp community generally felt it 
would be best to settle on the mode currently bundled with the 
distribution as /the/ Emacs mode for PicoLisp, and wanted me to 
remove my mode from MELPA - or at least, rename it - in order to 
avoid confusion, i'd be fine with that as well. :-)



Alexis.

[1] Yes, i'm aware of the claim that "[i]f you think paredit is 
not for you then you need to become the kind of person that 
paredit is for." :-)


--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: picolisp-mode

[andreas]

I'm working with picolisp and emacs, also using the older picolisp-mode 
which comes with the picolisp distribution (the official upstream one 
from http://software-lab.de/down.html).


I greatly enjoy using paredit, which works well.
I have not tried out the other emacs modules for picolisp, and I don't 
know if the one in MELPA works well with paredit, which I see as the 
essential feature for an emacs picolisp-mode.


The one coming with the picolisp distribution has some flaws: some newer 
built-ins are not known by the syntax highlighting, paredit treats (;) 
similar to CommonLisp comment, I didn't get Ctrl+K working(picolisp 
source/definition lookup, see picolisp in vim or vip.
But those never bothered me enough that I srsly wanted to do something 
about it.

I'm happy as it is.

If the MELPA package supports paredit and the other features of the 
picolisp-mode coming with picolisp, ideally by also supporting the nice 
tools from the vim/vip editors, then I would support to replace the mode 
in picolisp with the MELPA, so to have one unified emacs package for 
picolisp.


If nobody is to be found to ensure that for the MELPA package, then I 
would just leave it as it is now.
Different users might find different versions, but I would not consider 
it impossible or even difficult to get to the things you want.
In the end everyone should use whatever fits that person the best, we 
don't need one way to rule them all.


- beneroth

--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: picolisp-mode

[Jean-Christophe Helary]

> On Jan 22, 2019, at 23:23, Alexander Burger  wrote:
> 
> On Tue, Jan 22, 2019 at 10:41:24PM +0900, Jean-Christophe Helary wrote:
>> The problem is that on Debian (and derivatives) the most recent mode that 
>> Alexis has developed is not available. I discovered that when I found 
>> discrepancies between the mode in raspian and the mode on my Mac when I was 
>> sshing to raspian.
> 
> Yes, that's why I meant I could pack the other version if somebody tells me 
> exactly what is needed. Optimally by sending new files and telling me which 
> ones to replace. Then it will take of course a long time until it propagates 
> through
> the package systems.

Yes, but I wonder if it's necessary to provide this (or any) emacs package since
1) most of the people who use picolisp install it on Linux through a package 
manager and thus have no direct access to the picolisp distribution
2) most emacs users would use the emacs package manager to search for a 
picolisp mode

Maybe it would be better to refer to available packages in the documentation 
and let people use the one they like ?

Jean-Christophe 
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: picolisp-mode

[Alexander Burger]

On Tue, Jan 22, 2019 at 10:41:24PM +0900, Jean-Christophe Helary wrote:
> The problem is that on Debian (and derivatives) the most recent mode that 
> Alexis has developed is not available. I discovered that when I found 
> discrepancies between the mode in raspian and the mode on my Mac when I was 
> sshing to raspian.

Yes, that's why I meant I could pack the other version if somebody tells me
exactly what is needed. Optimally by sending new files and telling me which ones
to replace. Then it will take of course a long time until it propagates through
the package systems.

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: picolisp-mode

[Jean-Christophe Helary]

> On Jan 22, 2019, at 22:04, Manuel Cano  wrote:
> 
> Hi,
> 
> As an Emacs user, it would be nice to have Picolisp package in Debian 
> updated. I use Emacs but I've tweaked some other lisp libs.
> I don't use MELPA either.

The problem is that on Debian (and derivatives) the most recent mode that 
Alexis has developed is not available. I discovered that when I found 
discrepancies between the mode in raspian and the mode on my Mac when I was 
sshing to raspian.

If you have time, give the melpa mode a try, it is available from Github:
https://github.com/flexibeast/picolisp-mode

Jean-Christophe

> 
> Kind regards,
> Manu
> 
> 
> El mar., 22 ene. 2019 a las 10:20, Jean-Christophe Helary 
> (mailto:brandel...@gmail.com>>) escribió:
> 
> 
>> On Jan 22, 2019, at 15:58, Alexander Burger > > wrote:
>> 
>> Hi all,
>> 
>> Or should we change the one in the distribution? I can do that, but as a 
>> non-emacs user I don't know exactly what is needed. So if there is a general 
>> agreement, please let me know what I should do.
> 
> It would be nice to hear from other emacs users.
> 
> If only for the access to documentation at point I would rather use Alexis' 
> mode.
> 
> If there is an agreement on that, I think it would be nice to discuss how we 
> do that. :)
> 
> 
> Jean-Christophe Helary
> ---
> http://mac4translators.blogspot.com  
> @brandelune
> 
> 

Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

Re: picolisp-mode

[Manuel Cano]

Hi,

As an Emacs user, it would be nice to have Picolisp package in Debian
updated. I use Emacs but I've tweaked some other lisp libs.
I don't use MELPA either.

Kind regards,
Manu


El mar., 22 ene. 2019 a las 10:20, Jean-Christophe Helary (<
brandel...@gmail.com>) escribió:

>
>
> On Jan 22, 2019, at 15:58, Alexander Burger  wrote:
>
> Hi all,
>
> Or should we change the one in the distribution? I can do that, but as
> a non-emacs user I don't know exactly what is needed. So if there is a
> general agreement, please let me know what I should do.
>
>
> It would be nice to hear from other emacs users.
>
> If only for the access to documentation at point I would rather use
> Alexis' mode.
>
> If there is an agreement on that, I think it would be nice to discuss how
> we do that. :)
>
>
> Jean-Christophe Helary
> ---
> http://mac4translators.blogspot.com @brandelune
>
>
>

Re: picolisp-mode

[Jean-Christophe Helary]

> On Jan 22, 2019, at 15:58, Alexander Burger  wrote:
> 
> Hi all,
> 
> Or should we change the one in the distribution? I can do that, but as a 
> non-emacs user I don't know exactly what is needed. So if there is a general 
> agreement, please let me know what I should do.

It would be nice to hear from other emacs users.

If only for the access to documentation at point I would rather use Alexis' 
mode.

If there is an agreement on that, I think it would be nice to discuss how we do 
that. :)


Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune