You using Pansymbolic: examples

You're writing a few Emacs packages. You've picked promising names for the packages and their symbols.

But do these symbols already exist somewhere?

You had a high-level view of what Pansymbolic is. Let's look closer.

Using Pansymbolic — examples for new packages

So you want to publish some packages.

Package #1: participle

Pansymbolic collects all elisp symbols. It slurps any and all packages out there to populate its extensive and growing database of symbols.

Your first package:

  • is called participle.
  • has one elisp file called participle.el.
  • has a few variables and functions, all of which start with participle-.

In summary, it's a standard, "well-behaved" package.

It does this sort of thing:

(participle-en "go")    => "gone"
(participle-nl "gaan")  => "gegaan"
(participle-de "gehen") => "gegangen"
(participle-fr "aller") => "allé"

Very well. Can you use these symbols?

(pansymbolic-pre-packs "participle") => nil

It found no symbol starting with participle followed (or not) by some separator (a dash, a slash, or some other punctuation).

So you're good to go.

You finish the package, release v0.1.0, and push it to a new public repository.

You submit it to Pansymbolic:

(pansymbolic-submit-package "https://git.sr.ht/~awesome-person-you/participle")

Behind the scenes, that's a simple POST request. Alternative submission methods exist (open a ticket, send an email). It all ends up in the same place.

The database is periodically updated. So soon afterwards you query it again. Lo and behold:

(pansymbolic-pre-packs "participle") => '(participle)

So now there's a package called participle that has at least one function starting with participle followed (or not) by a separator. That's you!

You now list the symbols in different ways:

(pansymbolic-pre-syms-htbl "participle")
H=> (h* "participle" (h* "-" (h* "-"  (h* "all" (h* :@ '(participle)))
                                 "de" (h* :@ '(participle))
                                 "en" (h* :@ '(participle))
                                 "fr" (h* :@ '(participle))
                                 "nl" (h* :@ '(participle)))))
(pansymbolic-pre-syms-list "participle")
=> '("participle" (participle--all
                   participle-de
                   participle-en
                   participle-fr
                   participle-nl))
(pansymbolic-pre-syms-tree "participle")
=> "\
participle
└─ -
   ├─ -
   │  └─ all  :@ participle
   ├─ de      :@ participle
   ├─ en      :@ participle
   ├─ fr      :@ participle
   └─ nl      :@ participle"

That's your package alright.

You check the info:

(pansymbolic-pack-info "participle")
H=> (h* :package    "participle"
        :author     "Awesome Person You"
        :maintainer "Awesome Person You"
        :url "https://git.sr.ht/~awesome-person-you/participle")

You now check your next package.

Package #2: lm

Your second package:

  • is called lm.
  • has one elisp file called lm.el.
  • has a couple of functions only, starting with lm-.

Another standard, "well-behaved" package.

It's about laminations. Or something.

You check:

(pansymbolic-pre-packs "lm") => '(lisp-mnt)

Huh.

(pansymbolic-pack-info :url "lisp-mnt")
=> '("https://git.savannah.gnu.org/cgit/emacs.git/plain/lisp/emacs-lisp/lisp-mnt.el")

Right! Of course. That's a native package.

You could query Pansymbolic again, but here it's easier to just open lisp-mnt.el.gz.

Which you do: lots of functions starting with lm-.

Your functions have nothing to do with those. So it's unlikely that it'd be a problem.

But... you see no good reason for this potential confusion.

So you check:

(pansymbolic-pre-packs "laminate") => nil

No symbol anywhere prefixed with laminate. You go with that.

You rename the package and the functions.

You finish it, release v0.1.0, and push it to a new public repository.

You submit it to Pansymbolic:

(pansymbolic-submit-package "https://git.sr.ht/~awesome-person-you/laminate")

You now check your next package.

Package #3: current

You have a small package that does calculations about electrical current.

You want to name it current; it will, naturally, have functions starting with current-.

You check:

(pansymbolic-pre-packs "current")
=> '(EMACS-PRIMITIVES
     current-window-only
     current-word-highlight)

In principle, the last two don't seem to be a problem.

You check the primitives. They're things like current-buffer and current-time.

Hmm. Might be ok, but... not ideal. Your current-power could end up being independently named by Emacs to, I don't know, check the battery power or something?

Seems better to change. You'll think of another name.

So you move on and check your next package.

Package #4: smart

That's a common word, so you start with a check:

(pansymbolic-pre-packs "smart")
=> '(smart-backspace
     smart-comment
     smart-compile
     smart-cursor-color
     smart-dash
     smart-delete
     smart-forward
     smart-hungry-delete
     smart-indent-rigidly
     smart-jump
     smart-mark
     smart-mode-line
     smart-mode-line-atom-one-dark-theme
     smart-mode-line-powerline-theme
     smart-newline
     smart-region
     smart-semicolon
     smart-shift
     smart-tab
     smart-tabs-mode
     smart-window)

Ok, so all these packages define symbols starting with smart followed (or not) by some separator.

Your package has only two functions: smart-backward and smart-again.

They don't show up in the list, so they probably won't collide, but... you check:

(pansymbolic-pre-packs "smart-backward") => '(smart-forward)

So the package smart-forward defines some function that starts with smart-backward followed (or not) by a separator.

You list that package's functions:

(pansymbolic-pack-syms-list "smart-forward")
=> '(smart--er-try-list-without-inside
     smart--name-contains-inside-p
     smart--only-letters-in-region
     smart-backward
     smart-down
     smart-forward
     smart-up)

So although that package is called smart-forward, its symbols have smart- as their longest common prefix.

Hmm. You rename your package to smart-go and your functions to smart-go-backward and smart-go-again.

Solved.

You finish it, release v0.1.0, and push it to a new public repository.

You submit it to Pansymbolic:

(pansymbolic-submit-package "https://git.sr.ht/~awesome-person-you/smart-go")

Package #6: rollercoaster

You absolutely love the name of your new package. It's perfect for the thing it does, whatever it is.

(pansymbolic-pre-packs "rollercoaster") => '(roller-coaster)

Really?

You look up the info. You check the package out.

It happens to be a small package with four functions starting with rollercoaster- (no hyphen in the middle, unlike the package name!) completely unrelated to anything your package does. Its last update goes back to a remote past when Six Flags wasn't a thing yet. You decide that the probability that this will ever become a problem is about zero.

Yet there's an email address there — so, out of courtesy, you reach out to the maintainer and explain the situation. You get a reply:

No problem! I wrote this a long time ago, it's not important. Few users other than me, I guess. I'm unlikely to update it again, much less add new functions. Maybe I should obsolete them to rename and add a dash in the middle? I don't know. Regardless, go ahead, there'll be no confusion. Thanks for reaching out!

You make a new friend, you keep the name you wanted, and everybody's happy.

You finish it, release v0.1.0, and push it to a new public repository.

You submit it to Pansymbolic:

(pansymbolic-submit-package "https://git.sr.ht/~awesome-person-you/rollercoaster")

You soon check it again:

(pansymbolic-pre-packs "rollercoaster") => '(rollercoaster roller-coaster)

So both these packages have symbols prefixed with rollercoaster — but none of the symbols collide and it's not a problem.

Package #7: er

Doctors are always eager to use Emacs whenever they want to make life-or-death decisions about patients in emergency rooms. Or at least that's what you thought when you started writing er, your new package:

(er-sedate-p :bp-s 13 :bp-d 9 :temp-C 40) => 7   ; not a boolean? fix that bug!

You check the prefix:

(pansymbolic-pre-packs "er") => '(expand-region)

Oh, right. But wait a minute:

(pansymbolic-pre-packs "er/")  => '(expand-region)
(pansymbolic-pre-packs "er-")  => '(expand-region)
(pansymbolic-pre-packs "er--") => '(expand-region)

(pansymbolic-rx-packs "^er-[^-]") => nil

Ok, so it only has functions starting with er/ and er-- but none with only er- (one dash).

And yours only has that last kind. Hmm.

But no no, that's quite a stretch. You're not attached to er, and there's no good justification for that.

So you check for a replacement:

(pansymbolic-pre-packs "eroom") => nil

Good.

You rename it to eroom and change all prefixes accordingly.

You finish it, release v0.1.0, and push it to a new public repository.

You submit it to Pansymbolic:

(pansymbolic-submit-package "https://git.sr.ht/~awesome-person-you/eroom")

You now check your next package.

Package #8: org-something

A typical org package.

(pansymbolic-pre-packs "org")           => '(<hundreds of packages...>)
(pansymbolic-pre-packs "org-something") => nil

Looks good.

You finish it, release v0.1.0, and push it to a new public repository.

You submit it to Pansymbolic:

(pansymbolic-submit-package "https://git.sr.ht/~awesome-person-you/org-something")

You now check your next package.

Package #9: global

You're concerned about global warming, so you wrote this to show temperatures around the globe.

You search and:

(pansymbolic-pre-packs "global") => '(<hundreds of packages...>)

What?

Oh, of course. Every call to define-globalized-minor-mode creates a global-something-mode.

Collisions unlikely, but... unnecessary confusion. You add a note to think about a better name.

You wake up the next day thinking that warming would be just fine. So you check:

(pansymbolic-pre-packs "warming") => nil

Looks good.

You finish it, release v0.1.0, and push it to a new public repository.

You submit it to Pansymbolic:

(pansymbolic-submit-package "https://git.sr.ht/~awesome-person-you/warming")

You get the idea

Basically:

  • You come up with a name you like
  • You check, with a simple command, whether that name prefixes some function from some package somewhere
    • if it's all clear, you go ahead
    • otherwise, it depends — but you err on the side of finding another one
  • You finish the first version
  • You check it again (just in case)
  • You push it to a new git repo
  • You submit the repo link to Pansymbolic
  • Pansymbolic verifies that it's an elisp package — then adds it
  • Everyone can now see it exists

Package and its symbols registered soon and painlessly — collisions prevented.

Get involved.