From: Jesper Harder <harder@ifa.au.dk>
Subject: Re: Orphaned symbols?
Date: Fri, 13 Feb 2004 04:24:52 +0100 [thread overview]
Message-ID: <m3u11viruj.fsf@defun.localdomain> (raw)
In-Reply-To: <m38yj884jg.fsf@hamster.pflaesterer.de> (Karl =?iso-8859-1?q?Pfl=E4sterer's?= message of "Thu, 12 Feb 2004 22:03:44 +0100")
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.
next prev parent reply other threads:[~2004-02-13 3:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-10 20:28 Karl Pflästerer
2004-02-12 14:03 ` Reiner Steib
2004-02-12 21:03 ` Karl Pflästerer
2004-02-12 22:02 ` Reiner Steib
2004-02-13 3:24 ` Jesper Harder [this message]
2004-02-13 21:25 ` Karl Pflästerer
2004-02-13 22:16 ` Jesper Harder
2004-02-13 23:11 ` Karl Pflästerer
2004-02-14 18:23 ` Kai Grossjohann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3u11viruj.fsf@defun.localdomain \
--to=harder@ifa.au.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 NNTP newsgroup(s).