Orphaned symbols?

Orphaned symbols?

[Karl Pflästerer]

Hi,
recently I noticed by accident that the variable
`gnus-article-check-size' is mentioned exactly once in the Gnus source
code: in its defvar form.  That seems to indicate it's not used anymore.

I got nosy and searched for variable names which were not used anywhere
in the code.  I found 93 names (and some more functions).  Before I post
all these names in which libraries do I also have to look for usage of
variables?  I can't believe that so much variables should be garbage.



   KP

-- 
"But it has nothing to do with what a _value_ is.  This has to do with
whether you pass whatever-a-value-is or wherever-whatever-is-a-value-is
whenever you pass an argument to a function.  (Call it the Shakira
theory. :)"    [Erik Naggum in cllisp über call-by-value und call-by-reference]

Re: Orphaned symbols?

[Reiner Steib]

On Tue, Feb 10 2004, Karl Pflästerer wrote:

> I got nosy and searched for variable names which were not used anywhere
> in the code.  I found 93 names (and some more functions).  

Huh, this number seems quite high.

> Before I post all these names in which libraries do I also have to
> look for usage of variables?

I'd suggest to post the list, maybe someone has a glue about their
potential usage in other packages.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Orphaned symbols?

[Karl Pflästerer]

On 12 Feb 2004, Reiner Steib <- 4.uce.03.r.s@nurfuerspam.de wrote:

> On Tue, Feb 10 2004, Karl Pflästerer wrote:

>> I got nosy and searched for variable names which were not used anywhere
>> in the code.  I found 93 names (and some more functions).  

> Huh, this number seems quite high.

I thought this also.

>> Before I post all these names in which libraries do I also have to
>> look for usage of variables?

> I'd suggest to post the list, maybe someone has a glue about their

Did you think glueing the vars makes any difference? :-)

> potential usage in other packages.

Okay here we go (there are some version variables; I include them also
just to be complete).
These are 32 variables which are not boundp in my current XEmacs Gnus
session.  Maybe if I used some of the backends they would be boundp.
That would make sense at least for the version variables so I think they
can be safely ignored.

The other variables are boundp I write them afterwards; at
least boundp doesn't mean the variable gets used in some way or another.

(I wanted to attach the file but that was not possible; I have to check
why but first have to do a cvs up.  XEmacs just seems to be in an
endless loop).

***************************** Not boundp ***************************
binhex-body-line -> binhex.el
binhex-end-line -> binhex.el
gnus-carpal-browse-buffer-buttons -> gnus-salt.el
gnus-carpal-group-buffer-buttons -> gnus-salt.el
gnus-carpal-server-buffer-buttons -> gnus-salt.el
gnus-carpal-summary-buffer-buttons -> gnus-salt.el
gnus-outlook-deuglify-version -> deuglify.el
gnus-picon-setup-p -> gnus-picon.el
gnus-tree-line-format-alist -> gnus-salt.el
gnus-tree-mode-line-format-alist -> gnus-salt.el
gnus-tree-mode-line-format-spec -> gnus-salt.el
gnus-uu-shar-file-name -> gnus-uu.el
mml1991-decrypt-function -> mml1991.el
mml1991-verify-function -> mml1991.el
nnagent-version -> nnagent.el
nnbabyl-version -> nnbabyl.el
nndb-version -> nndb.el
nndir-version -> nndir.el
nndoc-version -> nndoc.el
nneething-version -> nneething.el
nnimap-version -> nnimap.el
nnkiboze-version -> nnkiboze.el
nnmaildir--novlen -> nnmaildir.el
nnmaildir-version -> nnmaildir.el
nnmbox-version -> nnmbox.el
nnrss-version -> nnrss.el
nnsoup-version -> nnsoup.el
nnspool-version -> nnspool.el
nnwarchive-version -> nnwarchive.el
rfc1843-old-gnus-decode-header-function -> rfc1843.el
uudecode-body-line -> uudecode.el
uudecode-end-line -> uudecode.el
********************************************************************


************************* Boundp ***********************************

gnus-agent-file-header-cache -> gnus-agent.el
gnus-article-check-size -> gnus.el
gnus-article-mode-line-format-alist -> gnus-art.el
gnus-article-mode-line-format-spec -> gnus-spec.el
gnus-button-last -> gnus-art.el
gnus-button-regexp -> gnus-art.el
gnus-category-line-format -> gnus-agent.el
gnus-category-line-format-alist -> gnus-agent.el
gnus-category-mode-line-format -> gnus-agent.el
gnus-category-mode-line-format-alist -> gnus-agent.el
gnus-category-mode-line-format-spec -> gnus-agent.el
gnus-cited-closed-text-button-line-format-alist -> gnus-cite.el
gnus-current-copy-group -> gnus-sum.el
gnus-current-crosspost-group -> gnus-sum.el
gnus-current-move-group -> gnus-sum.el
gnus-ephemeral-group-server -> gnus-group.el
gnus-face-0 -> gnus-spec.el
gnus-face-1 -> gnus-spec.el
gnus-face-2 -> gnus-spec.el
gnus-face-3 -> gnus-spec.el
gnus-face-4 -> gnus-spec.el
gnus-group-line-format-alist -> gnus-group.el
gnus-group-mode-line-format-alist -> gnus-group.el
gnus-maintainer -> gnus.el
gnus-mouse-face-0 -> gnus-spec.el
gnus-mouse-face-1 -> gnus-spec.el
gnus-mouse-face-2 -> gnus-spec.el
gnus-mouse-face-3 -> gnus-spec.el
gnus-mouse-face-4 -> gnus-spec.el
gnus-newsgroup-none-id -> gnus-sum.el
gnus-server-line-format-alist -> gnus-srvr.el
gnus-server-mode-line-format-alist -> gnus-srvr.el
gnus-server-mode-line-format-spec -> gnus-srvr.el
gnus-summary-dummy-line-format-alist -> gnus-sum.el
gnus-summary-line-format-alist -> gnus-sum.el
gnus-summary-mode-line-format-spec -> gnus-spec.el
gnus-topic-indentation -> gnus.el
gnus-topic-line-format-alist -> gnus-topic.el
gnus-use-generic-from -> gnus.el
ietf-drums-dot-atext-token -> ietf-drums.el
ietf-drums-qtext-token -> ietf-drums.el
ietf-drums-quote-token -> ietf-drums.el
ietf-drums-specials-token -> ietf-drums.el
mail-source-imap-authenticators -> mail-source.el
mail-source-imap-streams -> mail-source.el
message-mode-syntax-table -> message.el
news-reply-yank-from -> nnheader.el
news-reply-yank-message-id -> nnheader.el
nndraft-version -> nndraft.el
nnfolder-version -> nnfolder.el
nnheader-numerical-full-files -> nnheader.el
nnmh-version -> nnmh.el
nnml-version -> nnml.el
nntp-version -> nntp.el
nnvirtual-version -> nnvirtual.el
pgg-armor-header-lines -> pgg-parse.el
pgg-fetch-key-function -> pgg.el
pgg-messages-coding-system -> pgg-def.el
pgg-status-buffer -> pgg-def.el
smiley-mouse-map -> smiley.el
********************************************************************


   KP

-- 
   Mary had a little lambda,
   Its syntax white as snow,
   And every program Mary wrote,
   She wrote in Lisp, you know.

Re: Orphaned symbols?

[Reiner Steib]

On Thu, Feb 12 2004, Karl Pflästerer wrote:

> On 12 Feb 2004, Reiner Steib <- 4.uce.03.r.s@nurfuerspam.de wrote:
[...]
>> I'd suggest to post the list, maybe someone has a glue about their
>
> Did you think glueing the vars makes any difference? :-)

:-)

[...]
> nnagent-version -> nnagent.el
[...]
> nnwarchive-version -> nnwarchive.el

These might make sense.  Also for other *-version variables below.

> gnus-face-0 -> gnus-spec.el
[...]
> gnus-face-4 -> gnus-spec.el

Needed for %{...%} e.g. in `gnus-summary-line-format', see (info
"(gnus)Formatting Fonts").

> gnus-mouse-face-0 -> gnus-spec.el
[...]
> gnus-mouse-face-4 -> gnus-spec.el

Same here.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Orphaned symbols?

[Jesper Harder]

sigurd@12move.de (Karl Pflästerer) writes:

> Okay here we go (there are some version variables; I include them
> also just to be complete).  These are 32 variables which are not
> boundp in my current XEmacs Gnus session.  Maybe if I used some of
> the backends they would be boundp.  That would make sense at least
> for the version variables so I think they can be safely ignored.
>
> The other variables are boundp I write them afterwards; at least
> boundp doesn't mean the variable gets used in some way or another.

I don't think these are used:

* gnus-picon-setup-p -> gnus-picon.el
* gnus-uu-shar-file-name -> gnus-uu.el
* mml1991-decrypt-function -> mml1991.el
* mml1991-verify-function -> mml1991.el
* rfc1843-old-gnus-decode-header-function -> rfc1843.el
* uudecode-body-line -> uudecode.el
* uudecode-end-line -> uudecode.el
* gnus-agent-file-header-cache -> gnus-agent.el
* gnus-article-check-size -> gnus.el
* gnus-button-last -> gnus-art.el
* gnus-button-regexp -> gnus-art.el
* gnus-current-copy-group -> gnus-sum.el
* gnus-current-crosspost-group -> gnus-sum.el
* gnus-current-move-group -> gnus-sum.el
* gnus-ephemeral-group-server -> gnus-group.el
* gnus-newsgroup-none-id -> gnus-sum.el
* gnus-topic-indentation -> gnus.el
* gnus-use-generic-from -> gnus.el
* news-reply-yank-from -> nnheader.el
* news-reply-yank-message-id -> nnheader.el
* nnheader-numerical-full-files -> nnheader.el
* pgg-armor-header-lines -> pgg-parse.el
* pgg-fetch-key-function -> pgg.el
* pgg-messages-coding-system -> pgg-def.el
* pgg-status-buffer -> pgg-def.el
* smiley-mouse-map -> smiley.el

But it's not necessarily trivial to tell, because you can reference a
variable by constructing the name dynamically -- that's the case for
some of the ones you listed.

These aren't actually used:

| ietf-drums-dot-atext-token -> ietf-drums.el
| ietf-drums-qtext-token -> ietf-drums.el
| ietf-drums-quote-token -> ietf-drums.el
| ietf-drums-specials-token -> ietf-drums.el

but it makes sense to keep them.  They were probably included to
define all the BNF tokens in the RFC.

Re: Orphaned symbols?

[Karl Pflästerer]

On 13 Feb 2004, Jesper Harder <- harder@ifa.au.dk wrote:

> I don't think these are used:

[Variables]

> But it's not necessarily trivial to tell, because you can reference a
> variable by constructing the name dynamically -- that's the case for
> some of the ones you listed.

Yes; especially in gnus-article that's used heavily (the functions are
defined with out gnus- prefix and it's added somewhere); not very nice.

> These aren't actually used:

> | ietf-drums-dot-atext-token -> ietf-drums.el
> | ietf-drums-qtext-token -> ietf-drums.el
> | ietf-drums-quote-token -> ietf-drums.el
> | ietf-drums-specials-token -> ietf-drums.el

> but it makes sense to keep them.  They were probably included to
> define all the BNF tokens in the RFC.

Is there no possibility to decide which variables could safely be
deleted?  Some of the vars I found aren't used anywhere; they make it
only harder to understand the code.  I also find a bunch of functions
which are only defined but never used (for them it's even harder to
decide if they don't get somewhere defined dynamically).  If we never
try to find them we will have garbage in the code.


   KP

-- 
If you have nothing to say on a subject, replying with a line such as,
"I agree with this." puts you in the TO:'s for all future messages, and
establishes you as "one who really cares", if not an actual expert, on
the topic at hand.         -- from the Symbolics Guidelines for Sending Mail

Re: Orphaned symbols?

[Jesper Harder]

sigurd@12move.de (Karl Pflästerer) writes:

> Is there no possibility to decide which variables could safely be
> deleted?  Some of the vars I found aren't used anywhere; they make it
> only harder to understand the code.  I also find a bunch of functions
> which are only defined but never used

I think the variables I listed are safe to delete.  But in general I
don't think there's any way to determine it automatically.

For example the function `mm-file-name-collapse-whitespace' isn't used
anywhere -- but its purpose is that you can add it to the hook
`mm-file-name-rewrite-functions', so it clearly shouldn't be removed.

Re: Orphaned symbols?

[Karl Pflästerer]

On 13 Feb 2004, Jesper Harder <- harder@ifa.au.dk wrote:

> sigurd@12move.de (Karl Pflästerer) writes:

>> Is there no possibility to decide which variables could safely be
>> deleted?  Some of the vars I found aren't used anywhere; they make it
>> only harder to understand the code.  I also find a bunch of functions
>> which are only defined but never used

> I think the variables I listed are safe to delete.  But in general I
> don't think there's any way to determine it automatically.

ACK.  Because of that I posted them here instead of a big patch :-)

Maybe we could try it in small steps; always delete 5 wait some days and
remove the next 5.

> For example the function `mm-file-name-collapse-whitespace' isn't used
> anywhere -- but its purpose is that you can add it to the hook
> `mm-file-name-rewrite-functions', so it clearly shouldn't be removed.

Yes with functions it gets even harder to decide which one aren't used
anymore.


   KP

-- 
 `Beware the Jabberwock, my son!
     The jaws that bite, the claws that catch!
  Beware the Jubjub bird, and shun
    The frumious Bandersnatch!'   "Lewis Carroll" "Jabberwocky"

Re: Orphaned symbols?

[Kai Grossjohann]

Jesper Harder <harder@ifa.au.dk> writes:

> * gnus-current-copy-group -> gnus-sum.el
> * gnus-current-crosspost-group -> gnus-sum.el
> * gnus-current-move-group -> gnus-sum.el

I suggest to keep these -- if my understanding is correct that they
are intended to be used in hooks and suchlike.

Kai