[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New DFSG-compliant emacs packages



Le jeudi 26 octobre 2006 23:45, David Kastrup a écrit :

> > These days, I wouldn't encourage people to try Emacs.  It's not
> > nonsense, it's my opinion.
> 
> There is no LaTeX editing environment with even half the functionality
> of AUCTeX available, in particular if you develop .dtx files, write
> math-heavy material or need to work with utf-8 texts.

Not everyone use Emacs for LaTex editing and I'd bet even half the
AUCTeX functionality would be just enough for their daily usage.
Hey, it's just like Emacs :-)

> > You don't share it. Fair enough.
> 
> I don't quite understand the rationale to include software into Debian
> that you don't want people to use.

There are many old time Emacs users who happen to be Debian users
as well.

> >> > Experienced users know Emacs enough to get along without its
> >> > documentation,
> >> 
> >> Again, this is utter nonsense.  I am an active Emacs developer and
> >> maintainer of AUCTeX, and such can hardly be called inexperienced,
> >> and I frequently need the documentation.
> >
> > Currently the lisp reference is not even provided by Emacs.
> 
> As a developer, I use the developer version of Emacs which contains
> the Elisp reference, and for good reason.  The only piece of the
> documentation that I don't use regularly is the Elisp tutorial.  And
> that is reasonably independent from Emacs that it would actually make
> sense of its own in a separate, independent package.
> 
> > And I bet you can use Emacs for everyday's tasks without it's user
> > guide.
> 
> Without knowing how to configure it?  Hardly.

I mean *you* old time Emacs user, of course.

> >> > and when they need it they know where to find it.
> >> 
> >> And another piece of nonsense.  Being an experienced User of Emacs
> >> does not imply being experienced with the Debian packaging system
> >> and the outpours of the DFSG guidelines.
> >
> > Nothing to do with it. They can even read the manual from gnu.org.
> 
> Uh, no, they can't.  Because C-h K C-t will not lead to the "manual
> from gnu.org".  Nor will using the hyperlinks spread throughout the
> documentation, like

C-h K C-t does not lead to the manual, it leads to doc strings.
FYI, C-h keybindings still work after moving manuals to non-free.
Don't we have a misunderstanding?

> M-x customize-variable RET help-char RET
> 
> (or pretty much any variable) which starts off with two hyperlinks
> explaining customization and customization files.
>
...
> > It _does_ provide a lecture of it: when people have to grab packages
> > from non-free, they get de facto warned about what is problematic
> > toward licensing.  Emacs is free software, it's documentation is
> > not.
> 
> Sure, since the FSF uses different criteria for essential freedoms of
> software and essential freedoms for documentation (the FSF public
> licenses are a mixture of freedoms and restrictions, designed to
> promulgate freedom overall, by putting restraints on what you can do
> with the product).  Debian does not differentiate, in contrast.  But
> the Emacs code and the Emacs documentation are not as separable as
> this is the case with, say, gcc.  gcc does not have commands that
> break when the documentation is not installed.

Please tell me about commands that lead to the manual, not doc strings.
AFAIK, doc strings are still around after the split. I'm still looking for
breakages you are talking about.

> >> There is no sense in providing only a partly functional part in
> >> main.  And it is misleading to not prominently point this out, in
> >> startup message, and in the name of the package
> >> (emacs21-without-docs or emacs21-only-dfsg or similar).  Otherwise,
> >> people will reasonably expect that the package contains a
> >> packaging/compilation of Emacs in the extent delivered by the FSF.
> >
> > No, they won't expect that because package descriptions as well as
> > changelogs and copyright files are informative enough for them to
> > understand.
> 
> Most people don't look at more than the package name when installing
> things.

apt-listchanges is quite popular, you know. Don't underestimate users.

-- 
Jérôme Marant



Reply to: