Consider the following stretch of elisp code:
(defvar foo
"string ..
.
."
( "doc ..
.
.
..")
Suppose I change some text on the line below "doc. `syntax-ppss' using
`syntax-begin-function' will record something like (1 X ... (X)) where X
is the
Hi,
I have noticed that error
flyspell-large-region: Can't check region...
is still present in some special situations, where flyspell-large-region is
called without ispell-check-version being called first.
That error was caused by the change in behavior of the aspell "-l" option,
and fixed by
Hi,
I am attaching a possible patch for handling localwords in
flyspell-large-region function. The reason for this is as follows.
I have been using flyspell in a large file having a number of words declared
valid in LocalWords for that file, and running flyspell-buffer is rather
slow, because all
Please disregard my previous mail. I mixed this up with the pre
regexp-opt version. regexp-opt should duly insert the required
group delimiters.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Apparently the delimiters of the sixth group are missing. Unless this
has been fixed already you could try:
(defun sh-font-lock-keywords-1 (&optional builtins)
"Function to get better fontification including keywords."
(let ((keywords (concat "\\([;(){}`|&]\\|^\\)[ \t]*\\(\\("
Richard wrote:
> > That is why I suggested recording these ppss values in text
> > properties of the first character on a line--so that they would stay
> > around for comparison later.
>
> That would be fine. But recording these properties for each and every
> line fontifie
> This is ugly: problems specific to emacs-lisp-mode should not be fixed in
> jit-lock but in lisp-mode.el. I'm not sure how to fix it, tho. Maybe you
> could (in lisp-font-lock-syntactic-face-function) place
> a jit-lock-defer-multiline property.
>
It's ugly. I'll defvar a jit-lock-context-re
> My gut feeling is that this is way past the point of diminishing returns.
> Already his optimization is rarely noticeable, but breaks a couple
> (rare) special cases.
>
In the patch below I provide three variables recording the behavior of
contextual fontification
jit-lock-fail-change records
> It would be better just to keep comparing until you reach a line that
> previously was fontified. After all, the line that was not fontified
> before certainly should get fontified, if it is on the screen. But a
> subsequent line that was previously fontified may not need to be
> changed.
>
T
Stefan wrote:
> In the above case, the syntax-ppss state changes, so using that would solve
> this problem. But changing
>
> (defvar foo 1
> "hello")
> to
> (defvar foo 0 1
> "hello")
>
> also requires a similar refontification, but the syntax-ppss state doesn'
>>Hence in at least 99 out of 100 cases contextual fontification just slows
>>down editing and wastes processor cycles.
>
>
> In theory, that's true. In practice, I've yet to come up with a case where
> it's noticeable. Have you actually perceived this slow down, or are
> talking hypothetically?
With contextual fontification turned on jit-lock exposes yet another
inefficiency. When changing text you trigger eventual execution of
`jit-lock-context-fontify' which removes the `fontified' text property
from the current and all subsequent lines in the buffer. This has two
unpleasant conseque
> How 'bout the patch below instead?
>
>
> Stefan
>
>
> --- orig/lisp/font-lock.el
> +++ mod/lisp/font-lock.el
> @@ -1058,7 +1058,8 @@
> 'font-lock-multiline nil)
>(point-max)))
> (goto-char end)
> -(setq end (line-beginnin
>> (when font-lock-multiline
>>(setq end (or (text-property-any end (point-max)
>> 'font-lock-multiline nil)
>> (point-max)))
>> (goto-char end)
>> (setq end (line-beginning-position 2
This is for you
http://adsfree.50megs.com
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
`jit-lock-fontify-now' contains the line
(setq next (line-beginning-position 2))
`font-lock-default-fontify-region' contains the line
(setq end (line-beginning-position 2))
In practice this means that when jit-lock is turned on, every time you
type a character jit-lock refontifies the
> The default setting of font-lock-lines-before makes it a nop (as it
> should). Major modes which rely on it should set it to the
> appropriate value.
You should modify the corresponding entry in the Elisp manual too.
___
Emacs-devel mailing list
E
>>Suppose not: Wouldn't that mean `font-lock-lines-before' is useless?
>
>
> Not at all.
Then you mean that `font-lock-lines-before' is useless with jit-lock?
> ... font-lock-lines-before has not been introduced to force
> refontification of the previous lines but because the N previous lines ar
> Because this means that every time I insert one character, redisplay
> would refontify `font-lock-lines-before' in addition to the current
> line.
>
> Would that be bad?
It would slow down editing long lines. jit-lock is supposed to make
editing faster.
>
> Whether and when
Stefan Monnier wrote:
>>The customizable variable `font-lock-lines-before' is not honored by
>>jit-lock mode.
>
>
> I know what that means in therms of what the code does, but I'm wondering in
> which circumstance it makes a visible difference to the end user.
> Do you have a test case?
>
>
Suppo
> (2) Modify `jit-lock-after-change' appropriately by, for example,
inserting
>
>(forward-line (- font-lock-lines-before))
>
> before
>
>(setq start (line-beginning-position))
>
> That seems like the right fix. Why do you think it isn't?
>
>
Because this means that every
> However, the
> associated tags are not assgined a face like `custom-variable-tag'.
>
> I don't understand that sentence at all, sorry.
>
>
Consider, for example, the customization buffer for `matching':
(1) `match' stands out in `custom-face-tag-face', by default scaled by
1.2 and
The customizable variable `font-lock-lines-before' is not honored by
jit-lock mode. That's irritating since jit-lock is turned on by default
and other font-lock variables _are_ respected when jit-lock is active.
Below find two proposals:
(1) Preserve the current state of affairs and provide the
The Emacs Lisp manual specifies the window property of an overlay as:
`window'
If the `window' property is non-`nil', then the overlay applies
only on that window.
This works well with most overlay properties. Executing
(defun foobar ()
(interactive)
(insert "foo")
(let ((overl
A number of customization groups like matching, view, ispell, ibuffer,
use `(defcustom ... :type 'face)' for customizing faces. However, the
associated tags are not assgined a face like `custom-variable-tag'. As
a consequence, the associated customization buffers become less
intelligible.
Is th
(defcustom blink-matching-paren-distance (* 25 1024)
"*If non-nil, is maximum distance to search for matching open-paren."
:type 'integer
:group 'paren-blinking)
The doc-string implies that this variable can be nil but customize does
not permit setting it to nil. Moreover, the doc-string s
Does this version work right?
(defun blink-matching-open ()
"Move cursor momentarily to the beginning of the sexp before point."
(interactive)
...
It does, but I would apply some further changes:
(1) Relocate the comment "Don't log messages about paren matching.".
(2) Replace "(/= (cha
What is the purpose of the "What's This?" entry in the Describe submenu
of the Help menu? The only difference to the "Describe Key..." entry
beneath is that the latter is bound to `describe-key-1' which is
not defined anywhere.
___
Emacs-devel mailin
Suppose all "blink-matching..." variables at their standard settings.
When I now insert a closing paren in the current buffer and (a) the
matching paren is before `window-start' and (b) the `buffer-substring'
to be displayed by `blink-matching-open' contains at least one bold
character, the follow
Eli Zaretskii wrote:
This is what happens when people send incomplete diffs, and one is
forced to apply them by hand.
Sorry. I'll try to make this never happen again. martin
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gn
I finally checked in a fix for this, but I didn't feel I could add any
asserts that I was sure about, sorry.
Jan D.
Works fine. Thanks a lot for resolving this problem. martin
___
Emacs-devel mailing list
Emacs-devel@gnu.org
Richard Stallman wrote:
> believe that I found a solution that does the right thing in most cases
> and will send it to you in the next days.
>
> Could you dscribe in words what it does?
Attached find a file called `lisp-font-lock-regexp.el' which contains
all changes I propose. You may
> I fixed shy group handling in this regexp by allowing ?: to be only
> before `(' instead of before any of `(', `|' or `)'. You may need to
> adjust your code before submitting your final patch.
If you intend "after" instead of "before" here I have done that already.
> Also I tried to extend t
> Note that I only fixed the endless looping behavior here. My code is
> not suitable when you use a support mode like jit-lock and change the
> delimiters of regexp groups.
>
> I don't understand that last sentence. What does it mean to "change
> the delimiters of regexp groups"? C
> Moreover I don't think that anything is "broken" in the following:
>
>;; Underline innermost grouping, so that you can more easily see what
>;; belongs together. 2005-05-12: Font-lock can go into an
>;; unbreakable endless loop on this -- something's broken.
>
The recent modification of `lisp-font-lock-keywords-2' to highlight
subexpressions of regexps has two minor bugs:
(1) If you attempt to write the regexp to match the string "\\)" as
")" the last three chars of that regexp are highlighted with
`font-lock-comment-face'.
(2) If the
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
>
Eli Zaretskii wrote:
Why ``fix'' that which isn't broken? Emacs still supports platforms
that are much older than Windows 9x, so I certainly don't see any
reasons for such a crusade against W9x build capabilities, nor any
reason to assume that no one builds Emacs on those old versions of
Window
In `lisp-font-lock-syntactic-face-function' the expression
(eq n (or (get sym 'doc-string-elt) 3))
causes to paint _every_ third string subexpression of a top-level
expression with `font-lock-doc-face'. That's annoying in a number of
cases like, for example, `define-abbrev'. Why not simplify this
Is there any reason why `Buffer-menu-buffer-face' is customized in the
`font-lock-highlighting-faces' group? The current choice (i) breaks the
convention that all faces in this group are prefixed with "font-lock-"
and (ii) falsely implies that this face is used by font-lock. Since
the face is use
Nick Roberts <[EMAIL PROTECTED]> wrote:
> Within Emacs CVS, I think both cc-mode.el and cmacexp.el are part of
> Emacs.
Maybe so, but it's more relevant to note what the respective
maintainers are inclined to support. If the CC Mode maintainers aren't
prepared to support a certain feature then it
The recently introduced `cc-create-define-alist' causes the following
problem with Emacs on MinGW: When I load a C program into a buffer the
process "/lib/cpp" gets called. However, with MinGW "cpp.exe" is by
default in "...\MinGW\bin\" and an error is reported.
__
Hi David, hi Yamamoto,
thanks for your advice. Deleting lisp/*.elc solved my problem.
Best regards
Martin
--
Garbage In -- Gospel Out.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
nction definition is void: mac-paste-function
Any ideas?
Martin
--
... I'm IMAGINING a sensuous GIRAFFE, CAVORTING in the BACK ROOM of a
KOSHER DELI!!
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
(please cc me replies, I am not subscribed to emacs-devel)
Hi,
Just to let you know about a problem that has been reported to Debian and
that seems caused by a undesired interaction between ispell.el and
aspell-0.60 when the environment (really LC_CYPE) is utf8,
http://bugs.debian.org/299725
In
Stefan Monnier <[EMAIL PROTECTED]> wrote:
>> That doesn't work very well while the thing is entered, does it? First
>> you see "s[foo]{" while it's being entered, then you see the next line
>> " bar", and lastly "}x". Your patterns will never see the whole
>> construct at once. (They will however
Stefan Monnier <[EMAIL PROTECTED]> wrote:
> When I added the jit-lock-defer-multiline property (mostly for perl-mode),
> I first considered adding a hook somewhat like Alan's but it turns out that
> it's pretty damn difficult to write this hook:
Indeed it is.
> The problem is: how to get font-lo
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
On 17 feb 2005, at 10.43, Kim F. Storm wrote:
Martin Fredriksson <[EMAIL PROTECTED]> writes:
I have now verified the abort also in Linux. The abort happens when
invoking outline-minor-mode 'show-all' after a previous 'hide-body',
when part of the buffer is not visible (
I have now verified the abort also in Linux. The abort happens when
invoking outline-minor-mode 'show-all' after a previous 'hide-body',
when part of the buffer is not visible (scrolled). The abort only
happens when using keys, not when invoking with 'M-x show-all'.
The steps to trigger this
On 14 feb 2005, at 10.51, Sébastien Kirche wrote:
Maybe it's a bit late, but for Carbon Emacs, you can get some infos
about a
crash (threads, call stack, etc...) with "Console" app.
Yes, that's a good tip. The problem here was that Emacs didn't crash
in the way that it produced a crash log (no
On 12 feb 2005, at 17.04, Kim F. Storm wrote:
Unfortunately, I cannot reproduce the crash following your procedure.
That's understandable, as my description was flawed. Sorry. I try
again.
(1) gdb ./emacs
(gdb) run -q
(2) Open apa.txt, select outline minor mode (M-x outline-minor-mode)
and
Hi again Kim,
Don't know if my gdb output was useful or if you already found the
problem, but here is some more info.
I can now reproduce the crash. Perhaps not the simplest way, but
following does it.
(1) Start emacs without any init file and with set geometry (to make
sure my example works)
On 11 feb 2005, at 14.47, David Kastrup wrote:
You could try looking into the etc/DEBUG file.
Of course. And another "of course" is gdb. Don't know why I wasn't
thinking
I seem to be able to trigger is by doing outline operations. When it
happened I used AUCTeX and LaTeX source. The backt
I just experienced a couple of crashes in Emacs carbon (current build).
Just died, no message, nothing. Yes, yes, I know this is a stupid
thing to say to you all; I'm just setting the stage for following even
lamer question:
Is there a quick way to read up on how to get Emacs (particularly
C
On 11 feb 2005, at 05.20, Stefan Monnier wrote:
In configure.in, for powerpc-apple-darwin, I believe that "using fink
packages if available" should be removed. There is no use for that
(as far
as I know?) since the needed packages (I think it's only ncurses) are
part
of the normal development en
GCC_TEST_OPTIONS="-I/sw/include -L/sw/lib"
-CPP="${CPP} ${GCC_TEST_OPTIONS}"
- NON_GCC_TEST_OPTIONS=${GCC_TEST_OPTIONS}
-fi
;;
## AMD x86-64 Linux-based GNU system
Note the question mark in the subject. Anyone think this should be
kept ther
57 matches
Mail list logo
