unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* Understanding internal use functions
@ 2019-05-06  4:15 Paul W. Rankin
  2019-05-06  7:29 ` Tassilo Horn
  0 siblings, 1 reply; 4+ messages in thread
From: Paul W. Rankin @ 2019-05-06  4:15 UTC (permalink / raw)
  To: Help Gnu Emacs mailing list

Hello,

I saw this in the Elisp manual:

> By convention, if a function’s symbol consists of two names separated
> by ‘--’, the function is intended for internal use and the first part
> names the file defining the function.  For example, a function named
> ‘vc-git--rev-parse’ is an internal function defined in ‘vc-git.el’.
> Internal-use functions written in C have names ending in ‘-internal’,
> e.g., ‘bury-buffer-internal’.  Emacs code contributed before 2018 may
> follow other internal-use naming conventions, which are being phased
> out.
(info "(elisp) Function Names")

How should I decide whether a function is for internal use, as opposed 
to just another function?

A command, i.e. (commandp FUNCTION) -> t, is interactive and so clearly 
not intended for internal use, but I assume this does not mean all 
non-interactive functions should be considered internal use?

It seems easier for internal use variables; if the user changes the 
`this--internal-variable' then the program may not work. Functions leave 
me a bit more bewildered... Or should I just think of it in the same 
way, e.g. "don't run this function yourself or you'll break things"?

--
https://www.paulwrankin.com



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Understanding internal use functions
  2019-05-06  4:15 Understanding internal use functions Paul W. Rankin
@ 2019-05-06  7:29 ` Tassilo Horn
  2019-05-07  3:07   ` Paul W. Rankin
  0 siblings, 1 reply; 4+ messages in thread
From: Tassilo Horn @ 2019-05-06  7:29 UTC (permalink / raw)
  To: Paul W. Rankin; +Cc: Help Gnu Emacs mailing list

"Paul W. Rankin" <hello@paulwrankin.com> writes:

Hi Paul,

> How should I decide whether a function is for internal use, as opposed
> to just another function?
>
> A command, i.e. (commandp FUNCTION) -> t, is interactive and so clearly not
> intended for internal use, but I assume this does not mean all non-interactive
> functions should be considered internal use?

Obviously not!

> It seems easier for internal use variables; if the user changes the
> `this--internal-variable' then the program may not work. Functions
> leave me a bit more bewildered... Or should I just think of it in the
> same way, e.g. "don't run this function yourself or you'll break
> things"?

This applies to any function or variable, e.g., activate lisp-mode (a
command) in a JavaScript file, or set auto-mode-alist to "Hello world".
That just doesn't make sense and won't work but of course they are
non-internal nevertheless.

Internal functions/variables usually convey the meaning of "don't rely
on me because I might change whenever my author likes".  So it's more a
hint to programmers than to users.

For users, internal functions and variables are usually invisible
because they are never commands or customizable variables.

Bye,
Tassilo



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Understanding internal use functions
  2019-05-06  7:29 ` Tassilo Horn
@ 2019-05-07  3:07   ` Paul W. Rankin
  2019-05-07  9:57     ` Tassilo Horn
  0 siblings, 1 reply; 4+ messages in thread
From: Paul W. Rankin @ 2019-05-07  3:07 UTC (permalink / raw)
  To: Tassilo Horn; +Cc: Help Gnu Emacs mailing list


On Mon, May 06 2019, Tassilo Horn wrote:
>> It seems easier for internal use variables; if the user changes the
>> `this--internal-variable' then the program may not work. Functions
>> leave me a bit more bewildered... Or should I just think of it in the
>> same way, e.g. "don't run this function yourself or you'll break
>> things"?
>
> This applies to any function or variable, e.g., activate lisp-mode (a
> command) in a JavaScript file, or set auto-mode-alist to "Hello 
> world".
> That just doesn't make sense and won't work but of course they are
> non-internal nevertheless.
>
> Internal functions/variables usually convey the meaning of "don't rely
> on me because I might change whenever my author likes".  So it's more 
> a
> hint to programmers than to users.

So I should name a functions as internal as a way to imply "hey don't 
use this in other programs" (for whatever reason)?

-- 
https://www.paulwrankin.com



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Understanding internal use functions
  2019-05-07  3:07   ` Paul W. Rankin
@ 2019-05-07  9:57     ` Tassilo Horn
  0 siblings, 0 replies; 4+ messages in thread
From: Tassilo Horn @ 2019-05-07  9:57 UTC (permalink / raw)
  To: Paul W. Rankin; +Cc: Help Gnu Emacs mailing list

"Paul W. Rankin" <hello@paulwrankin.com> writes:

>> Internal functions/variables usually convey the meaning of "don't
>> rely on me because I might change whenever my author likes".  So it's
>> more a hint to programmers than to users.
>
> So I should name a functions as internal as a way to imply "hey don't
> use this in other programs" (for whatever reason)?

Yes.  And inversely, if you've written a public (non-internal) function
in your package, better assume that someone somewhere is already using
it in her config, so don't change its interface if not absolutely
necessary.

Bye,
Tassilo



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2019-05-07  9:57 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-05-06  4:15 Understanding internal use functions Paul W. Rankin
2019-05-06  7:29 ` Tassilo Horn
2019-05-07  3:07   ` Paul W. Rankin
2019-05-07  9:57     ` Tassilo Horn

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).