> From: Juri Linkov <[EMAIL PROTECTED]>
> Date: Fri, 13 May 2005 08:03:54 +0300
> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
>
> The new option compilation-current-message-highlight will support
> three values: `arrow', t for highlighting the whole current message
> line, and nil to turn all indic
> I don't like this change because its not the case that one user wants an arrow
> and another doesn't but rather one context may benefit from an arrow
> (graphical display) while another may not (text terminal).
>
> Previously I have suggested a change that gives compilation-context-lines a
> cont
> Seems odd to introduce a new face whose name refers to "comment" even
> though the only two known uses for it are not for comments but for
> email citations.
> Those were the only uses yet implemented for it,
> but now I've changed font-lock-fontify-syntactically-region
> to use it f
Message$B!!(BFrom$B!'(Bhttp://www.lovegal2.net?fumiko3
$B%$%-%J%j$N%a!<%k$G6C$+$;$F$7$^$C$F?=$7Lu$4$6$$$^$;$s!#!!(B
$B1356$j$J$/@5D>$KOC$9$N$G!";d$K>/$7IU$-9g$C$FD:$1$^$;$s$G$7$g$&$+!)!!(B
$BC1=c$JL\E*$H$7$F$O!"5.J}$H;[EMAIL PROTECTED]:$-$?$/%a!<%k$r(B
$B$7$?$,$"$l$
> For C++ mode, it doesn't quite work:
>foo // comment1
>bar /* comment2 */
> The // and /* are put in font-lock-comment-delimiter-face (which I find to
> be useless clutter and makes the text less legible without helping
> understand the structure), but the */ is l
> * font-lock.el (font-lock-comment-delimiter-face): Inherit from
> font-lock-comment-face rather than copying its setting.
> font-lock-comment-delimiter-face differs from font-lock-comment-face
> under X. They used to be Firebrick; now font-lock-comment-delimiter-face
> changed to re
For C++ mode, it doesn't quite work:
foo // comment1
bar /* comment2 */
The // and /* are put in font-lock-comment-delimiter-face (which I find to
be useless clutter and makes the text less legible without helping
understand the structure), but the */ is left with ju
> It occur to me that we could make it easier to find those places.
> Suppose that by default the `evaporate' property is set to
`display-warning'.
> Suppose that in this case, when the overlay becomes empty, it evaporates
> and displays a warning using `display-warning'.
We c
This seems right to me. Are there any reasons why the latest
development release of ispell.el is not synced with Emacs CVS?
In principle there is no reason--it would be good to install
the latest code. Ken, could you do this soon?
___
Emacs-d
However, the installed change is too radical.
It affects all users of ispell having aspell in exec-path.
Preferring aspell to ispell will inevitably do that.
It is the price that must be paid for a change that we will make
sooner or later.
We are going to switch to preferring aspell som
I don't like this change because its not the case that one user wants an
arrow
and another doesn't but rather one context may benefit from an arrow
(graphical display) while another may not (text terminal).
I agree.
And doesn't the current code do exactly this?
___
i'm presently updating the copyright years in lisp/net/ and
have come upon a doubt: certain files have been merged from
outside emacs, w/ copyright notices that show years prior
to their merging (as far as i can tell from looking at the
"cvs log" output for these files). i am i
Binding a non-command object (a process) to this-command looks quite
obscure and unclean to me.
To me it seems natural. The filter was not run by any user command,
so I'm suggesting the idea that the command that ran the filter code
is the process itself.
Lots of commands look at thi
Since this change:
2005-05-12 Stefan Monnier <[EMAIL PROTECTED]>
* font-lock.el (font-lock-comment-delimiter-face): Inherit from
font-lock-comment-face rather than copying its setting.
font-lock-comment-delimiter-face differs from font-lock-comment-face
under X. They used to b
Hello all,
The attached patch is for LP64 support of Emacs CVS HEAD
on Mac OS X 10.4 + G5.
(But it does not support neither Carbon nor X11 (terminal only)).
Before compiling emacs, you need libncurses for ppc64 architecture:
1. get source files ncurses-15.tar.gz from darwin site and extract it.
> * Richard Stallman <[EMAIL PROTECTED]> [2005-05-12 07:15:37 -0400]:
>
> Loading jka-cmpr-hook...
> Wrong type argument: stringp, 0
>
> Can you run this under GDB with a breakpoint at Fsignal?
> Then do backtrace and xbacktrace, and the info will probably
> enable me or someone to fix the
"Eli Zaretskii" writes:
> This uses exec-installed-p, which we don't have. Where is it from?
I have been the developer and maintainer of this for years - however, I
have become neglectful of late due to work, family, and other
volunteering loads.
I have a version that doesn't use exec-installe
Kim F. Storm wrote:
> I would expect it to be buffer local, and as such, it would only be
> triggered by filter functions that update that buffer.
But when a filter function updates the buffer, this change function
(whether global or buffer local) should do nothing.
But even the change function wer
Stefan Monnier wrote:
> Could you give us more info about what you're trying to do. Maybe
> there's a better way.
There certainly is a better way, suggested on gnu.emacs.sources several
years ago by Dave Love, but I haven't had the time to properly
generalize it. What I'd like to do right now is
Lute Kamstra <[EMAIL PROTECTED]> writes:
> Richard Stallman <[EMAIL PROTECTED]> writes:
>
>> Does anybody know why authors in lisp/emacs-lisp/authors.el doesn't
>> parse ChangeLogs in lispref/? I'd like to change that.
>>
>> Perhaps it has not been updated since we put lispref/ into the E
Richard Stallman wrote:
>(when (featurep 'dnd)
> (make-variable-buffer-local 'dnd-protocol-alist)
> (setq dnd-protocol-alist
I think this should be `make-local-variable'.
Yes.
My favorite Emacs Lisp idiom:
(set (make-local-variable 'foo) ...)
--
Kevin Rodgers
Richard Stallman <[EMAIL PROTECTED]> writes:
> Does anybody know why authors in lisp/emacs-lisp/authors.el doesn't
> parse ChangeLogs in lispref/? I'd like to change that.
>
> Perhaps it has not been updated since we put lispref/ into the Emacs
> distribution.
It explicitly excludes lisp
I will try it shortly. I have one concern though---does this code
take care of the situation when the buffer was modified even before
insert-file-contents is called?
Yes.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.or
Does anybody know why authors in lisp/emacs-lisp/authors.el doesn't
parse ChangeLogs in lispref/? I'd like to change that.
Perhaps it has not been updated since we put lispref/ into the Emacs
distribution. Maybe there are other dirs it doesn't cover, too.
Could you check?
_
I think that is a bug--please do fix it.
What about the following patch, which fixes the problem? I can
install if desired.
It looks clean to me.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/em
>> No, because the after-change-function is generic
> I would expect it to be buffer local, and as such, it would only be
> triggered by filter functions that update that buffer.
Well, to tell you the truth, given the lack of info, I actually have
no idea. My impression is that the OP is writing
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> Doesn't the following work?
>
>> (defvar in-my-filter-p nil)
>
>> (defun my-filter (proc text)
>> (let ((in-my-filter-p t))
>> ...))
>
>> (defun my-after-change-function ()
>> (if in-my-filter-p
>> ...
>
> No, because the after-change-funct
Richard Stallman <[EMAIL PROTECTED]> writes:
> If I understood correctly, define-generic-mode only started
> constructing automatic defcustoms recently, which was an incompatible
> change. In that case, it could easily be reversed, which would make
> the two major mode defining f
> Cc: emacs-devel@gnu.org
> From: Stefan Monnier <[EMAIL PROTECTED]>
> Date: Thu, 12 May 2005 08:42:32 -0400
>
> > . on Windows, check_executable uses stat to verify executability
> > . on Posix systems, check_executable uses euidaccess if it's available
> > . by contrast, openp always uses
> Doesn't the following work?
> (defvar in-my-filter-p nil)
> (defun my-filter (proc text)
> (let ((in-my-filter-p t))
> ...))
> (defun my-after-change-function ()
> (if in-my-filter-p
> ...
No, because the after-change-function is generic and doesn't know about all
the various filt
Richard Stallman <[EMAIL PROTECTED]> writes:
> Is there a way to tell whether a function was called via process filter?
>
> Not currently.
Doesn't the following work?
(defvar in-my-filter-p nil)
(defun my-filter (proc text)
(let ((in-my-filter-p t))
...))
(defun my-after-change-funct
>> > Yes. But since you obviously didn't read my identical comment posted
>> > in response to your suggestion to do what you just did in this version
>> > of executable-find (or perhaps you read it, but disregarded it), I
>> > posted the same comment again.
>>
>> Hmm... I replied to it in
>> http
Thien-Thi Nguyen <[EMAIL PROTECTED]> writes:
> i'm presently updating the copyright years in lisp/net/ and
> have come upon a doubt: certain files have been merged from
> outside emacs, w/ copyright notices that show years prior
> to their merging (as far as i can tell from looking at the
> "cvs l
> I suggest adding a new option defining how to highlight lines
> in compilation/grep buffers, similar to `next-error-highlight'
> which defines highlighting in source buffers. It will replace
> `compilation-context-lines':
>
> (defcustom compilation-message-highlight 0
> "*Highlighting
Is there a way to tell whether a function was called via process filter?
Not currently.
We could envision making the code that calls process filters
bind this-command to the process that sent the output.
That is an incompatible change, but your arguments show
that probably the code that runs
Today's GNU Emacs CVS snapshot, Thu, 2005 May 12 11:04 UTC
GNU Emacs 22.0.50.5 (i686-pc-linux-gnu, GTK+ Version 2.6.4)
started with
src/emacs -Q -D
Unable to run tramp because
Autoloading failed to define function executable-find
Debugger entered--Lisp error: (error "Autoloading fa
Loading jka-cmpr-hook...
Wrong type argument: stringp, 0
Can you run this under GDB with a breakpoint at Fsignal?
Then do backtrace and xbacktrace, and the info will probably
enable me or someone to fix the bug.
___
Emacs-devel mailing list
Ema
i'm presently updating the copyright years in lisp/net/ and
have come upon a doubt: certain files have been merged from
outside emacs, w/ copyright notices that show years prior
to their merging (as far as i can tell from looking at the
"cvs log" output for these files). i am inclined to remove
th
> From: Juri Linkov <[EMAIL PROTECTED]>
> Date: Thu, 12 May 2005 09:14:47 +0300
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
> [EMAIL PROTECTED]
>
> To my surprise I just discovered that the latest development release of
> ispell.el at http://kdstevens.com/~stevens/ispell-p
ispell and aspell use different dictionaries. Changing the default
ispell program name from "ispell" to "aspell" is an incompatible
change for users configured Emacs to use ispell dictionaries,
not aspell dictionaries.
Maybe aspell could support ispell dictionaries. Or, aspell co
>(when (featurep 'dnd)
> (make-variable-buffer-local 'dnd-protocol-alist)
> (setq dnd-protocol-alist
I think this should be `make-local-variable'.
Yes.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org
If someone is interested in working on Perl mode,
here's something to do.
--- Start of forwarded message ---
Date: Wed, 11 May 2005 11:30:49 +0200 (CEST)
From: na frederic <[EMAIL PROTECTED]>
To: bug-gnu-emacs@gnu.org
Subject: trouble with perl indentation
Sender: [EMAIL PROTECTED]
X-Spam-
>> There was a disagreement about what the code should look like (I don't
know
>> the specifics but my understanding is that Richard wanted some changes
that
>> Ilya rejected), so his version and the Emacs version are not the same.
I don't remember for certain what happened. I think
Richard Stallman <[EMAIL PROTECTED]> writes:
> Perhaps it would be better for overlays to evaporate by default.
>
> I tend to agree this would make things better in most cases, and only
> be wrong in a few. However, it is an incompatible change, and in some
> places it WILL break code.
And s
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED],
> [EMAIL PROTECTED], emacs-devel@gnu.org
> From: Juri Linkov <[EMAIL PROTECTED]>
> Date: Thu, 12 May 2005 08:29:55 +0300
>
> > (1) user doesn't have aspell installed
> > (2) user has aspell installed, but configured it to use ispell's
> >
> Cc: emacs-devel@gnu.org
> From: Stefan Monnier <[EMAIL PROTECTED]>
> Date: Wed, 11 May 2005 19:16:46 -0400
>
> > Yes. But since you obviously didn't read my identical comment posted
> > in response to your suggestion to do what you just did in this version
> > of executable-find (or perhaps you
46 matches
Mail list logo
