2005/7/3, martin rudalics <[EMAIL PROTECTED]>:
> 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
BTW, I think it's not unreasonable to ask people to re-send
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.gnu.org/mai
> From: Juri Linkov <[EMAIL PROTECTED]>
> Date: Sun, 03 Jul 2005 03:09:08 +0300
> Cc: martin rudalics <[EMAIL PROTECTED]>
>
> What were the reasons for making long face names much longer?
>
> After renaming `font-lock-regexp-backslash-construct' it became
> absurdly long: `font-lock-regexp-backsl
Juri Linkov wrote:
I think the face names proposed by Martin in his latest patch
are much better: `font-lock-regexp-backslash' and
`font-lock-regexp-group'. These face name have sensible lengths
and are still descriptive enough.
I agree.
Sincerely,
Luc.
__
What were the reasons for making long face names much longer?
After renaming `font-lock-regexp-backslash-construct' it became
absurdly long: `font-lock-regexp-backslash-grouping-construct'.
The face name is not the place for full description of the face.
There are docstrings for that purpose. Bu
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 could avoid painting regexp groups that span multiple lines, but this
would deprive me from highlighting many interesting things. I could set
`font-lock-lines-before' to a higher value but this would slow down
fontification in general and still not handle all cases.
The current
> I can't help wondering what would be the benefit of highlighting
> things like \< and \w. Highlighting \( and \| and \) can make sense
> since it helps doing visual paren matching
\< and \w are keywords of the language of regular expressions.
Like keywords of other programming languages highlig
>> I tried to implement variants of that but it did not turn out well.
>> Highlighting backslashes only is more distracting than useful. Having
>> `<' or `w' stand out with bold face makes groupings much less readable.
> A different face could be used for `<', `w' and other constructs.
I can't he
> I tried to implement variants of that but it did not turn out well.
> Highlighting backslashes only is more distracting than useful. Having
> `<' or `w' stand out with bold face makes groupings much less readable.
A different face could be used for `<', `w' and other constructs.
--
Juri Linko
> 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 removed the "\\(\\?:\\)?" since I find it distracting to
> put yet another face here. If you believe that you _really_ need it
> you will have to reinsert it, but in that case you have to modify
> match-data cropping as well. (I do have to modify match-data since
> redisplay wants s
> 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
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"? Could you ple
> 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.
>
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.
martin rudalics <[EMAIL PROTECTED]> writes:
> The recent modification of `lisp-font-lock-keywords-2' to highlight
> subexpressions of regexps has two minor bugs:
[...]
> Finally, I would use three distinct font-lock faces for regexps:
FWIW, I wholeheartedly agree.
> - One face for highlighti
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
18 matches
Mail list logo
