Handling of `i' is broken in the current CVS state. For example,
trying to isearch for `i' in etc/HELLO (`C-h h C-s i C-s ...') reveals
several problems:
1. isearch finds `i' on characters from non-Latin scripts, which have
nothing in common with `i'.
2. not all `i' characters are highlighted
Then I'm confused. As Juri said (and it works):
`unspecified' does just what it says, i.e. leaves the default frame
value untouched. If you want to change the default for new frames,
you can set the value of this attribute to nil. So this should work
just
Then I'm confused. As Juri said (and it works):
`unspecified' does just what it says, i.e. leaves the default frame
value untouched. If you want to change the default for new frames,
you can set the value of this attribute to nil. So this should work
just fine
This seems to be a bug in internal-set-lisp-face-attribute that is
specific to the :inherit attribute. When I try your recipe with other
attributes, like :foreground or :slant, everything works as expected.
(A good face to try this is `fringe': when it changes, you
> On Thu, 13 Oct 2005 23:22:58 +0100, David Reitter <[EMAIL PROTECTED]>
> said:
> Copying a region with a number to the clipboard means that some
> additional characters seem to be copied.
That's BOM (Byte Order Mark) for UTF-16. Could you try the following
patch?
In article <[EMAIL PROTECTED]>, Zhang Wei <[EMAIL PROTECTED]> writes:
> In emacs-unicode-2 branch, these files had been removed from
> the lisp/international/ directory:
> utf-8.el
> latin-1.el
> latin-2.el
> latin-3.el
> latin-4.el
> latin-5.el
> latin-8.el
> latin-9.el
> But their names still
In article <[EMAIL PROTECTED]>, Reiner Steib <[EMAIL PROTECTED]> writes:
>> But, as we need non-trivial change to the current code to make that
>> work in general, I think we must wait for Emacs 23.
> If it works correctly for Latin-1 and Latin-9, I'd strongly suggest to
> add it to the trunk.
I have installed fixes to solve the reported problems.
Notice that posn-at-point will now return nil if point is not
visible in the window (also if hscrolled out of view).
"LaserDoodads Info" <[EMAIL PROTECTED]> writes:
> With the cursor in column 10 or greater on any line of text and no horizon
Copying a region with a number to the clipboard means that some
additional characters seem to be copied.
FYI, Aquamacs copies with cua-region-copy (i.e. clipboard-kill-ring-
save).
I could reproduce this bug with standard Carbon Emacs (CVS) by
starting with -q and marking a number. When I th
Another logical value to return would be "". That certainly satisfies the
doc-string requirement that it is "equivalent to FILENAME when used with
that default directory as the default".
I won't object.
___
Emacs-pretest-bug mailing list
Em
On Thu, Oct 13 2005, Boris B. Samorodov wrote:
[ On emacs-pretest. Cc-ing Ding ]
> Symptoms:
>
> I do have a letter with the next Subject:
> -
> Subject:
> =?UTF-8?B?W2lwdC5ydSAjMTYzXSDQkNCy0YLQvtCe0YLQstC10YI6INCc0KHQmjog0KHQ?=
> =?UTF-8?B?nyDRgtC10YHRgg==?=
> -
>
> In command-line mo
Symptoms:
I do have a letter with the next Subject:
-
Subject:
=?UTF-8?B?W2lwdC5ydSAjMTYzXSDQkNCy0YLQvtCe0YLQstC10YI6INCc0KHQmjog0KHQ?=
=?UTF-8?B?nyDRgtC10YHRgg==?=
-
In command-line mode I can do...
$ echo
"W2lwdC5ydSAjMTYzXSDQkNCy0YLQvtCe0YLQstC10YI6INCc0KHQmjog0KHQnyDRgtC10YHRgg==
1. The statement about the behavior of nil and t for
set-face-attribute is apparently not true for attribute
:inherit, but it is true for the other
attributes. The doc for set-face-attribute specifically
mentions support for :inherit, without sayi
In emacs-unicode-2 branch, these files had been removed from
the lisp/international/ directory:
utf-8.el
latin-1.el
latin-2.el
latin-3.el
latin-4.el
latin-5.el
latin-8.el
latin-9.el
But their names still appear in lib-src/makefile.w32-in, when
emacs-unicode-2 branch is compiled on Windows platfor
> When
> foo
> ---
> ba
> is fontified you have two choices: (a) Don't set a multiline property,
> or (b) set a property from `foo' till - in the worst case - the end of
> the buffer. With (a) neither font-lock nor jit-lock will handle this.
> I have not seen an application using (b) yet.
As me
> "martin" == martin rudalics <[EMAIL PROTECTED]> writes:
>> > jit-lock breaks font-lock's handling of syntax-table properties anyway.
>> > Having syntactic properties behave correctly only for positions
>> > preceding `font-lock-syntactically-fontified' means that I can't parse
>> > text afte
On Wed, Oct 12 2005, Kenichi Handa wrote:
> Hmmm, then please try this brute force method.
>
> (1) Apply the attached patch to etc/ps-prin1.ps.
> (2) (setq ps-mark-code-directory nil)
> (3) (setq ps-mule-font-info-database-default
> '((latin-iso8859-1
>(normal nil nil iso-latin-1))
>
> > jit-lock breaks font-lock's handling of syntax-table properties anyway.
> > Having syntactic properties behave correctly only for positions
> > preceding `font-lock-syntactically-fontified' means that I can't parse
> > text after that position reliably with `parse-sexp-lookup-p
>>foo
>>---
>>ba
>
>
>>to
>
>
>>foo
>>---
>>bar
>
>
>>which to my knowledge neither font-lock nor jit-lock can handle.
>
>
> I'm tempted to say "no, that should work just fine". But really, it all
> depends on many more details of how foo and bar relate.
When
foo
---
ba
is fontified you have t
19 matches
Mail list logo
