My original patch for font-lock.el had problems. It did not work well
for modes that only use font-lock for font-lock-face and it did not
work for modes with a non-standard font-lock-function. I now propose
to leave font-lock.el unchanged and to apply the patch below to
font-core.el instead.
I a
> Nick Roberts wrote:
>
> > But shouldn't the cursor change to a hand cursor rather than an arrow
> > cursor when hoovering over a mouse-face?
>
>Following the change, if you have just line-number-mode on ,then the arrow
>pointer still displays over this area (I think this may be
In article <[EMAIL PROTECTED]>, Richard Stallman <[EMAIL PROTECTED]> writes:
>>;; Date lines, new and old styles.
>> !
>> ("^\\([1-9][0-9][0-9][0-9]-[0-9-]+\\|\\(Sun\\|Mon\\|Tue\\|Wed\\|Thu\\|Fri\\|Sat\\|Sun\\)
>> \\sw\\sw\\sw\\)[0-9:+ ]*"
>> (0 'change-log-date-face)
>
> Richard Stallman <[EMAIL PROTECTED]> writes:
>> Gnus should define a function called gnus-run-mode-hooks, which calls
>> run-mode-hooks if that is defined, otherwise run-hooks. Then all the
>> modes in Gnus could use gnus-run-mode-hooks.
> In <[EMAIL PROTECTED]>
> Lute Kamstra <[EMAI
> Better use:
>
>(defalias 'mymodule-function-in-doubt
> (if (fboundp 'function-in-doubt)
> 'function-in-doubt
>(lambda (..) ...)))
I was only highlighting the fact that defining functions from "future"
Emacsen is Not Good, but yes, your way is better. Every non-contrive
On 5/27/05, Richard Stallman <[EMAIL PROTECTED]> wrote:
> I think the former is cleaner, but the latter is also ok
> if it is more convenient.
I finally used the former, but I had to do:
extern Lisp_Object Qrisky_local_variable;
Fput (intern ("image-library-alist"), Qrisky_local_variable, Qt
Nick Roberts wrote:
> But shouldn't the cursor change to a hand cursor rather than an arrow
> cursor when hoovering over a mouse-face?
Following the change, if you have just line-number-mode on ,then the arrow
pointer still displays over this area (I think this may be an existing
gentlemen .
i need to get in cotact with this guy he has the cornell code for
cuseeme.
**
Zaheer Shamsi ([EMAIL PROTECTED])
Wed, 29 Apr 1998 02:27:21 +0800 (MYT)
Environment: Win95, Visu
> But shouldn't the cursor change to a hand cursor rather than an arrow
> cursor when hoovering over a mouse-face?
Following the change, if you have just line-number-mode on ,then the arrow
pointer still displays over this area (I think this may be an existing
bug not an introduced one).
Nick
Lute Kamstra <[EMAIL PROTECTED]> writes:
> It seems that that I was badly educated by code I read: I've quite
> often seen the use of constructs like the one above.
There is, or at least used to be, a fair amount of bad old code that
does stuff like that. One of the worst offenders was (not sure
To clarify, this is how comint enables Font Lock:
(defcustom comint-mode-hook '(turn-on-font-lock)
...
Without delay-mode-hooks, this is executed at the end of the call to
comint-mode. With delay-mode-hooks, it is run during the call to
run-mode-hooks, just before your own hook. Note that a use
Thien-Thi Nguyen <[EMAIL PROTECTED]> wrote:
> Richard Stallman <[EMAIL PROTECTED]> writes:
>
> > The goal now is to *find* possible bugs. The patch should set the
> > property to something unusual (maybe `never-set') by default. When
> > such an overlay becomes empty, there should be some sort o
Both Stefan and me might have partially misunderstood your problem.
`sql-interactive-mode' calls comint-mode without enclosing it in a
delay-mode-hooks form, as it should. To standardize your mode, you
should either define it using `define-derived-mode' (see `(elisp)Derived
Modes') or read `(elis
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Richard Stallman <[EMAIL PROTECTED]> wrote:
> Perhas you're saying that the mh-e group is intended as an alias for
> the mh group. Is that what you really want? We could arrange some way
> of doing that.
That's correct. We would not want both "mh" and "mh-e" to appear in the
"mail" group.
Howe
* Masatake YAMATO (2005-05-13) writes:
> I've implemented mouse-face on mode-line.
On my system (GTK-enabled CVS Emacs from yesterday on X11) the active
regions flicker quite a lot when the mouse pointer is moved over them.
Also CPU usage increases considerably while doing this.
--
Ralf
>From my earlier message:
When testing this patch, do not rely on stuff like `C-h v
font-lock-set-defaults', because this is currently buggy.
This is a consequence of a bug I reported in another thread,
`Bug in buffer-local-value'.
Sincerely,
Luc.
__
[EMAIL PROTECTED]<[EMAIL PROTECTED]@-$,Cf?4(B
$B$H$J$j2q0wMM$KF|:"$h$j4JC1$JBg?M8r:]$rDs6!$7$F$*$j$^$7$F!"8=(B
$B:_$G$O$*$+$2$5$^$GBgJQ9%I>[EMAIL PROTECTED][EMAIL PROTECTED]>R2p$r(B
$B9T$C$F$$$^$7$?$,!"(BGW$BO"[EMAIL PROTECTED])?t$,5^A}$7$?$?$a!"NW;~$K(B
$BDI2CJg=8$r$7$?$$$H;W$$%a!<
Here are my proposed changes to easy-mmode.el. Unlike my previous
proposed patch, they require some cooperation from the individual
minor modes, but this seemed necessary to catch (and attempt to work
around) all possible ways to mess up the major mode for which the
minor mode is set up. The onl
> I've run into the same problem in sql-mode; the need to alter the
> font-lock rules after font-lock-mode has been enabled. My current
> solution is as follows:
> ;; Force font lock to reinitialize if it is already on
> ;; Otherwise, we can wait until it can be started.
> (when (and
> > I've implemented mouse-face on mode-line.
> >
>
> This looks nice!
>
> But shouldn't the cursor change to a hand cursor rather than an arrow
> cursor when hoovering over a mouse-face?
Thank you for suggestion. I've installed a new patch. Please, try again.
Masatake YAMATO
___
Hi,
It would be nice if the specified mode in (compilation-start) would get
activated before inserting anything (i.e. the mode setter line) into the
buffer.
In a function which I added to compilation-mode-hook I change some
fontification things including the used font. When (compilation-sta
> (if (fboundp 'function-in-doubt)
> (defalias 'mymodule-function-in-doubt 'function-in-doubt)
> (defun mymodule-function-in-doubt ...))
Actually this form has the disadvantage that the
byte-compiler would have to check which functions
are defnied in every branch
Michael Mauger wrote:
;; Force font lock to reinitialize if it is already on
;; Otherwise, we can wait until it can be started.
(when (and (fboundp 'font-lock-mode)
(boundp 'font-lock-mode)
font-lock-mode)
(font-lock-defontify)
> Using completely different color for the same action is too confusing.
> If there is not enough contrast between adjacent highlighted and
> active/inactive mode line areas, then the color of mode-line-highlight
> could be adjusted to a darker color. For example, replacing "DarkSeaGreen2"
> used
> (if (fboundp 'function-in-doubt)
> (defalias 'mymodule-function-in-doubt 'function-in-doubt)
> (defun mymodule-function-in-doubt ...))
Actually this form has the disadvantage that the byte-compiler would have to
check which functions are defnied in every branch. And snice it doesn't
>Good improvement, but there is no reason to have two different faces
>with different colors for the same purpose - highlighting text areas
>under the mouse pointer.
>
> I believe there is, because the mode line has a different background face.
> I believe that the regular highlight fac
Michael Mauger wrote:
;; Force font lock to reinitialize if it is already on
;; Otherwise, we can wait until it can be started.
(when (and (fboundp 'font-lock-mode)
(boundp 'font-lock-mode)
font-lock-mode)
(font-lock-defontify)
Hi,
the C++ header file which led to the problematic BROWSE file reads
namespace test {
class Base
{
};
class B : public Base
{
};
}
class A : public test::Base
{
};
The *Tree* is then displayed as
*Globals*
test
test::Base
test::B
The class A seems to be m
From: Luc Teirlinck <[EMAIL PROTECTED]>
> Juri Linkov wrote:
>
>Good improvement, but there is no reason to have two different faces
>with different colors for the same purpose - highlighting text areas
>under the mouse pointer.
>
> I believe there is, because the mode line has a diff
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
Hello,
Short: When specifying a value for hscroll-margin which is quite large
relative to the window width, Emacs freezes up and takes 100% CPU.
Long: I have set hscroll-margin to a value of 20 so I can see the next
words in a buffer before reaching the margin. I also use the "Emacs
Code Br
Juri Linkov wrote:
Good improvement, but there is no reason to have two different faces
with different colors for the same purpose - highlighting text areas
under the mouse pointer.
I believe there is, because the mode line has a different background face.
I believe that the regular high
> Much, much easier to just use md5().
Even though I like when thumbnail file names are composed from file
name parts (this allows to purge old thumbnails based on their names),
this method is not reliable, because thumbnails don't get updated when
image file contents changes.
AFAIK, GIMP uses md
Luc Teirlinck dms.auburn.edu> writes:
>
> Stefan Monnier wrote:
>
>Can you explain the change?
>I really don't like the
>
> (defun turn-on-font-lock-as-appropriate ()
>(let (font-lock-set-defaults)
>(turn-on-font-lock-if-enabled)))
>
>since it may cause font-l
> *** Mouse-face on mode-line(and header-line) is now supported.
> `mode-line-highlight' is the standard face indicating mouse sensitive
> elements on mode-line(and header-line) like `highlight' face on text
> areas.
Good improvement, but there is no reason to have two different faces
with dif
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 "(defun [-a-z]+-mode "
and that does not contain "(run-".
> ;; Date lines, new and old styles.
> !
("^\\([1-9][0-9][0-9][0-9]-[0-9-]+\\|\\(Sun\\|Mon\\|Tue\\|Wed\\|Thu\\|Fri\\|Sat\\|Sun\\)
\\sw\\sw\\sw\\)[0-9:+ ]*"
> (0 'change-log-date-face)
> Shouldn't that regexp end with + rather than *?
The original regexp also
What is the recommended way to set 'risky-local-variable for a Lisp
variable defined in C code?
extern Qrisky_local_variable;
Fput(Vmy_var, Qrisky_local_variable, Qt);
or an autoload
;;;###autoload (put 'my_var 'risky-local-variable t)
I think the former is cleaner
Indeed, but I think it's worth mentioning it in the docstring since I got
caught by it: it's a sensible limitation, but it's not an obvious one.
Please add this info to the doc string if you want.
___
Emacs-devel mailing list
Emacs-devel@gnu.or
If that's your idea of the best patch, would you please
install it?
supercite does not need a lot of maintenance, but once
in a while it does. Could you possibly be its maintainer?
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/
Is it possible to use run-hooks in those Emacs versions?
Yes, but it won't always be correct.
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 d
Masatake YAMATO <[EMAIL PROTECTED]> writes:
> I've implemented mouse-face on mode-line.
>
This looks nice!
But shouldn't the cursor change to a hand cursor rather than an arrow
cursor when hoovering over a mouse-face?
--
Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk
___
Juri Linkov wrote:
> > In a French locale, C-h T shows the French tutorial which includes
> > some NBSP chars which are rendered as "\ " as in "m\ emacs\ ".
> > The \ are clearly undesirable here.
>
> [...]
>
> A better indication for non-breaking spaces and hyphens is the same
> as for whitespace
> In a French locale, C-h T shows the French tutorial which includes
> some NBSP chars which are rendered as "\ " as in "m\ emacs\ ".
> The \ are clearly undesirable here.
This could be fixed by adding `show-nonbreak-escape: nil' to tutorial's
file local variables. But I think that adding escape
> For instance, emacs/src/ChangeLog has this line near the
> end.
>
> See ChangeLog.9 for earlier changes.
>
> When I visit this file and turn on font-lock mode, "See
> Change" (the first 10 characters) gets change-log-data-face.
>
> It seems that the attached change fix the problem, but, it
> may
>>> However, if Info-goto-node is a useful thing to use from outside Info,
>>> perhaps it should be defined as autoloaded in info.el rather than in mh-e.
>>
>> No. Elisp packages that want to invoke info this way should use the `info'
>> function, which can be called just the same: (info "(mh-e)Dr
Miles Bader <[EMAIL PROTECTED]> writes:
> It's an inordinately cute concept (especially the name, "Emacs
> Reference Mug" :-) but cafepress mugs seem to have a bad rep for
> fading quickly...
Anyway, what we really need is an Emacs Reference barrel.
--
David Kastrup, Kriemhildstr. 15, 44793 Boc
Jason Rumney wrote:
>
> Rather than patch the source, can you please try to debug the startup
> code at the bottom of w32menu.c that decides whether to use Unicode
> menu names. Does Windows ME have a stubbed out version of
> unicode_append_menu (AppendMenuW) that does nothing? The code assumes
>
$B5.J}$OEv%0%k!<%W(B([EMAIL PROTECTED](B)[EMAIL PROTECTED];$G$9!#(B
$B!!(B
$B"(G'>Z%3!<%I!!(B<3305>
$B$3$N%a!<%k$r3+Iu$7$F#2#4;~4V0JFb$K2q0wEPO?(B($BL5NA(B)$B$r:Q$^$;$l$P!"$J$s$H!)(B
$B!!!D!Z(B10$BJ,![$GBT$A9g$o$;!D(B
$B"-!!"-!
> 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 ".
For searching in Lisp structures I use the f
> Maybe Gnus can do something like:
>
> (or (fboundp 'run-mode-hooks)
> (defalias 'run-mode-hooks 'run-hooks))
(Not in this case, that's already been fixed but) that would not be good.
The usual answer is making your own lookalike:
(if (fboundp 'function-in-doubt)
(defalias 'mymodul
> Indeed, but I think it's worth mentioning it in the docstring since I got
> caught by it: it's a sensible limitation, but it's not an obvious one.
Yes, you're right.
OTOH, to fix the function (other than modifying the docstring), I
think there's no need to make a new convert-standard-filename-e
$B!!(.(!(,(!(,(!(,(!(,(!(,(!(/(B
$B!!"!!~"!!~("!!6[5^!*5^!*5^!*Jg=8!!("!~"!!~"!(B
$B!!(1(!(,(!(,(!(,(!(,(!(,(!(0(B
$B!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&(B
$B!!Ev%0%k!<[EMAIL PROTECTED]@Z$N$*R2pCW$7
54 matches
Mail list logo
