RE: Icicles stealing keybindings

[Drew Adams <drew.adams@oracle.com>]

> I'll try to sit down and find the right set of options for wget to
> download only the Icicles-related pages from the wiki (I guess I
> could also leverage the fact that Emacs Wiki runs on Oddmuse, which
> means I can easily get the list of all pages and filter by the string
> "Icicles").  Then, converting to epub/mobi is easy with calibri.

My advice is to not do anything with the wiki content until it is
brought back in working order.  Apparently there are some pages there
now that are not up-to-date - perhaps from an old cache (dunno).

Apparently this has meant also that some MELPA files that are
mirrored from the wiki have been thrown back a year or so in date.

In sum, wait for the wiki to be fixed, before accessing its pages in
any serious way, and perhaps before downloading stuff from MELPA
whose source is the wiki.  I'm told that it is perhaps a matter of
waiting only a few more days.

> > The `finder'-accessed doc of some of my libraries, such as Icicles
> > and Bookmark+, also provides for navigation using simple hyperlinks
> > provided by library `linkd.el', if you happen to have that
> > installed.
> 
> Wow.  That sounds really interesting.

`linkd.el' is very simple.  It does not do the things that, say,
Org mode does with hyperlinking.  But it is good enough for the use
I mentioned.

> So do I get it right that finder just formats the docstrings and/or
> comments?  Wow.  I'll look into it someday.

It uses only the `Commentary' portion of a file.  It does not use doc
strings or comments in general.

> > (There is now a long list of outstanding doc bugs.)
> 
> Is it available somewhere online?

http://debbugs.gnu.org/ provides access to all of the Emacs bugs
(well, all of those since a few years back, when the bug tracker
was used by Emacs Dev for the first time).  I can't help with
sorting or searching for only doc bugs, I'm afraid.  Perhaps
"doc" in the subject line will help.

> > To "get" Emacs is to understand the usefulness and power of a
> > program that communicates with you about itself, that opens itself
> > freely and completely.  It includes understanding the importance
> > software freedom and of, yup, doc.
> >
> > It is no accident that Emacs was the *starting point* and remains
> > at the core of the "free" approach to using and developing
> > software.  And it is no accident that RMS concentrated so much of
> > his energy on its ability to talk to you about itself - its doc, in
> > particular.
> 
> Those remarks are /very/ interesting.  I will share this with a few
> of my friends and students.

Keep in mind that those remarks are just one person's judgment/opinion.

> Coming back to the "If you can, and you would like to, help with
> that incipient effort, everyone would appreciate it" and "There too,
> there is always room for improvement" parts, here are my thoughts.
> 
> I'd love to, especially with the docs.  (Also, possibly with coding,
> though I'm only a hobbyist programmer.)  I like writing (and
> tinkering with what I wrote).  (I don't want to boast too much, so
> I'l try to keep the boasting part short: I have a blog updated weekly
> (currently mostly about Emacs), I wrote two master's theses and one
> doctoral dissertation, my first book (in English, on mathematics) is
> currently under peer review, my second book (in Polish, on LaTeX,
> with a coauthor) is currently being written, and I have plans to
> write a third one (again in English).  So I guess that while I'm not
> G.K. Chesterton, still my credentials as far as writing goes /might/
> be above the median.)

I don't think that any credentials or any special background are
needed, to help fix Emacs bugs or otherwise contribute to Emacs.
Look at a bug, send in a patch for it - that's about it, AFAIK.
People like Eli will help & guide you if need be.

> I could even learn bzr, though now that Emacs is in git, it would be
> much easier for me (especially with Magit).  I mean: this or that
> versioning system isn't a big deal.
> 
> But - and this is a very big "but" - there is a huge barrier to
> entry, in my case probably insurmountable.  The FSF copyright
> agreement.  Most probably, I won't sign it /ever/, for various
> reasons.  One is that the text of the agreement is not available
> online.  I strongly oppose such anti-openness (and find it very
> strange, especially that FSF claims that it is about openness),
> and may not sign it /just because of this/. Another one is that I
> am not sure whether the agreement is even valid under my jurisdiction.
> (American and Polish - in general, European - copyright laws are
> much different, though IANAL.)  Yet another one (much less
> important) is that (assuming the ATM unlikely scenario that I
> leave academia and start working in IT) I am not at all sure whether
> having signed the FSF papers would not decrease my hiring chances.

I can't speak to such concerns.  I know next to nothing about the
legal aspects.  The FSF has lawyers and others who can probably
help.  Whether they have people expert in both Polish and US law,
I don't know.  But they've been dealing with this question for a
long time now.

See section `Copyright Assignment' in file .../etc/CONTRIBUTE.

One of these discussion threads might also help a bit:
http://lists.gnu.org/archive/html/emacs-devel/2013-02/msg00102.html
http://lists.gnu.org/archive/html/emacs-devel/2014-03/msg01217.html
http://lists.gnu.org/archive/html/emacs-devel/2010-08/msg00223.html

Otherwise, you might try writing to emacs-devel@gnu.org or
assign@gnu.org or rms@gnu.org, expressing your concerns & questions.

Your help is surely welcome.  And you might not find the hurdles
as high as you think, wrt legal matters.  You are certainly not the
first person to ponder the question.  But the decision is an
individual one, of course.