Reiner Steib <[EMAIL PROTECTED]> writes:
> I tried to enable battery-mode on my notebook using `M-x battery- TAB'
> but I got "No match". Eventually I found `display-battery-mode' in
> `battery.el'. Shouldn't the name of the minor mode read
> `battery-mode' instead of `display-battery-mode'?
Ag
Juri Linkov <[EMAIL PROTECTED]> writes:
[...]
>>> 7. In the section `Info'
>>>
>>> \key{find specified function or variable in Info}{C-h C-i}
>>>
>>> the keybinding `C-h C-i' is not available anymore.
>>
>> Is there a new binding?
>
> Currently `C-h C-i' is unbound. Some time ago I proposed to b
"Sean O'Rourke" <[EMAIL PROTECTED]> writes:
[...]
>> Thanks. This looks too complicated to hack on for me (I don't have
>> access to OS X). Maybe someone else would like to add support for
>> versions of OS X that don't have "pmset -g ps"?
>
> FYI, I've used the version at the end of this page,
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> As far as I know, the GNU Task List is obsolete and has been replaced
> by http://savannah.gnu.org/projects/tasklist. There is still an old
> version of the list in etc/tasks.texi. Shall I delete that file?
>
> Please do.
Done.
>
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> I noticed that lisp/elide-head.el has the FSF's old address hardcoded.
> It should probably be fixed so that it recognizes the new address as
> well.
>
> Could you please do that?
Done.
Lute.
__
Juri Linkov <[EMAIL PROTECTED]> writes:
> I looked at etc/refcard.tex too and noticed places that need to be fixed
> other than those already corrected by Lute.
>
> 1. In the section `Files'
>
> \key{version control checkin/checkout}{C-x C-q}
>
> needs to be replaced with
>
> \key{toggle read only
Juri Linkov <[EMAIL PROTECTED]> writes:
> It seems you missed a change to version 22 in the comments
> `% Reference Card for GNU Emacs version 21 on Unix systems'.
Thanks. Fixed.
> PS: Perhaps maintainers of refcard's translations should be
> notified after all changes in refcard.tex are comple
David Kastrup <[EMAIL PROTECTED]> writes:
> the recent batch of address changes also affected a lot of "COPYING"
> files. Those now start with
>
> GNU GENERAL PUBLIC LICENSE
> Version 2, June 1991
>
> Copyright (C) 1989, 1991 Free Software Foundation, Inc.
Ken Raeburn <[EMAIL PROTECTED]> writes:
[...]
>> Do you know of a way to get battery information on your system?
[... lots of useful info ...]
Thanks. This looks too complicated to hack on for me (I don't have
access to OS X). Maybe someone else would like to add support for
versions of OS X
I've updated etc/refcard.tex. Ok to commit?
Lute.
2005-07-06 Lute Kamstra <[EMAIL PROTECTED]>
* refcard.tex: Update `versionnumber' and `year'. Update Emacs's
version to 22.
(Starting Emacs): Delete sentence to fix formatting problems.
As far as I know, the GNU Task List is obsolete and has been replaced
by http://savannah.gnu.org/projects/tasklist. There is still an old
version of the list in etc/tasks.texi. Shall I delete that file?
Should we add a pointer to http://savannah.gnu.org/projects/tasklist?
Any ideas where to add t
Lute Kamstra <[EMAIL PROTECTED]> writes:
> "Richard M. Stallman" <[EMAIL PROTECTED]> writes:
>
>> All files in the Emacs distribution have the old address. I think we
>> should update before the release. Shall I add that task to
>>
David Ponce <[EMAIL PROTECTED]> writes:
> Richard M. Stallman wrote:
>> Anyway I reverted the last change made to:
>> - dispextern.h 1.206 -> 1.205
>> - xdisp.c 1.1028 -> 1.1027
>> - xfnc.c 1.640 -> 1.639
>> That change fixed another bug, and mostly works correctly, so
Juanma Barranquero <[EMAIL PROTECTED]> writes:
>> I am too sleepy.
>
> That last sentence practically summarizes my last two or three months.
My partner is an MD. Whenever I suffer from the symptoms you describe,
she advises me to go to bed and sleep. Try it, it works for me.
Lute.
_
Arne Jørgensen <[EMAIL PROTECTED]> writes:
> Lute Kamstra <[EMAIL PROTECTED]> skriver:
>
>> Apparently that option was added in OS X 10.4. Strange that pmset
>> doesn't signal an error with its exit code when it gets passed an
>> unknown option. Maybe
Arne Jørgensen <[EMAIL PROTECTED]> writes:
> Lute Kamstra <[EMAIL PROTECTED]> writes:
>
> [...]
>
>> My patch tries to test whether pmset supports "-g ps" by looking at
>> the exit code. Does "pmset -g ps" return a non-zero exit code
Ken Raeburn <[EMAIL PROTECTED]> writes:
[...]
> (And, BTW, the "-g ps" arguments given don't seem to do anything on my
> laptop running 10.3, kernel 7.9.0; I don't know if that means it's
> just not a supported option on my laptop for some reason, which would
> seem kind of strange, or if the "ps
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> The changes are ok (presuming they work), but there is a problem in
> the comments:
>
> ! ;; There is at present support for Linux and Darwin.
>
> Darwin is a complete operating system. To include "Linux" in that
> list implies that it too i
David Kastrup <[EMAIL PROTECTED]> writes:
> "Richard M. Stallman" <[EMAIL PROTECTED]> writes:
>
>> The changes are ok (presuming they work), but there is a problem in
>> the comments:
>>
>> ! ;; There is at present support for Linux and Darwin.
>>
>> Darwin is a complete operating system.
>
>
Lennart Borgman <[EMAIL PROTECTED]> writes:
> There is an assq-delete-all, but I am missing assoc-delete-all
I guess nobody needed it before. Do you want to use it?
Lute.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman
David Kastrup <[EMAIL PROTECTED]> writes:
> Lute Kamstra <[EMAIL PROTECTED]> writes:
>
>> Currently, lisp/battery.el supports only Linux. I've added support
>> for Darwin. See the patch below. Is it ok to install this now, or
>> should I wait until af
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> All files in the Emacs distribution have the old address. I think we
> should update before the release. Shall I add that task to
> FOR-RELEASE?
>
> Yes. In fact, could you possibly make the change?
> Using a script to do the edits
Currently, lisp/battery.el supports only Linux. I've added support
for Darwin. See the patch below. Is it ok to install this now, or
should I wait until after the release?
Lute.
2005-07-02 Lute Kamstra <[EMAIL PROTECTED]>
* battery.el: Add support for Darwin (with muc
Jim Blandy <[EMAIL PROTECTED]> writes:
> The COPYING files in the Emacs distribution all have the old address
> for the Free Software Foundation --- 59 Temple Place.
All files in the Emacs distribution have the old address. I think we
should update before the release. Shall I add that task to
F
David PONCE <[EMAIL PROTECTED]> writes:
[...]
> Do you observe the same thing?
Yes. On GNU/Linux with Lucid, but not with GTK.
Lute.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Juri Linkov <[EMAIL PROTECTED]> writes:
>> We also need to find other modes that are effectively "derived" and
>> ought to use delay-mode-hooks. I think one could write a Lisp
>> program that would search for a match for "([-a-z]+-mode " within a
>> defun that starts with "(defun [-a-z]+-mode ".
Richard Stallman <[EMAIL PROTECTED]> writes:
> Of course my method failed to find any major modes that don't run mode
> hooks at all. Maybe someone else could try to fix those?
>
> Perhaps one could find these easily with a Lisp program
> that searches for a defun whose start matches "(de
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> The faces menu automatically lists all faces that are defined
> except those whose names are matched by facemenu-unlisted-faces.
> I am pretty sure that list is not up to date, and that various
> packages define faces that shouldn't be listed in
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> Or, it could just warn the user that the highlighting will not be
> visible since font lock is enabled?
>
> It would be possible, but why be so complicated?
> This change seems to do the right job.
You asked if someone would like to work
Juanma Barranquero <[EMAIL PROTECTED]> writes:
> On 6/23/05, Lute Kamstra <[EMAIL PROTECTED]> wrote:
>
>> Maybe it's better to first get a good understanding of the problems
>> you're experiencing.
>
> Well, we have at least one case of a fully repr
Jason Rumney <[EMAIL PROTECTED]> writes:
> Juanma Barranquero wrote:
>
>>The issue is that `fit-window-to-buffer', when called from
>>`occur-hook', changes the current buffer.
>>
> Yes, this seems like a real bug. I have noticed some other strange
> behaviour lately with things taking place in the
Miles Bader <[EMAIL PROTECTED]> writes:
> I didn't realize this when I sent those messages, but you first have to do:
>
>(require 'fringe)
Yup, that makes it work. Your bitmaps are a bit to thin for my taste.
(I use 1024x768 on a 17" monitor.) Also, the empty-line bitmap
touches the bottom-
Miles Bader <[EMAIL PROTECTED]> writes:
[...]
> Could people try them out? Maybe these would be better defaults
> than the existing bitmaps.
Ehrm, maybe I'm doing something really stupid, but your redefinitions
don't seem to change the appearance of the fringe bitmaps in my Emacs.
What I do is
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> There are other commands using `a' letter to read function names (like
> `elp-instrument-function', etc.) where getting the default function name
> from the current buffer would be useful too. So maybe it's better to
> implement
Juri Linkov <[EMAIL PROTECTED]> writes:
> A better way to do this is to change the interactive specification of
> `debug-on-entry' to call `function-called-at-point'.
How about this?
Lute.
Index: lisp/emacs-lisp/debug.el
===
RCS f
Hi Jérôme,
> Is anyone interested in applying this patch?
Yep, I'll do that.
Lute.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Richard Stallman <[EMAIL PROTECTED]> writes:
> I tested this the other day too and was confuzzled (confused +
> puzzled). After a while I realized that it had to do woth
> font-lock-mode overriding my coloring.
>
> Perhaps those menu items should be disabled when Font Lock is enabled.
Hi Werner,
> [emacs CVS 2005-06-12 with GTK]
>
> If I mark a text region and select the menu entry
>
> Edit->Text Properties->Foreground Color->Other...
>
> I can select a colour (say, red) and everything is fine.
>
> After doing that, the colour `red' is added to the last submenu so
> that it c
Richard Stallman <[EMAIL PROTECTED]> writes:
> > It might be useful to find a way to arrange a warning when files use
> > Mode: or -*-...-*- to specify minor modes.
>
> In general, there are examples of minor modes (Ralf and David gave an
> example) for which it is useful to turn t
[EMAIL PROTECTED] (Johan Bockgård) writes:
>>> Modes derived from fundamental mode run after-change-major-mode-hook
>>> twice because fundamental mode runs it unconditionally.
>
> I don't understand this. As define-derived-mode is currently defined modes
> derived from fundamental-mode do not auto
Richard Stallman <[EMAIL PROTECTED]> writes:
> I think you and Werner are talking about different things. You talk
> about Font Lock mode overriding the text properties you set manually.
> Werner's problem happens even when Font Lock mode is off. The "red"
> menu entry (that is c
Juanma Barranquero <[EMAIL PROTECTED]> writes:
> I got these errors on bootstrapping:
[...]
Should be fixed now.
Lute.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Miles Bader <[EMAIL PROTECTED]> writes:
>> The patch below gets bootstrap working again. Can you confirm that
>> it's the right fix?
>
> Yes that looks correct.
Committed,
Lute.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org
Hi Miles,
This change broke bootstrapping for me.
2005-06-17 Miles Bader <[EMAIL PROTECTED]>
* mh-customize.el (mh-folder-body, mh-folder-cur-msg)
(mh-folder-cur-msg-number, mh-folder-date, mh-folder-followup)
(mh-folder-msg-number, mh-folder-refiled, mh-folder-subject)
Richard Stallman <[EMAIL PROTECTED]> writes:
> Modes derived from fundamental mode run after-change-major-mode-hook
> twice because fundamental mode runs it unconditionally. Fundamental
> mode should only run after-change-major-mode-hook if delay-mode-hooks
> is nil. We can eithe
Mathias Dahl <[EMAIL PROTECTED]> writes:
> Werner LEMBERG <[EMAIL PROTECTED]> writes:
>
>> [emacs CVS 2005-06-12 with GTK]
>>
>> If I mark a text region and select the menu entry
>>
>> Edit->Text Properties->Foreground Color->Other...
>>
>> I can select a colour (say, red) and everything is fine
Richard Stallman <[EMAIL PROTECTED]> writes:
> I've got the same problem with auto-fill sometimes. I switch that
> mode on with text-mode-hook. When I visit a text file that has "mode:
> auto-fill", it is effectively turned off. Maybe we should do
> (some-minor-mode 1) for "mode
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Lute Kamstra wrote:
>
>I think your formulation is a bit misleading. Emacs' debugger can't
>step through a primitive, gdb can.
>
> So what about:
[...]
> ! type @kbd{C-M-x} on its definition.) You can
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> What about the following additional change to debugging.texi? It may
> not be that surprising that if you can not step through a
> byte-compiled function, you can not step through a primitive function
> either, but it may not hurt to explicitly mention
Stefan Monnier <[EMAIL PROTECTED]> writes:
> 1 - move mouse to one of the minor modes names on the mode-line.
> press mouse-3 to get a menu of minor modes.
> cancel the menu by releasing outside of it (while keeping the mouse
> cursor pointing outside of any Emacs window): the mouse-fa
Ralf Angeli <[EMAIL PROTECTED]> writes:
> * Lute Kamstra (2005-06-15) writes:
>
>> I've got the same problem with auto-fill sometimes. I switch that
>> mode on with text-mode-hook. When I visit a text file that has "mode:
>> auto-fill", it is effecti
Werner LEMBERG <[EMAIL PROTECTED]> writes:
> If I put
>
> Local Variables:
> mode: enriched
> End:
>
> into a file and I load it into Emacs, I get the message
>
> Toggling enriched-mode off; better pass an explicit argument.
>
> Why?
I did a quick analysis:
When you save a file with enri
Modes derived from fundamental mode run after-change-major-mode-hook
twice because fundamental mode runs it unconditionally. Fundamental
mode should only run after-change-major-mode-hook if delay-mode-hooks
is nil. We can either test this directly or use (run-mode-hooks
'fundamental-mode-hook).
Richard Stallman <[EMAIL PROTECTED]> writes:
> With that change, please install it.
Done.
Lute.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Hi David,
>> Does someone see a problem with this change?
>
> This is a good idea, however I think the call to `recentf-dialog-mode'
> should be moved before to setup the widgets because they might use
> local variables.
Like this?
Lute.
Index: lisp/recentf.el
=
Does someone see a problem with this change?
Lute.
2005-06-13 Lute Kamstra <[EMAIL PROTECTED]>
* recentf.el (recentf-dialog-mode): Use kill-all-local-variables
and run-mode-hooks.
(recentf-edit-list, recentf-open-files): Don't call
kill-all-loca
Lute Kamstra <[EMAIL PROTECTED]> writes:
>>> You can use debug-on-entry for primitive functions that are not
>>> specials forms. You just can't step through them. I'll fix the
>>> docs.
>>
>> Also they may be called without triggering th
Lennart Borgman <[EMAIL PROTECTED]> writes:
> should be VOID-TEXT-AREA-POINTER in Info.
Fixed,
Lute.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
David Kastrup <[EMAIL PROTECTED]> writes:
>>> I can't decide whether the title of this thread is more fitting for a
>>> blues song or a pulp fiction booklet. It certainly projects drama.
>>
>> Hey, it says derived, not deprived.
>
> Actually, for some keymaps "depraved" would fit better.
I knew
David Kastrup <[EMAIL PROTECTED]> writes:
> I can't decide whether the title of this thread is more fitting for a
> blues song or a pulp fiction booklet. It certainly projects drama.
Hey, it says derived, not deprived.
Lute.
___
Emacs-devel mailing
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> You can use debug-on-entry for primitive functions that are not
>> specials forms. You just can't step through them. I'll fix the
>> docs.
>
> Also they may be called without triggering the debugger, if they're called
> directly from C rather than fr
Werner LEMBERG <[EMAIL PROTECTED]> writes:
> After saying `make bootstrap; make install', the file `cus-load.el~'
> is installed also. Wouldn't it be better to remove it?
I don't see how this can happen with Makefile.in. Do you use W32?
Lute.
___
E
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> What about the following additional change:
I like it,
Lute.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Richard Stallman wrote:
>
>@var{function-name} in the minibuffer. If @var{function-name} is
>! omitted, @code{nil} or the empty string, it cancels break-on-entry
> for all
>
>You need a comment after @code{nil} to eliminate a misrea
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> changes on related things. Maybe you could explain the rationale
>> behind the test so that I can take that into account when I'm fixing
>> the derived modes?
>
> The additional check is only relevant when compiling unbundled packages
> (the bundled p
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Are the claims in the Elisp manual and in the debug-on-entry docstring
> that debug-on-entry does not work for primitive functions still valid?
>
> I tried it on select-frame, a primitive function, and possibly one can
> not get all features, but a least
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> Currently, the parent of a derived mode's keymap is set by the mode
>> function. This means that if the docstring of a derived mode shows
>> the keybindings of its keymap, the bindings of the parent keymap are
>> not shown until the mode function is f
Richard Stallman <[EMAIL PROTECTED]> writes:
> Is the expansion of this define-derive-mode macro ever run in older
> Emacsen? Wouldn't delay-mode-hooks (used unconditionally) be missing
> as well, then?
>
> Shall I just delete the test?
>
> Please leave it alone. There is no need
Currently, the parent of a derived mode's keymap is set by the mode
function. This means that if the docstring of a derived mode shows
the keybindings of its keymap, the bindings of the parent keymap are
not shown until the mode function is first called. Why not set the
parent keymap at top-level
Eli Zaretskii <[EMAIL PROTECTED]> writes:
>> From: Lute Kamstra <[EMAIL PROTECTED]>
>> Date: Fri, 10 Jun 2005 00:34:34 +0200
>> Cc: emacs-devel@gnu.org
>>
>> > As long as the manual is not printed, who would see the edition
>> > number?
>&
Richard Stallman <[EMAIL PROTECTED]> writes:
> man/emacs.texi defines "@set EMACSVER 22.0.50" and uses
> "@value{EMACSVER}" to refer to Emacs' version. I'd like to do the
> same for lispref/elisp.texi. Any objections?
>
> Ok with me.
Done. I've also changed admin/admin.el so that E
Eli Zaretskii <[EMAIL PROTECTED]> writes:
>> So the edition is only increased when the manual is printed by the
>> FSF? That means that different versions of the manual can have the
>> same edition number. Isn't that confusing?
>
> As long as the manual is not printed, who would see the edition
I don't understand this piece of code at the end of
define-derived-mode in lisp/emacs-lisp/derived.el:
,
|;; Run the hooks, if any.
|;; Make the generated code work in older Emacs versions
|;; that do not yet have run-mode-hooks.
|(if (fboundp 'run-mode-hooks)
|
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Lute" == Lute Kamstra <[EMAIL PROTECTED]> writes:
>
> Lute> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>> I'm tracking CVS HEAD, building daily on OSX.
>
> Lute> W
Eli Zaretskii <[EMAIL PROTECTED]> writes:
>> Why not let the edition of the manual equal the version of Emacs?
>
> I think that's because not every version of Emacs automatically causes
> a new edition of the manual to be printed by the FSF. Producing a
> printed manual for sale in bookstores is
Eli Zaretskii <[EMAIL PROTECTED]> writes:
>> From: Lute Kamstra <[EMAIL PROTECTED]>
>> Date: Wed, 08 Jun 2005 12:49:16 +0200
>>
>> The Lisp Manual has its own version number (2.9 currently). Does this
>> serve any purpose now that we release it t
man/emacs.texi defines "@set EMACSVER 22.0.50" and uses
"@value{EMACSVER}" to refer to Emacs' version. I'd like to do the
same for lispref/elisp.texi. Any objections?
Lute.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman
The Lisp Manual has its own version number (2.9 currently). Does this
serve any purpose now that we release it together with Emacs? Why not
remove the version number and just say that it is the Lisp Manual
corresponding to Emacs version so-and-so?
Lute.
Lute Kamstra <[EMAIL PROTECTED]> writes:
> Using define-minor-mode to implement flyspell-mode seems a cleaner
> solution to me.
I just installed this fix. You may have to delete lisp/loaddefs.el to
make bootstrapping work again.
Lute.
_
Nick Roberts <[EMAIL PROTECTED]> writes:
> > After today's update of CVS Emacs, bootstrap failed with this error
> > when dumping Emacs:
> ...
>
> > It seems that autoload cookies are missing in flyspell.el for
> > flyspell-mode-map and other variables it refers to.
> >
> > The following p
David PONCE <[EMAIL PROTECTED]> writes:
[...]
> After today's update of CVS Emacs, bootstrap failed with this error
> when dumping Emacs:
[...]
> while building Emacs; they do not indicate a problem.
> ((15247 . 4070) (4364 . 4) (549 . 0) 104139 45313 (13 . 1)
> (17 . 0) (4954 . 527))
> Loadin
Richard Stallman <[EMAIL PROTECTED]> writes:
> Maybe Gnus can do something like:
>
> (or (fboundp 'run-mode-hooks)
> (defalias 'run-mode-hooks 'run-hooks))
>
> Definitely not! Gnus should not mess with the way Emacs defines
> (or doesn't define) these functions!
It seems that that
Katsumi Yamaoka <[EMAIL PROTECTED]> writes:
> run-mode-hooks is only available in Emacs 22, while Gnus v5.11
> still supports Emacs 20 and 21 (and No Gnus supports Emacs 21).
>
> 2005-05-26 Lute Kamstra <[EMAIL PROTECTED]>
>
> * score-mode.el (gnus-score-mod
Lute Kamstra <[EMAIL PROTECTED]> writes:
> Richard Stallman <[EMAIL PROTECTED]> writes:
>
>> If there are any major modes that fail to use run-mode-hooks, we want
>> to fix them now. It would be good for someone to look for them.
>
> I'll do that.
I&
Richard Stallman <[EMAIL PROTECTED]> writes:
> I believe that we plan to eventually make all modes run
> `after-change-major-mode-hook', usually as a byproduct of making them
> run their mode hook with `run-mode-hooks'.
>
> If there are any major modes that fail to use run-mode-hooks,
Bill Wohler <[EMAIL PROTECTED]> writes:
[...]
> Do you have any idea when string-to-number was introduced? I would
> like to simply substitute string-to-number for string-to-int, as you
> have done, but we are still supporting Emacs 20.7.
string-to-number was introduced in Emacs 19.7.
Lute.
_
Luc Teirlinck <[EMAIL PROTECTED]> writes:
[...]
> I also do not immediately understand why find-file-hook could not
> potentially run too early too.
If I understand things correctly, after-find-file first calls the
major mode function (by calling normal-mode) and then runs
find-file-hook.
Lute.
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Lute Kamstra wrote:
>
>You seem only to consider the problem that GLOBAL-MODE-buffers is not
>called. It can also be a problem when it is called too early.
>
> I agree that if run-mode-hooks is used, it should be run
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Lute Kamstra wrote:
>
>It is a problem in combination with a global minor mode defined with
>define-global-minor-mode since this change:
>
>2005-05-22 Luc Teirlinck <[EMAIL PROTECTED]>
>
> * ema
Stefan Monnier <[EMAIL PROTECTED]> writes:
[...]
> While I think that org-mode should use define-derived-mode, I'm wondering
> why it's a problem that after-change-major-mode-hook is run at the
> wrong time. After all, such manual mode derivation (without using
> define-derived-mode) is pretty c
Hi Carsten,
> I remember trying to do define-derived mode, but not doing it for a
> number of reasons which I do not exactly remember. The argument was
> one reason. Another was that older versions of define-derived-mode
> did not allow a BODY arguments which I needed.
> A third one was that or
org-mode in lisp/textmodes/org.el is derived from outline-mode, but it
doesn't use define-derived-mode to accomplish this. Instead, it just
calls outline-mode as the first thing it does. (I guess this is
because org-mode accepts an argument, which define-derived-mode
doesn't support.) The proble
Can somebody confirm that this change is correct?
Lute.
Index: src/eval.c
===
RCS file: /cvsroot/emacs/emacs/src/eval.c,v
retrieving revision 1.238
diff -C4 -r1.238 eval.c
*** src/eval.c 8 May 2005 16:30:13 - 1.238
--- sr
Nick Roberts <[EMAIL PROTECTED]> writes:
> Lute Kamstra writes:
> > Juanma Barranquero <[EMAIL PROTECTED]> writes:
> >
> > > This change
> > >
> > > 2005-05-24 Nick Roberts <[EMAIL PROTECTED]>
> > >
>
Juanma Barranquero <[EMAIL PROTECTED]> writes:
> This change
>
> 2005-05-24 Nick Roberts <[EMAIL PROTECTED]>
>
> * xmenu.c (Fx_popup_dialog): Add a third boolean argument to
> select frame title ("Question"/"Information").
> (xdialog_show): Use it.
>
> * lisp.h: F
Does anyone see any problems with the patch below? font-lock-defaults
is defined in lisp/font-core.el which is loaded by lisp/loadup.el
before any major modes are loaded. I checked that the patch
introduces no compiler warnings.
Lute.
Index: lisp/subr.el
===
Richard Stallman <[EMAIL PROTECTED]> writes:
> Thanks. WOuld someone please install this change?
Done.
Lute.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Lute Kamstra <[EMAIL PROTECTED]> writes:
> Stefan Monnier <[EMAIL PROTECTED]> writes:
>
>>> So, how do you make Font Lock use the function in the variable
>>> syntax-begin-function to move to top level?
>>
>> I don't understand the question. W
--
Are they perhaps also available somewhere on the Internet?
As you can see, I updated the FSF's address in emacs.texi. The
address is mentioned in almost every file in the distribution. Should
we update it before the release? Is there a decent script to automate
this?
Lute.
200
Dan Nicolaescu <[EMAIL PROTECTED]> writes:
> Am I the only one that finds the new makefile-shell-face annoying?
It's more than annoying on a 8-color console: it sets the background
color to white, while the foreground color of most of the text is
white as well.
Lute.
_
1 - 100 of 264 matches
Mail list logo
