emacs -q -nw --color=never

emacs -q -nw --color=never

[Luc Teirlinck]

After:

emacs-21.3.50 -q -nw --color=never

and C-h i

the colors in Info buffers are still present.  Is there a reason for
this?   Or am I doing something wrong?  Or is this a local problem and
does it work for everybody else?

Sincerely,

Luc.

emacs and libxml2 (for emacs w3)

[Nic Ferrier]

This is primarily a question for rms but others might know the answer.

Is it possible to link emacs with the gnome project's libxml2
library? (http://www.xmlsoft.org/).

This library is distributed under an MIT licence.


I'm wondering about this because emacs is being used (by me at least)
more and more for XML hacking. I'd like to have a go at adding
libxml2 into emacs and providing a proper DOM implementation and
libxml2 based parsers and xslt styling.

It would also be a good basis for the proposed w3 rewrite.


But if there are legal problems with the licences then it would not
be a good idea for me to even think about doing the work.



Nic Ferrier

Re: emacs and libxml2 (for emacs w3)

[Richard Stallman]

    Is it possible to link emacs with the gnome project's libxml2
    library? (http://www.xmlsoft.org/).

Please send me the license and I'll tell you.

Re: emacs and libxml2 (for emacs w3)

[Nic Ferrier]

Richard Stallman <rms@gnu.org> writes:

>     Is it possible to link emacs with the gnome project's libxml2
>     library? (http://www.xmlsoft.org/).
> 
> Please send me the license and I'll tell you.

Thanks. Here's the licence:

>>>>>>>>>>
Except where otherwise noted in the source code (trio files, hash.c and list.c)
covered by a similar licence but with different Copyright notices:

 Copyright (C) 1998-2002 Daniel Veillard.  All Rights Reserved.

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is fur-
nished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FIT-
NESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
DANIEL VEILLARD BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CON-
NECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Except as contained in this notice, the name of Daniel Veillard shall not
be used in advertising or otherwise to promote the sale, use or other deal-
ings in this Software without prior written authorization from him.
<<<<<<<<<

The author describes it as an "MIT-style" licence.

It looks GPL compatible to me.



Nic

Re: emacs and libxml2 (for emacs w3)

[Richard Stallman]

Yes, it is GPL-compatible.
We could make Emacs link with it if that is technically a good idea.

Re: emacs and libxml2 (for emacs w3)

[James Clark]

Richard Stallman wrote:

> We could make Emacs link with it if that is technically a good idea.

It does not seem a technically good idea to me.  I think it's much 
better to have a XML library designed specifically to work with Emacs 
from the start and I see no compelling reason for it to be in C.  Using 
a general-purpose XML parser like libxml2 would be very limiting.  For 
example, an Emacs-specific parser can be designed to take advantage of 
the after-change-functions hook and do incremental parsing and 
validation. A typical general-purpose parser like libxml2 is not 
designed to do this sort of thing.

For the last few months, I've been working on new XML support for Emacs. 
  There's a user-oriented overview of the initial release at:

   http://www.xmlhack.com/read.php?item=2061

It's built on top of a low-level XML parsing layer that's designed to 
support a broad range of different kinds of XML processing that are 
useful in Emacs, such as

- font lock

- XML syntax aware editing (functionality like parse-partial-sexp for XML)

- incremental validation to support context/schema-sensitive completion 
(like PSGML)

- doing what xml.el does (i.e. parsing XML into a list form that is 
convenient for further processing in Lisp)

It's still early days, but I think this is technically a better 
direction that linking to a general-purpose XML library like libxml2.

James

Re: emacs and libxml2 (for emacs w3)

[Stefan Monnier]

> - XML syntax aware editing (functionality like parse-partial-sexp for XML)

I'd like to beef up the syntax.c code, which means among other things
parse-partial-sexp.  One important aspect of it is that I'd like it
to be extensible.  Do you have some idea of how parse-partial-sexp
could be made extensible such that you could make use of it in your
XML parser ?


        Stefan


PS: One trivial option is to introduce a parse-partial-sexp-function,
    of course, but it's too crude and doesn't address the need to also
    adjust things like up-list, backward-sexp, ...
PPS: I have some other unconvincing ideas as well, but I'd like to hear your
    ideas, if any, first (I feel like I'm stuck in a rut and fear that by
    presenting my ideas I'll force you to get stuck in the same rut).

Re: emacs and libxml2 (for emacs w3)

[Nic Ferrier]

James Clark <jjc@jclark.com> writes:

> For the last few months, I've been working on new XML support for
> Emacs. 

I've seen it (via Tim Bray's weblog http://www.tbray.org/ongoing) and
I was very impressed.


> It's still early days, but I think this is technically a better 
> direction that linking to a general-purpose XML library like
> libxml2.

The attraction (to me) of libxml2 is that I use it elsewhere. I know
what it does. When I'm developing xml based tools within emacs, using
a parser and xpath evaluator that I will use in production has value
for me.


Nic

Re: emacs and libxml2 (for emacs w3)

[James Clark]

Nic Ferrier wrote:

> The attraction (to me) of libxml2 is that I use it elsewhere. I know
> what it does. When I'm developing xml based tools within emacs, using
> a parser and xpath evaluator that I will use in production has value
> for me.

That doesn't seem like a good reason for the standard version of Emacs 
to link with libxml2.  The whole point of XML is to be interoperable and 
not tie you to specific tools.  I don't think one can assume that all 
Emacs users will be using libxml2 for XML processing.

Can you give examples of applications that require linking to libxml2 
rather than using libxml2 via separate programs?  One approach that 
might be worth considering is writing a little C program on top of 
libxml2 that outputs an XML document in the form of the printed 
representation of the list structure defined in xml.el and vice-versa. 
Then you could do efficient XML processing in Emacs based on libxml2 
without requiring Emacs to be linked to another library. I've been 
talking with the xml.el maintainer about how to extend this to handle 
namespaces, which are really essential for many apps these days.

James

Re: emacs and libxml2 (for emacs w3)

[Alex Schroeder]

Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:

> I'm wondering about this because emacs is being used (by me at least)
> more and more for XML hacking. I'd like to have a go at adding
> libxml2 into emacs and providing a proper DOM implementation and
> libxml2 based parsers and xslt styling.

A long time ago I wrote a DOM implementation (dom.el) and a first
xpath implementation (xpath.el) to do this kind of thing.  It would
use the xml.el that comes with Emacs to create a list data structure,
and then use dom.el to create a DOM, and then use xpath.el to extract
info.

At the time nobody was interested, and I have since abandoned the
stuff.  It is still available on emacswiki.org, however.

http://www.emacswiki.org/cgi-bin/wiki/XmlParser
http://www.emacswiki.org/elisp/dom.el
http://www.emacswiki.org/elisp/xpath.el
http://www.emacswiki.org/elisp/xpath-parser.el

Alex.
-- 
http://www.emacswiki.org/alex/
There is no substitute for experience.

Re: emacs -q -nw --color=never

[Robert J. Chassell]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

   After:

   emacs-21.3.50 -q -nw --color=never

   and C-h i

   the colors in Info buffers are still present.  Is there a reason for
   this?   Or am I doing something wrong?  

You are not doing anything wrong.  I, too, see the colors.  The
manual, (emacs)Colors , says

    `never'
    `no'
          Don't use colors even if the terminal's capabilities specify
          color support.

so seeing colors is a bug.

Using today's CVS snapshot, Sun, 2003 Sep 21 18:33 UTC
GNU Emacs 21.3.50.80 (i686-pc-linux-gnu, GTK+ Version 2.2.1)

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: emacs -q -nw --color=never

[Richard Stallman]

    emacs-21.3.50 -q -nw --color=never

    and C-h i

    the colors in Info buffers are still present.  Is there a reason for
    this?

It sounds like a bug to me.  Judging from the manual, --color=never is
supposed to completely prevent Emacs from displaying colors, even if a
Lisp program specifies colors.  It would appear to be completely
broken.  Can you debug it?

Re: emacs -q -nw --color=never

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Mon, 22 Sep 2003 05:05:10 -0400
> 
> It sounds like a bug to me.  Judging from the manual, --color=never is
> supposed to completely prevent Emacs from displaying colors, even if a
> Lisp program specifies colors.

That's true, although a Lisp program should never specify colors
unless the display supports them; it should instead specify faces, and
faces are computed based on color capabilities.  But Info does work
like this: it specifies faces, not explicit colors.

> It would appear to be completely broken.  Can you debug it?

I did debug this a bit.  AFAICS, this happens because this code in
line 2130 of term.c:

  NATNUMP (color_mode)

evaluates to zero (i.e. false) when the value of color_mode is -1.
The value of -1 is correct: that's the association of `never' in
tty-color-mode-alist, and set_tty_color_mode, where this code belongs,
is called with its second argument `val' being the symbol `never'.

Sorry, I don't have enough time to figure out why NATNUMP doesn't do
what it was supposed to do here.  FWIW, "cvs annotate" says that this
code didn't change since when I first wrote it, so perhaps it's my
original sin, although I'm quite sure I tested `never' at the time.

Re: emacs -q -nw --color=never

[Eli Zaretskii]

> Date: Mon, 22 Sep 2003 18:48:13 +0200
> From: "Eli Zaretskii" <eliz@elta.co.il>
> 
> Sorry, I don't have enough time to figure out why NATNUMP doesn't do
> what it was supposed to do here.

Ugh, what was I smoking?  Of course, NATNUMP won't do what I wanted!

Please try the latest CVS HEAD, it should be fixed now.

Re: emacs -q -nw --color=never

[Luc Teirlinck]

Eli Zaretskii wrote:
   
   Please try the latest CVS HEAD, it should be fixed now.

It is.  Thanks.

Sincerely,

Luc.

Re: emacs -q -nw --color=never

[Richard Stallman]

    I did debug this a bit.  AFAICS, this happens because this code in
    line 2130 of term.c:

      NATNUMP (color_mode)

    evaluates to zero (i.e. false) when the value of color_mode is -1.

I see you made some changes that would fix this bug, but there
are other bugs too.

What do you think of this version?

void
set_tty_color_mode (f, val)
     struct frame *f;
     Lisp_Object val;
{
  Lisp_Object color_mode_spec, current_mode_spec;
  Lisp_Object color_mode, current_mode;
  int mode, old_mode;
  extern Lisp_Object Qtty_color_mode;
  Lisp_Object tty_color_mode_alist;

  tty_color_mode_alist = Fintern_soft (build_string ("tty-color-mode-alist"),
				       Qnil);

  if (INTEGERP (val))
    color_mode = val;
  else
    {
      if (NILP (tty_color_mode_alist))
	color_mode_spec = Qnil;
      else
	color_mode_spec = Fassq (val, XSYMBOL (tty_color_mode_alist)->value);

      if (CONSP (color_mode_spec))
	color_mode = XCDR (color_mode_spec);
      else
	color_mode = Qnil;
    }

  current_mode_spec = assq_no_quit (Qtty_color_mode, f->param_alist);

  if (CONSP (current_mode_spec))
    current_mode = XCDR (current_mode_spec);
  else
    current_mode = Qnil;

  if (INTEGERP (color_mode))
    mode = XINT (color_mode);
  else
    mode = 0;	/* meaning default */
  /* Canonicalize negative numbers to -1.  */
  if (mode < 0)
    mode = -1;

  if (INTEGERP (current_mode))
    old_mode = XINT (current_mode);
  else
    old_mode = 0;

  if (mode != old_mode)
    {
      tty_setup_colors (mode);
      /*  This recomputes all the faces given the new color
	  definitions.  */
      call0 (intern ("tty-set-up-initial-frame-faces"));
      redraw_frame (f);
    }
}

Re: emacs -q -nw --color=never

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Wed, 24 Sep 2003 08:47:04 -0400
> 
> I see you made some changes that would fix this bug, but there
> are other bugs too.
> 
> What do you think of this version?

AFAICS, the only real change is this fragment that is absent in the
current codebase:

>   /* Canonicalize negative numbers to -1.  */
>   if (mode < 0)
>     mode = -1;

I don't really object, but what problem would that solve?  The value
of `mode' is not supposed to be negative unless it's -1.

Did I miss any other changes in the version you suggested?

Re: emacs -q -nw --color=never

[Richard Stallman]

    >   /* Canonicalize negative numbers to -1.  */
    >   if (mode < 0)
    >     mode = -1;

    I don't really object, but what problem would that solve?  The value
    of `mode' is not supposed to be negative unless it's -1.

That's the point--a user could specify -2 or -1000.
It may as well do something predictable.

Re: emacs -q -nw --color=never

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 25 Sep 2003 19:20:12 -0400
> X-PRIVAWALL-ID: 0002556710ac
> X-OriginalArrivalTime: 26 Sep 2003 00:23:17.0468 (UTC) FILETIME=[61D4F1C0:01C383C4]
> 
>     >   /* Canonicalize negative numbers to -1.  */
>     >   if (mode < 0)
>     >     mode = -1;
> 
>     I don't really object, but what problem would that solve?  The value
>     of `mode' is not supposed to be negative unless it's -1.
> 
> That's the point--a user could specify -2 or -1000.
> It may as well do something predictable.

The current code does something predictable as well: any number that
is not a positive number of colors and not -1 means the same as zero,
i.e. switch to the default number of colors, the one specified by the
terminal's termcap/terminfo entry.  (The code that does that is in
tty_setup_colors.)

Thus,

     emacs -nw --color=2000
and
     emacs -nw --color=-2000

produce the same result.  What you suggest will change that.

Do you think that negative arguments are ``special'' in the sense that
they imply that the feature is to be turned off?

(I should also add that the user is not supposed to use numbers as
arguments to the --color option, except if she specifies the number of
supported colors, like --colors=8 or --colors=256.  That is, I never
meant for them to say --colors=-1 or --colors=0, since the expected
effect of --colors=0 might be to turn off the colors, which is not
what happens.  Similarly, --colors=-2000 was not something I expected
users to say.)

Re: emacs -q -nw --color=never

[Richard Stallman]

    Do you think that negative arguments are ``special'' in the sense that
    they imply that the feature is to be turned off?

I think it is more consistent for all negative numbers to mean "off".

Re: emacs -q -nw --color=never

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 28 Sep 2003 11:34:13 -0400
> 
>     Do you think that negative arguments are ``special'' in the sense that
>     they imply that the feature is to be turned off?
> 
> I think it is more consistent for all negative numbers to mean "off".

Okay, I made that change, but in tty_setup_colors, not in
set_tty_color_mode, so as to keep the intimate knowledge about
supported values of the MODE argument localized to the former.

Re: emacs -q -nw --color=never

[Richard Stallman]

    Okay, I made that change, but in tty_setup_colors, not in
    set_tty_color_mode, so as to keep the intimate knowledge about
    supported values of the MODE argument localized to the former.

Ok, thanks.