help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: A question about cycle-spacing--context


From: Drew Adams
Subject: RE: A question about cycle-spacing--context
Date: Sun, 25 Jan 2015 16:38:48 -0800 (PST)

> Here's what I found in the definition of cycle-spacing:
> (cons n (cons orig-pos (buffer-substring start (point))))
> Is there any particular reason for using this instead of just
> (list n orig-pos (buffer-substring start (point)))?

No, not that I can see.

> (Of course, the results are formally different, but functionally
> the same, and in the current implementation, thus defined
> cycle-spacing--context is not even a "proper", nil-terminated
> list!) I understand that the current implementation saves memory

> So, my question is: (1) why is that so and (2) would it be a good
> practice to employ such an idea in my own code?  (I suppose the
> answers are (1) why not? and (2) no, but I'd like to ask anyway.)

I think you are asking whether and when it makes sense to use
dotted lists in your own code.  If so, the answer lies in what you
use the possibly dotted list for.

If you expect to be able to use list operations (e.g. `mapcar')
on it then the answer is generally no.  If you are using it as
a simple, large (many conses) alist, especially one that is
created anew often, then the answer might be "Why not?"

The answer is to look at how it is being used in your code and
judge whether it is convenient or inconvenient etc.

FWIW, I probably would not have bothered to use a dotted list
in this case.  But there is nothing really wrong with doing so.

For clarity, I'd say start by using proper lists, and change
to a dotted list here or there if you find a good reason to
do so.

> Also, this is yet another time I see a symbol with two consecutive
> dashes.  This might be a naive question, but is there any convention
> used here that I do not know of?

Some of the Emacs developers like to use `--' to indicate an
"internal" function, variable or whatever, by which is meant only
that its implementation is not guaranteed not to change (which is
anyway true of any function, var or whatever!).  You can take it
as a hint that if you write code that uses such an "internal"
thingy then you are on your own if and when an Emacs release
changes its use or behavior.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]