$ emacs -nbc -Q &
S-Mouse-1 pops up a menu from which a new font can be selected.
Customize the "default" face, make a simple change, for example,
change the foreground color to blue, and set for current session.
Now S-Mouse-1 pops up the font menu, but selecting a font doesn't have
any effect.
The following patch should assert that FROM is "correct" when
`after-change-functions' is called (without any warranty).
*** insdel.cSat Nov 5 20:46:36 2005
--- insdel.cSat Dec 17 18:22:00 2005
***
*** 749,757
{
if (nbytes > 0)
{
! int opoint = PT;
!
>
> I suppose this happens because signal_after_change
> is called with arguments `opoint' and `PT - opoint' where opoint = 1090
> and PT = 1090 + 52 + 1.
>
> Can you find the line number of the call to signal_after_change?
> We need to determine why its argument FROM is incorrect.
The problem is that the FROM value of `widget-after-change' now points
into the foreground overlay and the TO value into the background
overlay.
Right. So...where does the FROM value come from
before it gets to widget-after-change?
I suppose this happens because signal_after_ch
> :notify will now change the text following the State button from "SAVED
> and set." to "EDITED, shown value does not take effect until you set or
> save it." The first of these strings is 14 characters long, the second
> 66. The difference of their length is 52.
>
> I see.
>
>
:notify will now change the text following the State button from "SAVED
and set." to "EDITED, shown value does not take effect until you set or
save it." The first of these strings is 14 characters long, the second
66. The difference of their length is 52.
I see.
This edit ought
> `widget-before-change' may modify text preceding the editable field. As
> a consequence FROM and TO values passed to `widget-after-change' get
> messed up.
>
> I don't entirely understand the reasoning. Why can
> `widget-before-change' modify that text? Is this solely because of
>
`widget-before-change' may modify text preceding the editable field. As
a consequence FROM and TO values passed to `widget-after-change' get
messed up.
I don't entirely understand the reasoning. Why can
`widget-before-change' modify that text? Is this solely because of
doing :notify
The bug seems related to the following change from 1997-06-20:
(widget-after-change): Don't apply :notify here.
(widget-before-change): New function. Apply :notify here.
`widget-before-change' may modify text preceding the editable field. As
a consequence FROM and TO values pas
olor) (min-colors 88) (background light))
(:background "magenta" :foreground "lightskyblue1")
and I do
M-x customize-face RET isearch RET
and try to reinsert "3" after "magenta" I get
Debugger entered--Lisp error: (error "Change in
When attempting to customize the face at point (M-x customize-face), I
get the error
read-face-name: Symbol's function definition is void: complete-in-turn
This behavior seems to be stable across buffers, modes, and faces.
In GNU Emacs 22.0.50.20 (powerpc-apple-darwin7.9.0, X toolkit,
* Ralf Angeli (2005-04-06) writes:
> I just compared this functionality in CVS Emacs with Emacs 21. In
> Emacs 21 it is easier to select a face because there is this "Select
> Face" button which presents you with a minibuffer prompt including
> auto-completion of face names. Additionally you can
* David PONCE (2005-04-05) writes:
>> It looks clean to me. I have never understood widgets very well,
>> so I don't know whether it is correct. But if it seems to work
>> better than the present code, it must be a step forward.
>>
>> I wish someone here had enough expertise to be able to
>> as
Hi,
> It looks clean to me. I have never understood widgets very well,
> so I don't know whether it is correct. But if it seems to work
> better than the present code, it must be a step forward.
>
> I wish someone here had enough expertise to be able to
> assure us it is correct--but I think no
It looks clean to me. I have never understood widgets very well,
so I don't know whether it is correct. But if it seems to work
better than the present code, it must be a step forward.
I wish someone here had enough expertise to be able to
assure us it is correct--but I think nobody does.
So wo
Hello,
> It works well excepted that sometimes, when doing M-TAB completion, I
> encounter this bug:
>
> Debugger entered--Lisp error: (args-out-of-range 1094 1094)
> get-char-property(1094 field #)
> widget-field-end(...)
> widget-field-find(1229)
> widget-before-change(1229 1234)
> li
I am not sure it is due to my change nor have any idea on what could
cause it. Maybe a guru of the custom/widget internals could help?
I hope we have one. I don't know any more about this code than you
do; probably less, since I have had more time to forget.
The experience of Custom has
[CC'd this msg again to the devel ML for help]
Hello,
> I made the following patch which seems to work better. WDYT?
>
> You changed the code quite a bit, so I can't quickly see what the
> user-level behavior is. Would you please describe what has changed
> at that level?
I redid the patch
Oops! here is the correct change log. Sorry!
2005-04-01 David Ponce <[EMAIL PROTECTED]>
* cus-edit.el (face): Derive from symbol widget. Display sample
of the current face on the fly.
(widget-face-sample-face-get, widget-face-notify): New functions.
(widget-face
I made the following patch which seems to work better. WDYT?
You changed the code quite a bit, so I can't quickly see what the
user-level behavior is. Would you please describe what has changed at
that level?
___
Emacs-pretest-bug mailing list
Em
Hi,
Here is a new simpler patch which works well most of the time.
However in some case, when doing M-TAB to complete the face field, I
got this error:
Debugger entered--Lisp error: (args-out-of-range 1094 1094)
get-char-property(1094 field #)
widget-field-end(...)
widget-field-find(1229)
>>In latest CVS Emacs the "Inherit" face attribute appears as a
>>"Function" widget in the `customize-face' buffer.
>>
>>In Emacs 21.3 it appears as expected, that is a "Face" widget allowing
>>to customize the inherited face
[Limiting list of recipients to emacs-pretest-bugs.]
* David Ponce (2005-03-27) writes:
> In latest CVS Emacs the "Inherit" face attribute appears as a
> "Function" widget in the `customize-face' buffer.
>
> In Emacs 21.3 it appears as expected, that is a
Hi,
In latest CVS Emacs the "Inherit" face attribute appears as a
"Function" widget in the `customize-face' buffer.
In Emacs 21.3 it appears as expected, that is a "Face" widget allowing
to customize the inherited face.
Also when adding a new inherited face
The apropos-* faces are not in the buffer. The default for
customize-face is supposed to customize all faces.
These are not faces, they are variables whose values are faces.
That way of doing things is old and somewhat obsolete.
Perhaps we should replace those variables with faces
1. load-library apropos
2. customize-face RET
The apropos-* faces are not in the buffer. The default for
customize-face is supposed to customize all faces.
However, if you do `customize-apropos aprop', then they are shown in the
customize buffer.
In GNU Emacs 21.3.50.1 (i386-mingw-nt5.1
26 matches
Mail list logo
