headers
Miles Bader | 1 Jul 2004 04:17
Picon
Picon

Re: appears CVS build is broken (tty-supports-face-attributes-p)?

BTW, usually it's sufficient to do `make -C lisp recompile', and of
course it's much faster.  So a generally good strategy after updating is
to do that followed by a normal make, and if it fails in a suspicious
way, then try make maintainer-clean + make bootstrap.

-Miles
--

-- 
Fast, small, soon; pick any 2.
Permalink | Reply | 4 comments |
headers
Luc Teirlinck | 1 Jul 2004 05:38
Picon

Re: appears CVS build is broken (tty-supports-face-attributes-p)?

Miles Bader wrote:

   BTW, usually it's sufficient to do `make -C lisp recompile', and of
   course it's much faster.  So a generally good strategy after updating is
   to do that followed by a normal make, and if it fails in a suspicious
   way, then try make maintainer-clean + make bootstrap.

In practice, people are going to do what we _ask_ then to do in
INSTALL.CVS:

    Normally, it is not necessary to use "make bootstrap" after every CVS
    update.  Unless there are problems, we suggest the following
    procedure:

      $ ./configure
      $ make
      $ cd lisp
      $ make recompile EMACS=../src/emacs
      $ cd ..
      $ make

    (If you want to install the Emacs binary, type "make install" instead
    of "make" in the last command.)

If this is not the best strategy, INSTALL.CVS should be changed.

(Note however that for people with fast machines, running `make
maintainer-clean' and `make bootstrap' is so fast that it is not even
worth the trouble trying anything else.)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Luc Teirlinck | 1 Jul 2004 05:47
Picon

Re: appears CVS build is broken (tty-supports-face-attributes-p)?

>From my previous message:

   In case of trouble we recommend first to update loaddefs.el and if
   this does not solve the problem, to run `make bootstrap'.  That used
   to be sufficient.  After a relatively recent change it no longer is.
   One has to first do `make maintainer-clean', then `make bootstrap'.
   This is not pointed out in INSTALL.CVS.

Actually, one has to do:

make maintainer-clean
./configure (with whatever options are wanted)
make bootstrap

This is another drawback of the recent change to `make bootstrap'.
`make maintainer-clean' removes _more_ than `make bootstrap' used to.

Sincerely,

Luc.
Permalink | Reply | 0 comments |
headers
Miles Bader | 1 Jul 2004 05:52
Picon
Picon

Re: appears CVS build is broken (tty-supports-face-attributes-p)?

Luc Teirlinck <teirllm <at> dms.auburn.edu> writes:
>    BTW, usually it's sufficient to do `make -C lisp recompile', and of
>    course it's much faster.  So a generally good strategy after updating is
>    to do that followed by a normal make, and if it fails in a suspicious
>    way, then try make maintainer-clean + make bootstrap.
>
> In practice, people are going to do what we _ask_ then to do in
> INSTALL.CVS:

My above message assumed that people (1) have emacs already installed,
and (2) are using GNU make.  It seems slightly dubious for INSTALL.CVS
to assume those things, but in practice they're probably often true.

Note that I also recommend recompiling the lisp files _before_ compiling
emacs, as sometimes lisp changes can affect the emacs build, but again
that requires a pre-existing emacs binary.

I don't understand why INSTALL.CVS says to re-run ./configure though --
that seems almost never necessary (as the Makefile will do so
automatically).

-Miles
--

-- 
My spirit felt washed.  With blood.  [Eli Shin, on "The Passion of the Christ"]
Permalink | Reply | 0 comments |
headers
Juri Linkov | 1 Jul 2004 07:08
Favicon
Gravatar

Re: Changes to emacs/lisp/progmodes/grep.el

Richard Stallman <rms <at> gnu.org> writes:
> Please don't call them "Linux distros".  They are more GNU than Linux,
> so calling them "Linux distros" is unfair to the GNU Project.

BTW, I remember discovering an interesting fact that the phrase

LINUX IS GOOD

is an anagram of the phrase

GNU IDOL IS OX

(PS: that was a side joke, and nothing more :-)

--

-- 
Juri Linkov
http://www.jurta.org/emacs/
Permalink | Reply | 0 comments |
headers
Juri Linkov | 1 Jul 2004 07:46
Favicon
Gravatar

Re: [PATCH] Allow compilation-next-error-function to leave code line highlighted until next command is typed

Richard Stallman <rms <at> gnu.org> writes:
> As long as the command name on C-x ` is next-error, we may as well
> call the option next-error-highlight.  If we change that binding
> before the release, we can rename the option at the same time.
>
> So please install this, as soon as you've written the changes for
> etc/NEWS and the Emacs Manual.

Mentioning the changes in etc/NEWS is ok, but I can't find a place in
the Emacs Manual where new options `next-error-highlight' and
`next-error-highlight-no-select' should be documented.

I recall that documentation rules disapprove adding every option
to the manual to not make it too big.  And it seems these options are
not too significant for using `next-error' to justify their additions
to the manual.

--

-- 
Juri Linkov
http://www.jurta.org/emacs/
Permalink | Reply | 6 comments |
headers
Juri Linkov | 1 Jul 2004 07:47
Favicon
Gravatar

Re: next-error refactoring

Ted Zlatanov <tzz <at> lifelogs.com> writes:
> Can I get a list of suggested modes that might benefit from next-error
> support?  Everyone, please send me your suggestions.
>
> So far we have:
>
> compilation-mode
> grep (which uses compilation-mode)
> occur-mode
>
> Other possibilities:
>
> emerge
> diff-mode

AFAICS, diff-mode belongs to the "what we have" category since it
already supports `next-error'.

> (please add your suggestions)

I think existing modes are enough to create an unified set of key
bindings. These modes are quite heterogeneous by their functionality,
so you can get good coverage of needs for key bindings.

If you want to add next-error support for more modes, you might consider
etags, dired-do-search, find-grep-dired.

> When I have a list of modes I can look at the key binding problems
> between them all.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Juanma Barranquero | 1 Jul 2004 11:30
Picon

Re: [PATCH] Delayed loading of image libraries


On Wed, 30 Jun 2004 11:42:34 -0400
Miles Bader <miles <at> gnu.org> wrote:

> The result of `create-image' can be saved in a lisp file, and later loaded,
> in which case the image will be displayed without `init-image-library' being
> called from `image-type-available-p'y

It can be loaded, sure, but can it be *displayed* without
`image-type-available-p' being called?  I'd say that's a bug.

> I added a the call to make sure it
> always gets called one way or another.

The current situation is Not Good.  Andreas has fixed your patch by
passing it Qnil, which "works" in the sense that init-image-library
doesn't fail.  But:

  - It is now effectively a noop, because init-image-library'ing any
    image type from inside lookup_image_type will not load it.

  - Emacs on Windows crashes on certain kinds of image files (notably
    TIFFs).  I think that's related to something I asked yesterday:
    lookup_image_type can return NULL, but at places its return value is
    just checked with xassert, which could be a noop, so it is posible
    to end creating image types with image->type == NULL.  Why it is
    allowed?

  - We could make image-library-alist available from C and pass it to
    the call to init-image-library on lookup_image_type, but then, why
(Continue reading)

Permalink | Reply | 15 comments |
headers
Miles Bader | 1 Jul 2004 11:48
Picon
Picon

Re: [PATCH] Delayed loading of image libraries

Juanma Barranquero <jmbarranquero <at> wke.es> writes:
>> The result of `create-image' can be saved in a lisp file, and later loaded,
>> in which case the image will be displayed without `init-image-library' being
>> called from `image-type-available-p'y
>
> It can be loaded, sure, but can it be *displayed* without
> `image-type-available-p' being called?  I'd say that's a bug.

With my patch they can.

Images are (currently) perfectly valid lisp values; if we don't want
them to be readable and writable to files, we should make them an opaque
type.

But that seems like a stupid thing to do.  Just make the C code deal
with the situation.  If my patch was wrong (though I admit, I still have
no idea why -- your discussion so far doesn't make much sense to me),
fix it, but don't remove the functionality it adds.

[Note that reading and writing images to files (and displaying them in a
new emacs instance, by just reading the file) worked fine before the
changes that added Finit_image_library etc., so the bug I fixed is a
regression.]

-Miles
--

-- 
My spirit felt washed.  With blood.  [Eli Shin, on "The Passion of the Christ"]
Permalink | Reply | 14 comments |
headers
Juanma Barranquero | 1 Jul 2004 12:13
Picon

Re: [PATCH] Delayed loading of image libraries


On Thu, 01 Jul 2004 18:48:46 +0900
Miles Bader <miles <at> lsi.nec.co.jp> wrote:

> Images are (currently) perfectly valid lisp values; if we don't want
> them to be readable and writable to files, we should make them an opaque
> type.

Reading and writing a lisp value (whether an image, or any other kind)
does not need image support.  *Processing* one of such values as an
image (to display it, ask questions about it, etc.) does need it.  At
that point, code should've asked whether the image type was available. 
I'm not sure why you do conflate reading/writing with using-as-an-image
(even if loading an image-representing lisp value ends up displaying it).

> But that seems like a stupid thing to do.  Just make the C code deal
> with the situation.  If my patch was wrong (though I admit, I still have
> no idea why

???

init-image-library has two mandatory arguments.  You didn't pass the
second one: the alist specifying where to find the dynamic libraries
supporting the desired image type.

>-- your discussion so far doesn't make much sense to me),

Why?  Lack of English skills, (absence of) clarity, vocabulary mismatch?

> fix it, but don't remove the functionality it adds.
(Continue reading)

Permalink | Reply | 13 comments |

Gmane