Special Event: Davin reveals his own personal additions to Emacs.

Special Event: Davin reveals his own personal additions to Emacs.

[Davin Pearson]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

Click on the following link to take you to a gallery of Emacs
screenshots showing the hows and whys I have added my own personal
additions to Emacs.

http://davinpearson.nz/screenshots

The most important and probably the most useful customisation that I
have is a drop in replacement for M-y.  Instead of cycling through the
kill ring, it brings up a window showing the kill ring in the order of
the kill ring.  You then click on the ENTER button of paste from the
kill ring to the last buffer you were editing.

In all my code I use the practice of prefixing all of my functions and
variables with <tt>dmp</tt> where DMP stands for Davin Max Pearson
which is my name.  I am unsure of just how useful this practice is for
adding to the Emacs sources.

[-- Attachment #2: Type: text/html, Size: 903 bytes --]

Re: Special Event: Davin reveals his own personal additions to Emacs.

[Philip Kaludercic]

Davin Pearson <davin.pearson@gmail.com> writes:

> The most important and probably the most useful customisation that I
> have is a drop in replacement for M-y.  Instead of cycling through the
> kill ring, it brings up a window showing the kill ring in the order of
> the kill ring.  You then click on the ENTER button of paste from the
> kill ring to the last buffer you were editing.

Since Emacs 28.1 this is done too (unless the last command was `yank'),
just that the selection is made using `completing-read'

Re: Special Event: Davin reveals his own personal additions to Emacs.

[Davin Pearson]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

On Sun, 10 Jul 2022 at 20:56, Philip Kaludercic <philipk@posteo.net> wrote:

> Davin Pearson <davin.pearson@gmail.com> writes:
>
> > The most important and probably the most useful customisation that I
> > have is a drop in replacement for M-y.  Instead of cycling through the
> > kill ring, it brings up a window showing the kill ring in the order of
> > the kill ring.  You then click on the ENTER button of paste from the
> > kill ring to the last buffer you were editing.
>
> Since Emacs 28.1 this is done too (unless the last command was `yank'),
> just that the selection is made using `completing-read'
>

Are you saying that my feature has already been added to Emacs?

[-- Attachment #2: Type: text/html, Size: 1129 bytes --]

Re: Special Event: Davin reveals his own personal additions to Emacs.

[Jean Louis]

* Davin Pearson <davin.pearson@gmail.com> [2022-07-10 06:39]:
> Click on the following link to take you to a gallery of Emacs
> screenshots showing the hows and whys I have added my own personal
> additions to Emacs.
> 
> http://davinpearson.nz/screenshots

Thanks David, those may be useful features for Emacs.

I suggest that you read Emacs Lisp Manual and try understanding how to
make an Emacs package. This is because you have got many features and
other languages combined in package software package. It is better
separating it.

You may evaluate this below:

(info "(elisp) Packaging")

When you start writing Emacs file you better set it up as proper
package that may be installed with M-x package-install-file or M-x
package-install-from-buffer

I may recommend my package to help with it:

Emacs: `package-header.el` your hjälpsam Package Header Assistant: 
https://hyperscope.link/3/7/7/3/0/Your-hjälpsam-Package-Header-Assistant-37730.html

I do understand that you maybe use m4 to insert those package header
snippets. 

In general you do follow the guidelines. Let us say "yes.el", it
misses `provide' on the end, and M-x package-install-from-buffer fails
due to missing headers. Do you really want global scoping there?

File: xyzdmp-reddy.el contains just "sdfsdsdf", is that wanted?

Instead of trying to update all files, I think you should have them
separated by their functionality and make separate packages.

Once packages are ready feel free to send them to this mailing list
for possible inclusion in ELPA. What do you think about it?


Naming issues:
==============

Please note that while it is possible, you should rather name your
modes like `css-mode` to be something else than those already well
common functions in main Emacs. For example, as you said, you could
name it `dmp-css-mode` as your function would overwrite the already
existing `css-mode'in Emacs.


Coding or style issues:
=======================

I do not recommend `progn` standing alone in packages, seetting
load-path and requiring `dotmacs. It is better you prepare package
header properly, that will make your dependencies clear.

`defun` shall placed always after one empty line.

You should not execute programs in packages or files, rather let user
invoke its functions by their will.

Do not hard code paths, like:
"c:/sound-samples/emacs/appt-pause-break.wav" but you should include
such files in the package.tar.gz, read instructions how to do that.

Parenthesis shall end together, not like this:

(defun manifest--log-message (msg)
  (save-excursion
    (set-buffer manifest--buffer)
    (goto-char (point-max))
    (setq latest-file (manifest--get-latest-file))
    (insert msg "\n")
    )
  )

rather like:

(defun manifest--log-message (msg)
  (save-excursion
    (set-buffer manifest--buffer)
    (goto-char (point-max))
    (setq latest-file (manifest--get-latest-file))
    (insert msg "\n")))

`defun' shall rather have its docstring or descriptions.

And other issues. I am sure you may find useful functions for other
users to be published in your new packages.


Installation issues:
====================

You have made Makefile that will probably work on your system only. I
have not tried it, as I am afraid of my file system being changed
capriciously. 


Licensing issues: 
==================

Emacs is licensed under GPL version 3 and later, thus all Emacs
packages that modify Emacs as whole program shall be published shall
be published under compatible license. 

In the package bundle I found only "Copyright (C) 2014-2015 Davin
Pearson" as in the file dmp-css.el. 

And I know you are generating compatible licenses, however, one cannot
just easily draw such conclusion without knowing that you could maybe
do that with m4, it means, at first sight, some users would or could
give up in getting packages.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Special Event: Davin reveals his own personal additions to Emacs.

[Davin Pearson]

[-- Attachment #1: Type: text/plain, Size: 4736 bytes --]

On Sun, 10 Jul 2022 at 23:46, Jean Louis <bugs@gnu.support> wrote:

> * Davin Pearson <davin.pearson@gmail.com> [2022-07-10 06:39]:
> > Click on the following link to take you to a gallery of Emacs
> > screenshots showing the hows and whys I have added my own personal
> > additions to Emacs.
> >
> > http://davinpearson.nz/screenshots
>
> Thanks David, those may be useful features for Emacs.
>

My name is Davin not David.  I get this all  the time.


> I suggest that you read Emacs Lisp Manual and try understanding how to
> make an Emacs package. This is because you have got many features and
> other languages combined in package software package. It is better
> separating it.
>
> You may evaluate this below:
>
> (info "(elisp) Packaging")
>
> When you start writing Emacs file you better set it up as proper
> package that may be installed with M-x package-install-file or M-x
> package-install-from-buffer
>
> I may recommend my package to help with it:
>
> Emacs: `package-header.el` your hjälpsam Package Header Assistant:
>
> https://hyperscope.link/3/7/7/3/0/Your-hjälpsam-Package-Header-Assistant-37730.html
>
> I do understand that you maybe use m4 to insert those package header
> snippets.
>
> In general you do follow the guidelines. Let us say "yes.el", it
> misses `provide' on the end, and M-x package-install-from-buffer fails
> due to missing headers. Do you really want global scoping there?
>
> File: xyzdmp-reddy.el contains just "sdfsdsdf", is that wanted?
>

The purpose of this file is a verify that the syntax-highlighting works.


> Instead of trying to update all files, I think you should have them
> separated by their functionality and make separate packages.
>
> Once packages are ready feel free to send them to this mailing list
> for possible inclusion in ELPA. What do you think about it?
>
>
> Naming issues:
> ==============
>
> Please note that while it is possible, you should rather name your
> modes like `css-mode` to be something else than those already well
> common functions in main Emacs. For example, as you said, you could
> name it `dmp-css-mode` as your function would overwrite the already
> existing `css-mode'in Emacs.
>
>
> Coding or style issues:
> =======================
>
> I do not recommend `progn` standing alone in packages, seetting
> load-path and requiring `dotmacs. It is better you prepare package
> header properly, that will make your dependencies clear.
>
> `defun` shall placed always after one empty line.
>

ok I've got you on this point.

>
> You should not execute programs in packages or files, rather let user
> invoke its functions by their will.
>
> Do not hard code paths, like:
> "c:/sound-samples/emacs/appt-pause-break.wav" but you should include
> such files in the package.tar.gz, read instructions how to do that.
>
> thank you


> Parenthesis shall end together, not like this:
>
> (defun manifest--log-message (msg)
>   (save-excursion
>     (set-buffer manifest--buffer)
>     (goto-char (point-max))
>     (setq latest-file (manifest--get-latest-file))
>     (insert msg "\n")
>     )
>   )
>
> rather like:
>
> (defun manifest--log-message (msg)
>   (save-excursion
>     (set-buffer manifest--buffer)
>     (goto-char (point-max))
>     (setq latest-file (manifest--get-latest-file))
>     (insert msg "\n")))
>

I prefer my own way of doing things, but I might have
a solution  that patches the files automatically before
uploading them.


> `defun' shall rather have its docstring or descriptions.
>
> And other issues. I am sure you may find useful functions for other
> users to be published in your new packages.
>
>
> Installation issues:
> ====================
>
> You have made Makefile that will probably work on your system only. I
> have not tried it, as I am afraid of my file system being changed
> capriciously.
>
>
> Licensing issues:
> ==================
>
> Emacs is licensed under GPL version 3 and later, thus all Emacs
> packages that modify Emacs as whole program shall be published shall
> be published under compatible license.
>
> In the package bundle I found only "Copyright (C) 2014-2015 Davin
> Pearson" as in the file dmp-css.el.
>
> And I know you are generating compatible licenses, however, one cannot
> just easily draw such conclusion without knowing that you could maybe
> do that with m4, it means, at first sight, some users would or could
> give up in getting packages.
>
>
> --
> Jean
>
> Take action in Free Software Foundation campaigns:
> https://www.fsf.org/campaigns
>
> In support of Richard M. Stallman
> https://stallmansupport.org/
>

[-- Attachment #2: Type: text/html, Size: 6681 bytes --]

Re: Special Event: Davin reveals his own personal additions to Emacs.

[Stefan Monnier]

>> Parenthesis shall end together, not like this:
>>
>> (defun manifest--log-message (msg)
>>   (save-excursion
>>     (set-buffer manifest--buffer)
>>     (goto-char (point-max))
>>     (setq latest-file (manifest--get-latest-file))
>>     (insert msg "\n")
>>     )
>>   )
>>
>> rather like:
>>
>> (defun manifest--log-message (msg)
>>   (save-excursion
>>     (set-buffer manifest--buffer)
>>     (goto-char (point-max))
>>     (setq latest-file (manifest--get-latest-file))
>>     (insert msg "\n")))

I dislike those close-parens-on-their-own-lines as well, but more
importantly:
- should use `with-current-buffer`.
- should not `setq` on a global variable that doesn't have an appropriate
  namespace prefix.


        Stefan

Re: Special Event: Davin reveals his own personal additions to Emacs.

[Davin Pearson]

[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]

On Wed, 13 Jul 2022 at 15:08, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> >> Parenthesis shall end together, not like this:
> >>
> >> (defun manifest--log-message (msg)
> >>   (save-excursion
> >>     (set-buffer manifest--buffer)
> >>     (goto-char (point-max))
> >>     (setq latest-file (manifest--get-latest-file))
> >>     (insert msg "\n")
> >>     )
> >>   )
> >>
> >> rather like:
> >>
> >> (defun manifest--log-message (msg)
> >>   (save-excursion
> >>     (set-buffer manifest--buffer)
> >>     (goto-char (point-max))
> >>     (setq latest-file (manifest--get-latest-file))
> >>     (insert msg "\n")))
>
> I dislike those close-parens-on-their-own-lines as well,


I use debugging checkpoints every second line
so the following code cannot be written:

(defun foo ()
   (progn
      (progn
         (zip)
         (message "&apple:1")
         (zap)
         (message "&apple:2")
         (boo)
         (message "&apple:3")
         (bum)
         (message "&apple:4"))))

Because the line (message &apple:4")))) will be deleted
using some code that comments out all debugging checkpoints.
Now that I think of it, I think I could get my code to behave
sensibly in this case... It just adds 1 more layer of intelligence
that I need to write.

> but more

> importantly:
> - should use `with-current-buffer`.
>

is that instead of (set-buffer buf)?


> - should not `setq` on a global variable that doesn't have an appropriate
>   namespace prefix.
>

Do you mean the following is not allowed:

(setq apple 'banana)

but the following code is allowed:

(setq dmp-apple 'banana)

Thanks for your valuable time in helping
to make my code more standards compliant.

[-- Attachment #2: Type: text/html, Size: 3093 bytes --]

Re: Special Event: Davin reveals his own personal additions to Emacs.

[Stefan Monnier]

> I use debugging checkpoints every second line
> so the following code cannot be written:
>
> (defun foo ()
>    (progn
>       (progn
>          (zip)
>          (message "&apple:1")
>          (zap)
>          (message "&apple:2")
>          (boo)
>          (message "&apple:3")
>          (bum)
>          (message "&apple:4"))))

I do use separate lines for closing parens every once in a while, don't
get me wrong.  It's just an exception rather than a rule.
[ Note also that inserting/removing such `message` needs to be different
  for the last element in any case because it determines the return
  value.  ]

>> importantly:
>> - should use `with-current-buffer`.
>
> is that instead of (set-buffer buf)?

If you compile the code, the byte-compiler will give you a warning
suggesting to replace with-current-buffer for save-excursion + set-buffer.

>> - should not `setq` on a global variable that doesn't have an appropriate
>>   namespace prefix.
>>
> Do you mean the following is not allowed:
>
> (setq apple 'banana)
>
> but the following code is allowed:
>
> (setq dmp-apple 'banana)

Neither are recommended without first declaring that global variable
(since that's what it is: a global variable).
And global declarations need to use a proper namespace prefix.
Otherwise you're at risk of stepping on someone else's toes/variables.


        Stefan

Re: Special Event: Davin reveals his own personal additions to Emacs.

[Davin Pearson]

[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]

Is dmp a reasonable prefix for global variables?

I once used my-* for my global variables but abandoned it
when other people started to use my code.

It is rather unlikely that there is a dmp out there in the world today.

Lisp namespaces should be allocated on a first in first served basis,
which is how internet domain names are allocated.



On Thu, 14 Jul 2022 at 13:48, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > I use debugging checkpoints every second line
> > so the following code cannot be written:
> >
> > (defun foo ()
> >    (progn
> >       (progn
> >          (zip)
> >          (message "&apple:1")
> >          (zap)
> >          (message "&apple:2")
> >          (boo)
> >          (message "&apple:3")
> >          (bum)
> >          (message "&apple:4"))))
>
> I do use separate lines for closing parens every once in a while, don't
> get me wrong.  It's just an exception rather than a rule.
> [ Note also that inserting/removing such `message` needs to be different
>   for the last element in any case because it determines the return
>   value.  ]
>
> >> importantly:
> >> - should use `with-current-buffer`.
> >
> > is that instead of (set-buffer buf)?
>
> If you compile the code, the byte-compiler will give you a warning
> suggesting to replace with-current-buffer for save-excursion + set-buffer.
>
> >> - should not `setq` on a global variable that doesn't have an
> appropriate
> >>   namespace prefix.
> >>
> > Do you mean the following is not allowed:
> >
> > (setq apple 'banana)
> >
> > but the following code is allowed:
> >
> > (setq dmp-apple 'banana)
>
> Neither are recommended without first declaring that global variable
> (since that's what it is: a global variable).
> And global declarations need to use a proper namespace prefix.
> Otherwise you're at risk of stepping on someone else's toes/variables.
>
>
>         Stefan
>
>

[-- Attachment #2: Type: text/html, Size: 2698 bytes --]

Re: Special Event: Davin reveals his own personal additions to Emacs.

[Davin Pearson]

[-- Attachment #1: Type: text/plain, Size: 2734 bytes --]

Here are some changes to my earlier email:

It is rather unlikely that there is another dmp who uses Elisp
out there in the world today.

Short of a rewrite of the Elisp code base I recommend that
Lisp namespaces be allocated on a first in first served basis,
which is how internet domain names are allocated.

A more ideal solution would be to borrow Java's package
system into Elisp.  My package name will be nz.davinpearson.
This is a bit unwieldy as it is much easier to use dmp as
the name of my package.  Perhaps someone out there can
come up with a system that combines the tersity of dmp with
the guarantee that you will not be treading on someone
else's code, like how Java does it....

On Thu, 14 Jul 2022 at 14:30, Davin Pearson <davin.pearson@gmail.com> wrote:

> Is dmp a reasonable prefix for global variables?
>
> I once used my-* for my global variables but abandoned it
> when other people started to use my code.
>
> It is rather unlikely that there is a dmp out there in the world today.
>
> Lisp namespaces should be allocated on a first in first served basis,
> which is how internet domain names are allocated.
>
>
>
> On Thu, 14 Jul 2022 at 13:48, Stefan Monnier <monnier@iro.umontreal.ca>
> wrote:
>
>> > I use debugging checkpoints every second line
>> > so the following code cannot be written:
>> >
>> > (defun foo ()
>> >    (progn
>> >       (progn
>> >          (zip)
>> >          (message "&apple:1")
>> >          (zap)
>> >          (message "&apple:2")
>> >          (boo)
>> >          (message "&apple:3")
>> >          (bum)
>> >          (message "&apple:4"))))
>>
>> I do use separate lines for closing parens every once in a while, don't
>> get me wrong.  It's just an exception rather than a rule.
>> [ Note also that inserting/removing such `message` needs to be different
>>   for the last element in any case because it determines the return
>>   value.  ]
>>
>> >> importantly:
>> >> - should use `with-current-buffer`.
>> >
>> > is that instead of (set-buffer buf)?
>>
>> If you compile the code, the byte-compiler will give you a warning
>> suggesting to replace with-current-buffer for save-excursion + set-buffer.
>>
>> >> - should not `setq` on a global variable that doesn't have an
>> appropriate
>> >>   namespace prefix.
>> >>
>> > Do you mean the following is not allowed:
>> >
>> > (setq apple 'banana)
>> >
>> > but the following code is allowed:
>> >
>> > (setq dmp-apple 'banana)
>>
>> Neither are recommended without first declaring that global variable
>> (since that's what it is: a global variable).
>> And global declarations need to use a proper namespace prefix.
>> Otherwise you're at risk of stepping on someone else's toes/variables.
>>
>>
>>         Stefan
>>
>>

[-- Attachment #2: Type: text/html, Size: 4034 bytes --]

Re: Special Event: Davin reveals his own personal additions to Emacs.

[Stefan Monnier]

> Is dmp a reasonable prefix for global variables?

Any prefix is potentially reasonable, yes.

IIUC the code under discussion is an example in a piece of text
discussing ELisp coding style, so which prefix is used doesn't matter,
the important thing is not to set a bad example of code using no prefix
at all.

Given that the example function uses `manifest-` as prefix, I'd
recommend you use `manifest-` as a prefix for the variable as well.

> I once used my-* for my global variables but abandoned it
> when other people started to use my code.

In code which is intended to be shared with other people to use, `my-`
is probably not the best choice, indeed.  But for your own personal
code, `my-` is fine (and if people copy&use that code anyway, it becomes
their own personal code, so `my-` is also fine).

> It is rather unlikely that there is a dmp out there in the world today.

I can definitely imagine someone using `dmp-` as a prefix for some
package, tho I don't know if that's the case currently, indeed.

> Lisp namespaces should be allocated on a first in first served basis,
> which is how internet domain names are allocated.

That's pretty much how it works out, tho allocation is "de facto".


        Stefan

Re: Special Event: Davin reveals his own personal additions to Emacs.

[Stefan Monnier]

> In all my code I use the practice of prefixing all of my functions and
> variables with <tt>dmp</tt> where DMP stands for Davin Max Pearson
> which is my name.

I think it's a fairly common practice.  I tend to use `my-` for that
purpose, hoping that there's a chance we can avoid having someone write
a package that uses this `my-` prefix, whereas it seems unlikely that
noone will ever write a package that uses a prefix which conflicts
with someone's initials.

Maybe we should officially declare the `my-` prefix as reserved for the
end-user.

> I am unsure of just how useful this practice is for adding to the
> Emacs sources.

When distributing code for other people to use, such a "personal prefix"
should be replaced with something else, indeed.


        Stefan

Document that symbol prefix "my-" (or other) should be left for users

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

* 2022-07-10 08:57:16-0400, Stefan Monnier wrote:

> Maybe we should officially declare the `my-` prefix as reserved for the
> end-user.

I support that and proposed it already in 2015-12-13:
<https://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00556.html>.

There is an example documentation patch in the message but some people
opposed the idea and nothing happened.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: Document that symbol prefix "my-" (or other) should be left for users

[Stefan Kangas]

Teemu Likonen <tlikonen@iki.fi> writes:

> I support that and proposed it already in 2015-12-13:
> <https://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00556.html>.
>
> There is an example documentation patch in the message but some people
> opposed the idea and nothing happened.

I tend to agree with John Wiegley here, when he says that it doesn't
really need explicit documentation:

    https://lists.gnu.org/r/emacs-devel/2015-12/msg00608.html

It just seems to be more words added to the ELisp manual for little
benefit.

Re: Document that symbol prefix "my-" (or other) should be left for users

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

Agreed. Not to mention this prefix is not super common - a ton of people user their name, initials, etc. E.g. `boz-my-command`. 

On Sun, Jul 10, 2022, at 7:59 PM, Stefan Kangas wrote:
> Teemu Likonen <tlikonen@iki.fi> writes:
> 
> > I support that and proposed it already in 2015-12-13:
> > <https://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00556.html>.
> >
> > There is an example documentation patch in the message but some people
> > opposed the idea and nothing happened.
> 
> I tend to agree with John Wiegley here, when he says that it doesn't
> really need explicit documentation:
> 
>     https://lists.gnu.org/r/emacs-devel/2015-12/msg00608.html
> 
> It just seems to be more words added to the ELisp manual for little
> benefit.
> 
> 

[-- Attachment #2: Type: text/html, Size: 1445 bytes --]

Re: Document that symbol prefix "my-" (or other) should be left for users

[Tim Cross]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> Agreed. Not to mention this prefix is not super common - a ton of people user their name, initials, etc. E.g. `boz-my-command`. 
>

Yep, I have used my-command and often tx-command  (for my initials x =
cross and yes, not great due to tx/rx being often used for send/receive,
though never been an issue so far).

The other 'convention' I see is my/command or my~command. I do find my/
or tx/ appealing, although I haven't 'switched' to use it.

One possible 'nice' advantage of my- would be that if it was flagged as
a 'personal' or reserved prefix, borrowing customisations and
bits of code from others would potentially be easier to add (but I guess
perhaps that is not necessarily a good thing!).

I'd love to have real namespace support in elisp. Something like Cl
packages or even better, something like Clojure where you can require a
package and specify either a prefix alias used to access symbols from
the package/namespace or a list of 'refer' symbols which can be accessed
without prefix. Anything which could help enable the use of shorter
symbol names and eliminate the need to use prefixes to avoid name
collision would be great. 

Of course, on the other hand, with the exception of longer names, in
over 25 years of Emacs use and especially since the growth in elisp
packages, name collision is something I rarely run into, so the current
status quo does at least seem to work and completion mechanisms have
evolved to make completing with large numbers of candidates having the
same prefix work well and you do tend to get use to the name 'noise'.   

Re: Document that symbol prefix "my-" (or other) should be left for users

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I'd love to have real namespace support in elisp.

The symbol-aliasing feature was supposed to give us that, but a little
more work is needed.  Would anyone like to finish this?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Special Event: Davin reveals his own personal additions to Emacs.

[Clément Pit-Claudel]

On 7/10/22 05:57, Stefan Monnier wrote:
> I think it's a fairly common practice.  I tend to use `my-` for that
> purpose, hoping that there's a chance we can avoid having someone write
> a package that uses this `my-` prefix, whereas it seems unlikely that
> noone will ever write a package that uses a prefix which conflicts
> with someone's initials.
> 
> Maybe we should officially declare the `my-` prefix as reserved for the
> end-user.

I use ~/ (as in `~/kill-this-buffer', for example), since they are my "home" functions.

Re: Special Event: Davin reveals his own personal additions to Emacs.

[Rudolf Adamkovič]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> I use ~/ (as in `~/kill-this-buffer', for example), since they are my
> "home" functions.

I used to use "my-" and "my/" but never liked the misalignment in M-x
and everywhere else.  It almost felt as if extending Emacs was not
something common.

Now, I append "+" to the function name, and I cannot get enough of its
beauty.  The plus denotes "added" by the user.  Examples:

magit-commit-mail-and-news+
org-remove-all-links+

(If we had a standard way to extend Emacs, we could not just provide
certain guarantees to the user [at least per convention] but also some
UI affordances, such as highlighted trailing "+" in M-x and such.)

Rudy
-- 
"I love deadlines.  I love the whooshing noise they make as they go by."
-- Douglas Adams, The Salmon of Doubt, 2002

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: Special Event: Davin reveals his own personal additions to Emacs.

[Davin Pearson]

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

To install these features, download the following file: Do this
even if you already have downloaded the tarball as my new tarball
contains modified code:

http://davinpearson.nz/screenshots/java-training-wheels--bagatelles_20220717-133942.tar.gz

then untar the tarball to your $HOME folder, or any other folder
at your own risk.  Then add the following line of code to your
$HOME/.emacs code:

(load-file "~/java-training-wheels/.emacs")

Start emacs by clicking on the Emacs icon or the command: emacs

On Sun, 10 Jul 2022 at 15:39, Davin Pearson <davin.pearson@gmail.com> wrote:

>
> Click on the following link to take you to a gallery of Emacs
> screenshots showing the hows and whys I have added my own personal
> additions to Emacs.
>
> http://davinpearson.nz/screenshots
>
> The most important and probably the most useful customisation that I
> have is a drop in replacement for M-y.  Instead of cycling through the
> kill ring, it brings up a window showing the kill ring in the order of
> the kill ring.  You then click on the ENTER button of paste from the
> kill ring to the last buffer you were editing.
>
> In all my code I use the practice of prefixing all of my functions and
> variables with <tt>dmp</tt> where DMP stands for Davin Max Pearson
> which is my name.  I am unsure of just how useful this practice is for
> adding to the Emacs sources.
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1956 bytes --]

Document that symbol prefix "my-" (or other) should be left for users

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

It seems to me that Emacs users often use "my-" prefix or person's
initials (like "tl-" or "tl/") as prefix when writing their private
extensions and configuration. However, there is no officially documented
prefix which Emacs promises to leave for users. So I suggest making such
promise and documenting it in info page "(elisp) Coding Conventions"
(example patch below).

What is suitable prefix? It should be short. "my-" and "user-" are
already used somewhere.


--8<---------------cut here---------------start------------->8---
commit 526387c4d62f06d932f7885cc4f047a0fa255381
Author: Teemu Likonen <tlikonen@iki.fi>
Date:   2015-12-13 19:58:57 +0200

    tips.texi: Document that symbol prefix `my-' is for users

diff --git a/doc/lispref/tips.texi b/doc/lispref/tips.texi
index ffce920..37186c6 100644
--- a/doc/lispref/tips.texi
+++ b/doc/lispref/tips.texi
@@ -89,6 +89,9 @@ Coding Conventions
 If one prefix is insufficient, your package can use two or three
 alternative common prefixes, so long as they make sense.
 
+Finally, prefix @code{my-} should be reserved for users, their private
+features and configuration. Don't use it in public packages.
+
 @item
 Put a call to @code{provide} at the end of each separate Lisp file.
 @xref{Named Features}.
--8<---------------cut here---------------end--------------->8---

-- 
/// Teemu Likonen   - .-..   <https://github.com/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

RE: Document that symbol prefix "my-" (or other) should be left for users

[Drew Adams]

> It seems to me that Emacs users often use "my-" prefix or person's
> initials (like "tl-" or "tl/") as prefix when writing their private
> extensions and configuration.

Yes.  As in any other language.

> However, there is no officially documented prefix which Emacs
> promises to leave for users.

Right.  As for any other language (?).

> So I suggest making such promise and documenting it in info
> page "(elisp) Coding Conventions"

Why?  What is the problem for which this would be a good solution?

Are you afraid that someone will create a function or variable
with prefix `my-', and that a user who uses that code will be
precluded from defining the same name, or that if s?he defines
another name that uses the same prefix s?he will be confused?

Did you encounter a real problem in this area?

Re: Document that symbol prefix "my-" (or other) should be left for users

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

Drew Adams [2015-12-13 10:32:20-08] wrote:

>> So I suggest making such promise and documenting it in info
>> page "(elisp) Coding Conventions"
>
> Why?  What is the problem for which this would be a good solution?

> Did you encounter a real problem in this area?

I have had zero problems but it's also near-zero effort to decide a
prefix, document it and obey it. And yes, it's for avoiding name
conflicts: so that user's configuration won't harm future Emacs
functionality, nor the other way around.

But it's just a suggestion. I'm not going to have a month long
discussion about this. So just ignore it. :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Document that symbol prefix "my-" (or other) should be left for users

[John Wiegley]

>>>>> Teemu Likonen <tlikonen@iki.fi> writes:

> I have had zero problems but it's also near-zero effort to decide a prefix,
> document it and obey it. And yes, it's for avoiding name conflicts: so that
> user's configuration won't harm future Emacs functionality, nor the other
> way around.

> But it's just a suggestion. I'm not going to have a month long
> discussion about this. So just ignore it. :-)

I appreciate the effort, Teemu, but I don't think it needs explicit
documentation. The only package that could conceivably use "my-" as a prefix
would have to be called "my", otherwise it's in violation of other Emacs
coding standards. At that point, a user who uses such a "my" package can
either choose not to (to preserve the "my-" namespace for themselves), or
request that the author change its name.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Document that symbol prefix "my-" (or other) should be left for users

[Tassilo Horn]

John Wiegley <jwiegley@gmail.com> writes:

>> I have had zero problems but it's also near-zero effort to decide a
>> prefix, document it and obey it. And yes, it's for avoiding name
>> conflicts: so that user's configuration won't harm future Emacs
>> functionality, nor the other way around.
>
>> But it's just a suggestion. I'm not going to have a month long
>> discussion about this. So just ignore it. :-)
>
> I appreciate the effort, Teemu, but I don't think it needs explicit
> documentation. The only package that could conceivably use "my-" as a
> prefix would have to be called "my", otherwise it's in violation of
> other Emacs coding standards.

There are some packages which have a long name and then use a short
abbreviation for (parts of) their functions and variables.  For example,
the `ace-window' package defines functions and variables with the
prefixes ace-* and aw-* (the latter mostly for "private" stuff).  At
least the aw-* symbols could easily clash with Anton Wiegley's private
stuff.

I just picked `ace-window' from the top of my head.  I'm pretty sure
there are more packages which use some abbreviation of their name as
prefix.

Despite clashes, such abbreviations make those packages also less
discoverable using the normal auto-completion features C-h f/v.

Bye,
Tassilo

Re: Document that symbol prefix "my-" (or other) should be left for users

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

On Tue, Dec 15, 2015 at 1:22 PM, Tassilo Horn <tsdh@gnu.org> wrote:

> There are some packages which have a long name and then use a short
> abbreviation for (parts of) their functions and variables.  For example,
> the `ace-window' package defines functions and variables with the
> prefixes ace-* and aw-* (the latter mostly for "private" stuff).  At
> least the aw-* symbols could easily clash with Anton Wiegley's private
> stuff.
>

How about reserving '/' as the user prefix delimiter and '-' as the package
prefix delimiter?  Then Anton Wiegley's aw/foo will never conflict with
ace-window's aw-foo.

/john

[-- Attachment #2: Type: text/html, Size: 1098 bytes --]

RE: Document that symbol prefix "my-" (or other) should be left for users

[Drew Adams]

> How about reserving '/' as the user prefix delimiter and '-'
> as the package prefix delimiter?  Then Anton Wiegley's aw/foo
> will never conflict with ace-window's aw-foo.

Again, why?  Why reserve any prefix for users?  We haven't yet
yet seen a reason.  (This is quite different from key-binding
prefixes, IMO.)

Re: Document that symbol prefix "my-" (or other) should be left for users

[John Wiegley]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

> Again, why? Why reserve any prefix for users? We haven't yet yet seen a
> reason. (This is quite different from key-binding prefixes, IMO.)

Drew has a point. How about we wait until there's some instance of the problem
in the wild that needs us to document such a convention? There's been a lot of
time for this to become an issue, and it hasn't yet.

Even then, it would only ever be a convention: we can't stop authors from
naming their symbols however they want -- except for those that are proposed
to Emacs or ELPA, where a "my-" prefix would already raise the necessary
eyebrows.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Document that symbol prefix "my-" (or other) should be left for users

[Evans Winner]

John Wiegley <jwiegley@gmail.com> writes:

     Drew has a point. How about we wait until there's some
     instance of the problem in the wild that needs us to
     document such a convention? There's been a lot of time
     for this to become an issue, and it hasn't yet.

For what it's worth, it's happened to me, but a long time
ago and I don't remember what function name I stepped on.
If it's happened to me, I would guess it's happened to other
people.  Creating a name clash isn't a bug in Emacs, so why
would I (or anyone else) report it?  So if it's happening,
it might not be something that would come up on the radar
here very often.  I finally discovered what I'd done and
jsut renamed my function.

Short of giving Elisp a package system like Common Lisp, it
seems that the solution is just to make sure your personal
prefix is complex enough that it is unlikely to be
duplicated in other people's code.

Re: Document that symbol prefix "my-" (or other) should be left for users

[John Wiegley]

>>>>> Evans Winner <ego111@gmail.com> writes:

> For what it's worth, it's happened to me, but a long time ago and I don't
> remember what function name I stepped on. If it's happened to me, I would
> guess it's happened to other people. Creating a name clash isn't a bug in
> Emacs, so why would I (or anyone else) report it? So if it's happening, it
> might not be something that would come up on the radar here very often. I
> finally discovered what I'd done and jsut renamed my function.

Good point, Evans. Perhaps it occurs more often than we realize.

I'm not sure a convention will result in it never happening again, in the same
way that key mapping conventions have not stopped various packages from
stomping on bindings that were reserved to me as a user.

Perhaps we could recommend that users consider their init file to be a sort of
package, and thus use a `.emacs-' prefix for their symbols, as they might when
writing any other package.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Document that symbol prefix "my-" (or other) should be left for users

[David Reitter]

On Dec 13, 2015, at 1:32 PM, Drew Adams <drew.adams@oracle.com> wrote:
> 
>> It seems to me that Emacs users often use "my-" prefix or person's
>> initials (like "tl-" or "tl/") as prefix when writing their private
>> extensions and configuration.
> 
> Yes.  As in any other language.

Which language would that be?

The vast majority of modern languages have some form of scoping that determines the namespace for global-like variables, often with several levels of hierarchy.

RE: Document that symbol prefix "my-" (or other) should be left for users

[Drew Adams]

> >> It seems to me that Emacs users often use "my-" prefix or person's
> >> initials (like "tl-" or "tl/") as prefix when writing their private
> >> extensions and configuration.
> >
> > Yes.  As in any other language.
> 
> Which language would that be?

Ok, you got me.

So can you give a reason why Emacs-Lisp coding conventions
should reserve such a prefix (or any other) for users?
Haven't heard any reason, so far.

Re: Document that symbol prefix "my-" (or other) should be left for users

[Chad Brown]

> On 15 Dec 2015, at 17:26, Drew Adams <drew.adams@oracle.com> wrote:
> 
> So can you give a reason why Emacs-Lisp coding conventions
> should reserve such a prefix (or any other) for users?
> Haven't heard any reason, so far.

I have seen people run into conflicts several times (over a long
time frame). At MIT, many students started out with simple
lisp functions added to a mostly-plain emacs. Eventually, they’d
add packages, and occasionally hit conflicts. A convention of
user/function-name would have avoided all of those.

This was in the time before package.el became widespread, so I
believe that packages are added to emacs far more often now than
they were then. Of course, back then, MIT’s intro CS class was
based on Scheme, so probably there are fewer people writing
personal lisp into nearly-empty .emacs files these days.

So: if you want to know if it has ever happened: absolutely. I don’t
know if this sort of thing comes up much anymore; MIT students’
experience doesn’t involve emacs nearly as much these days as it did
back then.

Hope that helps,
~Chad

RE: Document that symbol prefix "my-" (or other) should be left for users

[Drew Adams]

> > So can you give a reason why Emacs-Lisp coding conventions
> > should reserve such a prefix (or any other) for users?
> > Haven't heard any reason, so far.
> 
> I have seen people run into conflicts several times (over a
> long time frame)...  So: if you want to know if it has ever
> happened: absolutely.

The question I raised is not whether users have run into name
conflicts but why Emacs coding conventions should reserve any
given name prefix (or prefixes?) for users.

Users can run into name conflicts also if they use the same
"reserved" prefix `my-' (or `my/' or `my31459265358979535/'
or whatever).

Re: Document that symbol prefix "my-" (or other) should be left for users

[Chad Brown]

> On 15 Dec 2015, at 17:52, Drew Adams <drew.adams@oracle.com> wrote:
> 
>>> So can you give a reason why Emacs-Lisp coding conventions
>>> should reserve such a prefix (or any other) for users?
>>> Haven't heard any reason, so far.
>> 
>> I have seen people run into conflicts several times (over a
>> long time frame)...  So: if you want to know if it has ever
>> happened: absolutely.
> 
> The question I raised is not whether users have run into name
> conflicts but why Emacs coding conventions should reserve any
> given name prefix (or prefixes?) for users.
> 
> Users can run into name conflicts also if they use the same
> "reserved" prefix `my-' (or `my/' or `my31459265358979535/'
> or whatever).

Specifically, I’ve seen users run into name conflicts with things
like ABC-function where ABC was both a shortened package reference
and a user’s initials. Many packages use AB- or ABC- as a package
prefix. Many users use AB/ or ABC/ as a user-specific prefix. I’ve never
seen those swapped (personally).

~Chad