[MC]: better FAQ. was: zip issues, ftp wants, and others

[Peter Masiar <peter masiar yale edu>]

Quoting Pavel Roskin <proski gnu org>:

> > First, simple suggestions:

> > (2) can we display URL of MC homepage, *and* URL of MC FAQ,
> > in many places, like:
> >    * email footer in this list
> >    * first help page (at least as text)
> > I downloaded MC for Win from some freeware site, and was not aware
> > it is part of GNOME and has homepage. 
>
> MC is not part of GNOME.  GNOME hosts our mailing lists and CVS
> repository.  

OK. MC's homepage mentions GNOME and URL is on GNOME. 
Rest are technical niceties. ;-)

Don't you think it will be usefull for newcomers here, 
if email footer has a link to MC homepage and FAQ? And archives?

Or for newbies, if first help page has MC URL, too?
Don't you think it will be usefull for newbie users?

> > (3) At MC homepage, can we place link to FAQs into more prominent place?
> I agree, the homepage needs more work.

Just simple reorder: put para3 first (what MC is), screenshots, FAQ
and HOW-TOs first (for newbies). Then, technical stuff for gurus.
Use [H2] FAQ [/H2] to make FAQ more visible. Not much of work, IMHO.

> > (4) FAQ is huge plain text file.  At least table of contens should be
> > clickable. I propose to convert text to POD (perl docs) format, and then
> > to HTML. I can do it. And add more HOW-TOs... ;-)
>
> FAQ doesn't represent the questions that are often asked now.  The problem
> with excessive documentation is that we put too much strain on people
> changing the code - they have to update too much documentation.

OK. I propose to create new FAQ and keep also link to old one.

> The documentation should be more consolidated and less overlapping.  FAQ
> in HTML would be good - most developers know HTML.  More exotic formats
> will lead to obsolete documentation.  We used to have the manual sources
> in SGML, and some developers were updating the manual, not the source.  
> Finally the SGML file was removed because resynchronizing it with the
> changes manual would be too much work.

I just volunteered to be doc maintainer. Did you notice? ;-)

If developers are swamped, somebody else might help with docs. That's me.

My idea is, I can write first draft of docs, and then gurus
can fix misunderstandings.
Obviously, gurus cannot ask stupid questions. 
We need beginners for that... ;-)

> > (5) I am playing with colors. Looking into archives, it is FAQ. (and it
> > helped me - thank you guys.) I may add some questions/answers as I learn
> > something. Currently I am trying to set a "white theme" - with white
> > background, for ssh terminal. Having every color option at new line
> > would help a lot... 8-(
>
> I agree.  It's is TODO already.
>
> > (6) About forgetting F-keys:
> >
> > This bug bite me, too, before I realized what is going on. Bad news,
> > this bug will bite a novice when just experimenting with MC - and might
> > scare her away from MC forever.
>
> Also in TODO.

How do you plan to handle that?

This bug desperately needs to go into FAQs or HOW-TOs. 
Again: I can do that....

Maybe you can decide, which fixes are "critical", and rest can wait
until next release.

> > Maybe keys/colors should be in another .ini file, saved only by request?
>
> We have one single "Auto save setup" option.  Splitting it means remaking 
> the dialog and changing the documentation.

What about if I'll do docs, you'll do dialog? ;-)

Yeah, now I recall. Exactly as in NC... ;-)
I disabled Autosave and it works better (for what I want) now.

Thank you,
Peter