James Carlson wrote:
> Roland Mainz writes:
> > > As an architectural matter, I don't buy that story.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Erm, I missed that line...
> > ... from an architectural viewpoint I agree with you. But as I said
> > /usr/bin/man needs more fixes and when I start working on fixing
> > /usr/bin/man I'd like to make an "inception review" (or how it's really
> > called) and then start doing a full revamp. It may need some time (and I
> > am not sure how much time it needs since I have to find a normal job
> > first and do that project in my free time) and I really would prefer
> > that the people here start opening their hearts for the end-users and
> > try to get some small improvements done _now_. It's architecturally not
> > correct but it would help lots of the end-users. Remeber these cases are
> > about _usuablity_ which is difficult to measure with a "foot rule" or
> > other physical tools...
>
> It's not an issue of "opening [our] hearts." Please don't pretend as
> though the folks reviewing your proposal are hostile to users. That's
> just not the case, and it makes it very difficult to comment
> rationally on the proposal.
Erm... no no... this wasn't thought to accuse ARC of being a heartless
26-headed monster which eats cooked end-users ("...each meeting a
different recipe...") ... :-)
... the idea was to try to remind people to think like beginners and/or
end-users. Most people subscribed to opensolaris-arc@&co. work with
shells for many many years and can quickly handle problems and ignore
minor hiccups almost automatically by typing another key. For the
beginners these "hiccups" (like setting an editor mode manually via $
set -o gmacs #) are horrible things which are black magic, written down
on papers glued on the left/right side on the monitor, usually like
"<s><e><t><space><-><o><space><g><m><a><c><s><enter>. Response is a new
line and a "$" and a blinking square. If the respose is anything else
call the admin, number is 7950090". They usually do not even know what
the command does. Even <CTRL-L> to refresh the current line is "magic"
for them (which may not be obvious for more experienced users who no
longer see this as the "wonder of the shell" ...) ...
> The concern I have is that the proposed solution may well be at odds
> with a better solution. In other words, suppose we do go with your
> proposal to set MANPATH exactly once during shell start-up, based on
> the PATH at that point. If the user changes his PATH, MANPATH won't
> get those changes. But that's just life with environment variables.
Technically only those users change PATH or MANPATH who are familar
enougth with the shell and _know_ what the change may affect.
> If we later come along and enhance /usr/bin/man so that it searches
> the ../bin parallels of PATH, but only when MANPATH is unset (in order
> to honor compatibility), then the proposed "fix" from this project
> will actually get in the way and will need to be undone -- somehow.
>
> So, why produce a poor answer when a better one is possible?
What about the resource "manpower" ? If I take on /usr/bin/man then I
want to do a complete overhaul of that thing and not a half solution.
For example it makes me unhappy that the manual pages are in a
DocBook-like format but /usr/bin/man exposes zero features of Docbook to
the end-users (and the intermediate generation of troff files causes
trouble with tables, non-ASCII charatcers, transliteration, embedded
code examples etc.).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
