arevert-xtra.texi xref gremlin

arevert-xtra.texi xref gremlin

[Kevin Ryde]

[-- Attachment #1: Type: text/plain, Size: 176 bytes --]

2007-04-03  Kevin Ryde  <user42@zip.com.au>

	* arevert-xtra.texi (Supporting additional buffers): Correction to
	@xref, node name and description args were wrong way around.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: arevert-xtra.texi.xref-fix.diff --]
[-- Type: text/x-diff, Size: 801 bytes --]

*** arevert-xtra.texi	12 Mar 2007 10:17:26 +1100	1.4
--- arevert-xtra.texi	02 Apr 2007 16:08:21 +1000	
***************
*** 103,110 ****
  support for auto-reverting new types of buffers.
  
  To support auto-reverting the buffer must first of all have a
! @code{revert-buffer-function}.  @xref{Definition of
! revert-buffer-function,, Reverting, elisp, the Emacs Lisp Reference Manual}.
  
  In addition, it @emph{must} have a @code{buffer-stale-function}.
  
--- 103,110 ----
  support for auto-reverting new types of buffers.
  
  To support auto-reverting the buffer must first of all have a
! @code{revert-buffer-function}.  @xref{Reverting,, Definition of
! revert-buffer-function, elisp, the Emacs Lisp Reference Manual}.
  
  In addition, it @emph{must} have a @code{buffer-stale-function}.
  

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: arevert-xtra.texi xref gremlin

[Luc Teirlinck]

Kevin Ryde wrote:


   2007-04-03  Kevin Ryde  <user42@zip.com.au>

	   * arevert-xtra.texi (Supporting additional buffers): Correction to
	   @xref, node name and description args were wrong way around.

No, the original is correct and your suggested change is wrong.
This is an @xref to an anchor named
"Definition of revert-buffer-function" and *not* to the top of the node
"Reverting".

Why did you believe that there was something wrong?  What trouble did
you run into?

Sincerely,

Luc Teirlinck.

Re: arevert-xtra.texi xref gremlin

[Kevin Ryde]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
>
> This is an @xref to an anchor named "Definition of
> revert-buffer-function"

Oops, yep.

> Why did you believe that there was something wrong?

Pressing return to follow it didn't work (no such node or anchor).
But I see this may be the debian snapshot somehow broken.  Now I try
the actual cvs it seems ok :(.

Re: arevert-xtra.texi xref gremlin

[David Kastrup]

Kevin Ryde <user42@zip.com.au> writes:

> Luc Teirlinck <teirllm@dms.auburn.edu> writes:
>>
>> This is an @xref to an anchor named "Definition of
>> revert-buffer-function"
>
> Oops, yep.
>
>> Why did you believe that there was something wrong?
>
> Pressing return to follow it didn't work (no such node or anchor).
> But I see this may be the debian snapshot somehow broken.

Debian puts the various Emacs' flavors in different subdirectories in
info, and breaks two thirds of the links in that process.

But since it is likely that they are going to remove the manuals
completely in future (due to them being GFDL), it is probably nothing
worth worrying about.

-- 
David Kastrup

Re: arevert-xtra.texi xref gremlin

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Tue, 03 Apr 2007 08:48:13 +0200
> Cc: Luc Teirlinck <teirllm@dms.auburn.edu>, emacs-devel@gnu.org
> 
> But since it is likely that [Debian] are going to remove the manuals
> completely in future (due to them being GFDL)

They already did: at least one Debian user told me in some forum (I
think gnu.emacs.help) that "C-h F" and "C-h K" didn't work because the
manuals were not there.

Re: arevert-xtra.texi xref gremlin

[Romain Francoise]

Eli Zaretskii <eliz@gnu.org> writes:

> They already did: at least one Debian user told me in some forum
> (I think gnu.emacs.help) that "C-h F" and "C-h K" didn't work
> because the manuals were not there.

C-h F and C-h K are new in Emacs 22, and the Emacs 22 package in
Debian (emacs-snapshot) ships all the manuals (for the time being).

Perhaps that user was running Emacs 21, in which case those keys
wouldn't reach the manual anyway.

Re: arevert-xtra.texi xref gremlin

[Eli Zaretskii]

> From: Romain Francoise <romain@orebokech.com>
> Date: Tue, 03 Apr 2007 11:48:17 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > They already did: at least one Debian user told me in some forum
> > (I think gnu.emacs.help) that "C-h F" and "C-h K" didn't work
> > because the manuals were not there.
> 
> C-h F and C-h K are new in Emacs 22

Yes.  The person who told me that used the v21.x equivalents "C-h C-f"
and "C-h C-k".  This doesn't change the essence of the problem, which
is that Emacs 21 was shipped without documentation.

> and the Emacs 22 package in
> Debian (emacs-snapshot) ships all the manuals (for the time being).

If they did that once, and on purpose, they can do it again.

Re: arevert-xtra.texi xref gremlin

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Romain Francoise <romain@orebokech.com>
>> Date: Tue, 03 Apr 2007 11:48:17 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > They already did: at least one Debian user told me in some forum
>> > (I think gnu.emacs.help) that "C-h F" and "C-h K" didn't work
>> > because the manuals were not there.
>> 
>> C-h F and C-h K are new in Emacs 22
>
> Yes.  The person who told me that used the v21.x equivalents "C-h C-f"
> and "C-h C-k".  This doesn't change the essence of the problem, which
> is that Emacs 21 was shipped without documentation.

I think it was just because they fscked up when sorting things into
directories.  IIRC, the files were there, just not found.

>> and the Emacs 22 package in Debian (emacs-snapshot) ships all the
>> manuals (for the time being).
>
> If they did that once, and on purpose, they can do it again.

The maintainer of emacs-snapshot has already stated that he will no
longer update this package since he is not willing to rip out the
documentation and thus does not feel he can follow Debian policies
here.

Apart from the licensing issue, Emacs is one of the most thoroughly
ruined packages by Debian.  No Emacs and XEmacs developers understand
what Debian does, neither does Emacs/XEmacs itself
(list-load-path-shadows comes up with hundreds of entries), few people
see capable of creating an Elisp package for the system.

The purported advantage is that one needs only one Elisp package for
all flavors of Emacs (emacs21, emacs22, XEmacs) and can install things
in parallel.

There is also a half-baked solution for keeping the documentation in
parallel, and it leads to many manual links not working.

In short: Emacs/XEmacs under Debian are mostly broken, including the
documentation.

Removing the documentation does not make them much more broken.

-- 
David Kastrup

Re: arevert-xtra.texi xref gremlin

[Stefan Monnier]

>> But since it is likely that [Debian] are going to remove the manuals
>> completely in future (due to them being GFDL)

> They already did: at least one Debian user told me in some forum (I
> think gnu.emacs.help) that "C-h F" and "C-h K" didn't work because the
> manuals were not there.

Emacs on Debian has always been split into several packages.  The GFDL burp
caused them to refine the split such that the doc is now in a separate
package placed in the "non-free" section.

~-0% dpkg -l 'emacs21*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name                     Version    Description
+++-========================-==========-======================================================================
ii  emacs21                  21.4a+1-3  The GNU Emacs editor
ii  emacs21-bin-common       21.4a+1-3  The GNU Emacs editor's shared, architecture dependent files
ii  emacs21-common           21.4a+1-3  The GNU Emacs editor's shared, architecture independent infrastructure
ii  emacs21-common-non-dfsg  21.4a+1-1  GNU Emacs shared, architecture independent, non-DFSG items
ii  emacs21-el               21.4a+1-3  GNU Emacs LISP (.el) files
un  emacs21-nox              <none>     (no description available)

IIRC they also recently voted to consider GFDL'd manuals as free at the
condition that they do not add any extra clause.

In any case, the problem of Debian's multi-version support with info files
is unrelated to the GFDL.  And we can blame Debian all we want, but I don't
think we have many alternatives to offer.  Info is just currently not very
good at dealing with such problems.


        Stefan

Re: arevert-xtra.texi xref gremlin

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> Apart from the licensing issue, Emacs is one of the most thoroughly
> ruined packages by Debian.  No Emacs and XEmacs developers understand
> what Debian does

The last time I enquired, the debian-emacs people didn't actually
understand what it was doing either...

-Miles

-- 
Everywhere is walking distance if you have the time.  -- Steven Wright

Re: arevert-xtra.texi xref gremlin

[Davi Leal]

Miles Bader wrote:
> David Kastrup <dak@gnu.org> writes:
> > Apart from the licensing issue, Emacs is one of the most thoroughly
> > ruined packages by Debian.  No Emacs and XEmacs developers understand
> > what Debian does
>
> The last time I enquired, the debian-emacs people didn't actually
> understand what it was doing either...

Maybe it could be good idea the emacs developers, who are experts at this
topic, sent a quick email to debian, listing the 'improvements' to be
realized to the package.

I as debian and emacs user would like it.

Filling a bug would get an extra bonus, bugs.debian.org

Davi

Re: arevert-xtra.texi xref gremlin

[David Kastrup]

Davi Leal <david@leals.com> writes:

> Miles Bader wrote:
>> David Kastrup <dak@gnu.org> writes:
>> > Apart from the licensing issue, Emacs is one of the most thoroughly
>> > ruined packages by Debian.  No Emacs and XEmacs developers understand
>> > what Debian does
>>
>> The last time I enquired, the debian-emacs people didn't actually
>> understand what it was doing either...
>
> Maybe it could be good idea the emacs developers, who are experts at this
> topic, sent a quick email to debian, listing the 'improvements' to be
> realized to the package.
>
> I as debian and emacs user would like it.
>
> Filling a bug would get an extra bonus, bugs.debian.org

It is sort of pointless trying to fix broken links to manuals that
Debian is going to remove.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: arevert-xtra.texi xref gremlin

[Stefan Monnier]

> It is sort of pointless trying to fix broken links to manuals that
> Debian is going to remove.

Again: they're not completely removed, just moved to a separate package in
the non-free section.  So it's far from pointless.

I find it funny that Debian's "vrms" lists emacs21-common-non-dfsg ("vrms"
is the "Virtual RMS" which lists the non-free packages installed on your
system).  At least if they want to keep the "GFDL is not free" principle,
they should either rename vrms, or fix it to abide by Richard's
own principles.


        Stefan

Re: arevert-xtra.texi xref gremlin

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> IIRC they also recently voted to consider GFDL'd manuals as free at
> the condition that they do not add any extra clause.

And any front and back covers.  It was somewhat unclear what it would
have meant to the Debian AUCTeX maintainer if we had put the standard
FSF front and back cover texts on (he likely would have tried muddling
through).  But in this particular case (the manual had been licensed
differently before), Richard let us do without.  I think this is
basically what the simplified GFDL does: not have invariant sections
and, even more, not even have provisions for them.

With Emacs, however, the situation is already established and it has
the GNU Manifesto as an invariant section under the GFDL.  I doubt
this is going to change anytime soon.

In my opinion, rating the two standard sentences on front and back
covers for FSF as "non-free" is completely silly.  There has been no
Debian vote on those particular texts, though, just on the complete
absence of such texts making the GFDL being considered free.

> In any case, the problem of Debian's multi-version support with info
> files is unrelated to the GFDL.  And we can blame Debian all we
> want, but I don't think we have many alternatives to offer.  Info is
> just currently not very good at dealing with such problems.

Installing several different versions of software at once?  Certainly.
Other software can't do this without conflicts.  I think it was a
mistake by Debian to think they could allow such a contraption for
Emacs, when it fails for much simpler systems.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: arevert-xtra.texi xref gremlin

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> It is sort of pointless trying to fix broken links to manuals that
>> Debian is going to remove.
>
> Again: they're not completely removed, just moved to a separate package in
> the non-free section.  So it's far from pointless.
>
> I find it funny that Debian's "vrms" lists emacs21-common-non-dfsg ("vrms"
> is the "Virtual RMS" which lists the non-free packages installed on your
> system).  At least if they want to keep the "GFDL is not free" principle,
> they should either rename vrms, or fix it to abide by Richard's
> own principles.

I suggest filing a Debian bug report ;-)

Re: arevert-xtra.texi xref gremlin

[Johan Bockgård]

Chong Yidong <cyd@stupidchicken.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> I find it funny that Debian's "vrms" lists emacs21-common-non-dfsg ("vrms"
>> is the "Virtual RMS" which lists the non-free packages installed on your
>> system).  At least if they want to keep the "GFDL is not free" principle,
>> they should either rename vrms, or fix it to abide by Richard's
>> own principles.
>
> I suggest filing a Debian bug report ;-)

http://article.gmane.org/gmane.linux.debian.devel.emacsen/2159

Re: arevert-xtra.texi xref gremlin

[Davi Leal]

Johan Bockgård wrote:
> Chong Yidong <cyd@stupidchicken.com> writes:
> > I suggest filing a Debian bug report ;-)
>
> http://article.gmane.org/gmane.linux.debian.devel.emacsen/2159

I have sent an email to 221807_AT_bugs.debian.org, to raise the attention 
about it. You can read at: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=221807

Just copy & paste,
Davi

Re: [debian-vrms] Bug#221807: "please take this into consideration"

[David Diaz]

> > Stefan Monnier <monnier@iro.umontreal.ca> writes:
> >> I find it funny that Debian's "vrms" lists emacs21-common-non-dfsg
> >> ("vrms" is the "Virtual RMS" which lists the non-free packages installed
> >> on your system).  At least if they want to keep the "GFDL is not free"
> >> principle, they should either rename vrms, or fix it to abide by
> >> Richard's own principles.

Bdale Garbee wrote:
> Or, perhaps, offer a command line switch for choosing which of two rule
> sets definining freedom to apply?

I personally think too if the package name is "Virtual RMS" it should abide 
the RMS principles, just to avoid confusion to the package's users.

Another option could be rename the package to something like "check 
installation freedom" and allow choosing the freedom 'mode'.  However I like 
have a 'virtual' RMS.  Maybe the best option is to fix the vrms to abide the 
RMS principles, and add other virtual-whatever-package if you want. Note the 
comment in the vrms description package:

  "Future versions of vrms will include an option to also display text
   from the public writings of RMS and others that explain why use of
   each of the installed non-free packages might cause moral issues
   for some in the Free Software community."


Bug report at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=221807

Davi

Bug#221807: [debian-vrms] Bug#221807: "please take this into consideration"

[Bdale Garbee]

On Wed, 2007-04-04 at 19:38 +0200, David Diaz wrote:

> I personally think too if the package name is "Virtual RMS" it should abide 
> the RMS principles, just to avoid confusion to the package's users.

I understand your point.  I guess I just still hold out hope that the
FSF may one day again publish documentation under a license that's
compliant with the DFSG...

> Note the comment in the vrms description package:

;-)  Actually, I wrote that.  Way back when, I'm the one who dreamed up
the package, came up with the name, and wrote the man page.  The
motivation was a conversation a guy who used to work for me (Bill
Geddes) was having with RMS about Debian non-free.  Bill wrote the
original Perl implementation of vrms.  None of that is particularly
important, except to assure you that I'm completely aware that vrms has
never really fulfilled the original vision I/we had for it...

Do you care about this enough to want to help work on vrms?

Bdale

Re: [debian-vrms] Bug#221807: "please take this into consideration"

[David Diaz]

Bdale Garbee wrote:
> David Diaz wrote:
> > I personally think too if the package name is "Virtual RMS" it should
> > abide the RMS principles, just to avoid confusion to the package's users.
>
> I understand your point.  I guess I just still hold out hope that the
> FSF may one day again publish documentation under a license that's
> compliant with the DFSG...

The facts are that a "Virtual RMS" is a RMS not a DFSG. Please, rename the 
package. Do not confuse the users of your package.


> > Note the comment in the vrms description package:

> I'm completely aware that vrms has never really fulfilled the original
> vision I/we had for it... 

> Do you care about this enough to want to help work on vrms?

I am overloaded with this www.gnuherds.org

Best regards,
Davi