"Drew Adams" <[EMAIL PROTECTED]> writes:
> Would you like it if isearch failed before proceeding to the
> next Info node?
>
> I would. I suggested this long ago. It should first wrap, as Richard
> suggested. After the entire Info node has been searched, it should
> fail. A subsequent invoca
| Jari Aalto <[EMAIL PROTECTED]> writes:
|
| > | >David Kastrup <[EMAIL PROTECTED]> writes:
| > | > no previous desire, not fitting the feature
| > | > freeze. Is this a plot to distract people from releasing?
| > |
| > | IMO, it is a reasonable opportunity to DTRT before locking M-g down as
| >
> - why can't they use the font-lock-multiline property?
> People are looking for a clearer explanation of what this does
> and how to use it.
All the consecutive chars with a non-nil font-lock-multiline property will
always be re-fontified together. E.g. if it is put on three consecutive
lin
Stefan Monnier wrote:
A Cairo port will probably make sense at some point, but I think that
anti-aliasing support for X11 (using xft) is more urgent.
A lot of people _think_ they need AA support. Until I tell them about
the terminus-font that is. :-)
I tested the AA branch but that developer dislik
- why can't they use the font-lock-multiline property?
People are looking for a clearer explanation of what this does
and how to use it.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Its a bit more subtle than that. GUD tooltips use track-mouse (ordinary
tooltips work at a lower level and don't rely on events in lisp). For a GUD
tooltip to work, the lisp-level mouse-movement event must be generated in
the
buffer with the overlay arrow and the mode of the selec
Even so, it would be several years before major modes could start using
it in earnest, due to the need to continue supporting older Emacs
versions.
Supporting other Emacs versions is a secondary issue. We will start
using this feature right away, in all the modes where it helps.
_
This patch to font-lock is exactly the sort of change I was thinking
of. Could someone please install it, then rename
before-font-lock-after-change-function to
font-lock-extend-region-function, and rename
font-lock-run-before-after-change-hook to font-lock-extend-region?
Hmmm. The advice facility exists within Emacs, and it is difficult to
see what it could be used on, aside from another part of Emacs. After
all, one does not need to advise one's own code, having full control over
the source.
It is meant for users to use in their Lisp code. We c
2. Defining two new abnormal hooks, maybe named yank-encode-functions and
kill-encode-functions, to be called by kill-region etc (or possibly the
lower-level functions like kill-new and kill-append.)
This would be better than using advice.
On further consideration, there seems to
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Kim F. Storm) writes:
> Kenichi Handa <[EMAIL PROTECTED]> writes:
>> I've just found that C-a moves point to the beginning of
>> previous line when hit at the end of buffer.
> Obscure pos-visible-in-window-p returned incorrect value for
>
Maybe not now, but an elegant rewrite may enable changes to make Emacs
more powerful and better in the future.
I am not saying these are useless, I am saying that people focus too
much on making Emacs "more powerful", disregarding other kinds of
improvements that we need. Most of the TODO
It's generally agreed that the user should be able to enable and disable
features at will. Should Tramp be a global minor mode a la
auto-compression-mode and auto-image-file-mode?
There is no general rule that every Emacs feature needs a minor mode
to enable and disable it. Is there
It seems this is the most reasonable default behavior.
But I also think it would be too annoying to fail before
leaving every Info node. It would be better to fail only
in the first Info node where isearch was started.
Yes, I think that is right.
Could you please do it?
Of
> > Something has broken in `mark-diary-entries' such that (setq
> > mark-diary-entries-in-calendar t) and related no longer work
> > correctly. It seems to be setting point to the beginning of the
> > calendar buffer (I think the previous behavior was to leave it on
> > the current date.)
>
> I
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> In about 25% of the cases the lisp-indent-hook property is used to
>> specify the desired indentation and in the remaining 75% of the
>> cases, the lisp-indent-function property is used. Is the second
>> preferred? (The docsting of the function lisp-
[EMAIL PROTECTED]
¡¡-
[EMAIL PROTECTED]@[EMAIL PROTECTED]@f«EpXgEnCq[
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL
PROTECTED]@[EMAIL
PROTECTED]@`ßéßtF`æE®æÌóÉ`--
Karl Chen <[EMAIL PROTECTED]> writes:
> Something has broken in `mark-diary-entries' such that (setq
> mark-diary-entries-in-calendar t) and related no longer work
> correctly. It seems to be setting point to the beginning of the
> calendar buffer (I think the previous behavior was to leave it on
- Original Message -
From: "Lennart Borgman" <[EMAIL PROTECTED]>
> - Original Message -
> From: "Eli Zaretskii" <[EMAIL PROTECTED]>
> > > I suggest removing the "#ifdef HAVE_X_WINDOWS" completely or (which I
> > > believe most would like better - but not I) replacing them with
>
> "Stefan" == Stefan Monnier <[EMAIL PROTECTED]> writes:
Stefan> A Cairo port will probably make sense at some point, but I
Stefan> think that anti-aliasing support for X11 (using xft) is more
Stefan> urgent.
I suspect that the amount of work to get fontconfig/xft support on top
of the curren
Stefan Monnier wrote:
> A Cairo port will probably make sense at some point, but I think that
> anti-aliasing support for X11 (using xft) is more urgent.
A lot of people _think_ they need AA support. Until I tell them about
the terminus-font that is. :-)
I tested the AA branch but that developer
On Thu, 10 Mar 2005, Stefan Monnier wrote:
>>> You may be right, but I'd like to see your code first, to see how easy and
>>> robust it is to use your hook.
>> I re-posted my tentative 2002 patch here last night.
>Read again: I said "use" not "define".
>I.e. I don't want to see the font-lock si
>> - why can't they use the font-lock-multiline property?
>> - why can't they use the jit-lock-defer-multiline property?
> One argument for a hook alternative to these things is that it might
> not be efficient/convenient to spread text properties all over the
> place:
You misunderstood: I'm not
> This would not be on top of the current X11 support, but parallel to
> it (and to the mac and win gui support). This leaves the X11 code
> as is to support platforms w/o cairo and by keeping legacy stuff out
> helps to ensure the new port is clean.
A Cairo port will probably make sense at some
Stefan Monnier <[EMAIL PROTECTED]> wrote:
> - why can't they use the font-lock-multiline property?
> - why can't they use the jit-lock-defer-multiline property?
One argument for a hook alternative to these things is that it might
not be efficient/convenient to spread text properties all over the
Something has broken in `mark-diary-entries' such that (setq
mark-diary-entries-in-calendar t) and related no longer work
correctly. It seems to be setting point to the beginning of the
calendar buffer (I think the previous behavior was to leave it on
the current date.)
--
Karl 2005-03-10 13:38
There have been various pleas and debates on this posted on and off
over at least the past several months.
There are several options for doing this, but I beleive Cairo (cf
http://cairographics.org) is the best choice.
This would not be on top of the current X11 support, but parallel to
it (and t
>> You may be right, but I'd like to see your code first, to see how easy and
>> robust it is to use your hook.
> I re-posted my tentative 2002 patch here last night.
Read again: I said "use" not "define".
I.e. I don't want to see the font-lock side of the code, but the awk-mode or
c++-mode side o
Hi, Stephan.
On Thu, 10 Mar 2005, Stefan Monnier wrote:
>> We talked about it in bug-cc-mode just after CC Mode 5.30 had been
>> released. (Subject: Advising in cc-awk.el and namespace Date: Wed, 09
>> Jul 2003 13:20:20 -0400). I drew attention then (Jul 2003) to the patch
>> I had submitted
> In about 25% of the cases the lisp-indent-hook property is used to
> specify the desired indentation and in the remaining 75% of the cases,
> the lisp-indent-function property is used. Is the second preferred?
> (The docsting of the function lisp-indent-function suggest this.)
> Should occurrenc
Richard Stallman wrote:
AFAIK it is a general M-x behaviour. Pressing return in the minibuffer
starts the hourglass, and then invokes minibuffer-complete-and-exit.
This function throws so the start_hourglass done after return is
canceled by an unwind-protect (in keyboard.c, command
I also think it would be too annoying to fail before
leaving every Info node. It would be better to fail only
in the first Info node where isearch was started.
Good point - I agree.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I've just downloaded Emacs from tla and pcl-cvs does not work anymore.
Here is what I did to compile Emacs :
tla register-archive http://sourcecontrol.net/~miles/[EMAIL PROTECTED]
~tla get [EMAIL PROTECTED]/emacs--cvs-trunk--0 emacs-cvs
~
I was trying to give (with-no-warnings ...) the same indentation as
(progn ...). Now I have a few question:
In about 25% of the cases the lisp-indent-hook property is used to
specify the desired indentation and in the remaining 75% of the cases,
the lisp-indent-function property is used. Is the
Would you like it if isearch failed before proceeding to the
next Info node?
I would. I suggested this long ago. It should first wrap, as Richard
suggested. After the entire Info node has been searched, it should fail. A
subsequent invocation should continue through the manual.
IOW, isear
Okay, let me wrap up how things work out for me:
(set-keyboard-coding-system 'mac-roman)
seems to be an easy way to make Emacs behave like one would expect it
to: all special combinations (umlauts, euro symbol, accents) work.
To make Emacs display the stuff the following works:
(create-fontset-fr
>> On a side note, I'm wondering why you go through so much trouble with the
>> "unmatched opening quote" in AWK. No other mode does that AFAIK, even
>> though pretty much every major mode in lisp/progmodes/ has pretty much the
>> same need AFAICT. Does it have to do with something specific to AW
On a side note, I'm wondering why you go through so much trouble with the
"unmatched opening quote" in AWK. No other mode does that AFAIK, even
though pretty much every major mode in lisp/progmodes/ has pretty much the
same need AFAICT. Does it have to do with something specific to AWK, or is
it
Reiner Steib <[EMAIL PROTECTED]> writes:
> On Thu, Mar 10 2005, Kim F. Storm wrote:
>
>> Reiner Steib <[EMAIL PROTECTED]> writes:
>>
>>> Wouldn't the "file:linenumber" feature require an absolute filename
>>> unless the buffer local value `default-directory' happens to be
>>> appropriate? I'd gue
Andreas Schwab <[EMAIL PROTECTED]> writes:
> Romain Francoise <[EMAIL PROTECTED]> writes:
>
>> David Kastrup <[EMAIL PROTECTED]> writes:
>>
>>> It would be somewhat consistent with typical Emacs applications if the
>>> file name was prompted for only when a prefix argument was given.
>>
>> Unfortu
Kenichi Handa <[EMAIL PROTECTED]> writes:
> I've just found that C-a moves point to the beginning of
> previous line when hit at the end of buffer.
Obscure pos-visible-in-window-p returned incorrect value for
first char in last line.
I have installed a fix.
--
Kim F. Storm <[EMAIL PROTECT
On Thu, Mar 10 2005, Kim F. Storm wrote:
> Reiner Steib <[EMAIL PROTECTED]> writes:
>
>> Wouldn't the "file:linenumber" feature require an absolute filename
>> unless the buffer local value `default-directory' happens to be
>> appropriate? I'd guess that such situations are rare (sender and
>> re
Romain Francoise <[EMAIL PROTECTED]> writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
>
>> It would be somewhat consistent with typical Emacs applications if the
>> file name was prompted for only when a prefix argument was given.
>
> Unfortunately, the prefix argument is already used to jump t
Reiner Steib <[EMAIL PROTECTED]> writes:
> Wouldn't the "file:linenumber" feature require an absolute filename
> unless the buffer local value `default-directory' happens to be
> appropriate? I'd guess that such situations are rare (sender and
> recipient often have different file locations).
I
> We talked about it in bug-cc-mode just after CC Mode 5.30 had been
> released. (Subject: Advising in cc-awk.el and namespace Date: Wed, 09
> Jul 2003 13:20:20 -0400). I drew attention then (Jul 2003) to the patch
> I had submitted in 2002, which you acknowledged. However, the topic of
> conv
On Thu, Mar 10 2005, Miles Bader wrote:
> Of course the usefulness of Gnus' local binding will have to be
> re-evaluated with the new global binding in mind (the old global
> binding of M-g was not at all useful for Gnus).
I don't think that goto-line (and friends) are important enough *in
Gnus*
David Kastrup <[EMAIL PROTECTED]> writes:
> It would be somewhat consistent with typical Emacs applications if the
> file name was prompted for only when a prefix argument was given.
Unfortunately, the prefix argument is already used to jump to the file
in another window.
--
Romain Francoise <[
Does anybody see any problems with the following patch?
Lute.
Index: lisp/emacs-lisp/debug.el
===
RCS file: /cvsroot/emacs/emacs/lisp/emacs-lisp/debug.el,v
retrieving revision 1.75
diff -c -r1.75 debug.el
*** lisp/emacs-lisp/debug.e
Jari Aalto <[EMAIL PROTECTED]> writes:
> | >David Kastrup <[EMAIL PROTECTED]> writes:
> | > no previous desire, not fitting the feature
> | > freeze. Is this a plot to distract people from releasing?
> |
> | IMO, it is a reasonable opportunity to DTRT before locking M-g down as
> | a single comm
Piet van Oostrum <[EMAIL PROTECTED]> writes:
>> [EMAIL PROTECTED] (Kim F. Storm) (KFS) wrote:
>
>>KFS> David Kastrup <[EMAIL PROTECTED]> writes:
Juri Linkov <[EMAIL PROTECTED]> writes:
> 2. goto-line is not too frequent command to deserve the sole
> M-g key. There are many
Romain Francoise <[EMAIL PROTECTED]> writes:
> Juri Linkov <[EMAIL PROTECTED]> writes:
>
>> It would be useful to move `dired-jump' to dired.el and to modify it
>> to ask the file name with the default set to buffer-file-name (or to
>> create a new similar function and bind it to M-g f).
>
> I can
On Thu, 10 Mar 2005 10:18:49 +0100, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
> >KFS> Huh? M-g was a prefix key before the change...
>
> Was it? In gnus it is bound to gnus-summary-rescan-group. At least in the
> version a month or so ago.
Yup. You're allowed to bind over prefix keys... :-)
> [EMAIL PROTECTED] (Kim F. Storm) (KFS) wrote:
>KFS> David Kastrup <[EMAIL PROTECTED]> writes:
>>> Juri Linkov <[EMAIL PROTECTED]> writes:
>>>
2. goto-line is not too frequent command to deserve the sole
M-g key. There are many other goto-related commands that could
share the
Hi,
When you edit and save a writable file in a non writable dir, and you
use `backup-by-copying' to nil (the default), backup-buffer fails to
make a backup in the place you define with `backup-directory-alist'
(because you cannot move files that are in a not writable dir), so it
copies it to fil
$B$!$?$7$H;W$C$F$?$1$I$5$9$,$K:#2s$OIi$1$?$+$i$b$&D|$a$k$h!#C;[EMAIL
(BPROTECTED](B
(B
(B
(B
(B
(B___
(BEmacs-devel mailing list
(BEmacs-devel@gnu.org
(Bhttp://lists.gnu.org/mailman/listinfo/emacs-devel
> > I think it would be a lot less annoying if it at least changed the
> > prompt to say what it was doing, in the manner of a wrapped isearch
> > ("I-search in node ...: " ?).
> >
> > Maybe it could even act more like wrapped i-search, and fail once,
> > before proceeding to the next info pa
Hi, Stefan.
On Wed, 9 Mar 2005, Stefan Monnier wrote:
>> [The discussion is about a font-locking problem reported in CC Mode: The
>> user types the start of a C function, but puts a NL in the middle:
>> void function
>> (int x);
>> The second line gets incorrectly fonti
57 matches
Mail list logo
