headers
Stefan Monnier | 1 May 2006 02:48
Picon

Re: Getting the click position in a string

> It would not really suffice to let it accept an event instead of KEY:
> for implementing the follow-link functionality, the lookup has to be
> for [follow-link], but for a given event of type down-mouse-1 or
> similar.

Oh, now I understand what you mean.  So you basically want to add
a `position' argument to `key-binding'?  How 'bout adding a `position'
argument to `current-active-maps'?

        Stefan
Permalink | Reply | 2 comments |
headers
YAMAMOTO Mitsuharu | 1 May 2006 03:34
Picon

Re: ATSUI support on Carbon Emacs

>>>>> On Wed, 26 Apr 2006 18:13:13 +0900, YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp> said:

> Because there's no objection about the patch in
> http://lists.gnu.org/archive/html/emacs-devel/2006-04/msg00901.html
> so far, I'm going to enable ATSUI support at last.  Here's my plan:

Done, but with a few modifications as below.

>   * Enable ATSUI support in Mac OS X 10.2+ by default. 
>     It is really slow on Mac OS X 10.1.

What's slow was not ATSUI but Quartz 2D rendering.  So I enabled the
former but not the latter on Mac OS X 10.1.

>   * Maybe reconsider the name `mac-allow-anti-aliasing'.

Didn't change.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp
Permalink | Reply | 0 comments |
headers
Miles Bader | 1 May 2006 03:44
Picon
Gravatar

Re: [PATCH] Unicode Lisp reader escapes

Aidan Kehoe <kehoea <at> parhasard.net> writes:
> I find _that_ distinctly ugly, but more of a problem with it than the
> aesthetics is that it’s unfamiliar to everyone, Lisp people and Java people
> alike.

How about supporting  both the "standard" syntax ("\u0123")
and a flexible-length syntax like "\u{123}" (I seem to recall this
a syntax like this being discussed on this list)?

-Miles
--

-- 
Freedom's just another word, for nothing left to lose   --Janis Joplin
Permalink | Reply | 3 comments |
headers
Kenichi Handa | 1 May 2006 04:41

Re: Default face problem [was: Re: incomplete header-line with 3d boxes and prop fonts]

In article <m3aca6lyrz.fsf_-_ <at> kfs-l.imdomain.dk>, storm <at> cua.dk (Kim F. Storm) writes:

> storm <at> cua.dk (Kim F. Storm) writes:
>> Sascha Wilde <wilde <at> sha-bang.de> writes:
>> 
>>>>> I still do see a heavy misalignment of the header line in ses (with
>>>>> X11), but only when using a font with an odd size
>>>>> (-*-terminus-medium-r-*-*-17-*-*-*-*-*-iso8859-1 here).
>> 
>> I see it too.
>> 
>> If I customize the default face, and change the height from 99 to 100,
>> it works again.  I'll look into what's wrong.

This is because the current Emacs refuses to use an
auto-scaled font because it's usually too agree to use for
the editing work.  It at first checks the availability of
the specified font (without checking it's auto-scaled or
not), but, later on deciding a font for a face, it lists
fonts matching with family-name and registry-name, then
selects the best one among them.  On this selection,
auto-scaled font is refused even if scalable-fonts-allowed
is non-nil.  So, in your case the 16-dots font (that is
surely included in terminus font package) is selected.

---
Kenichi Handa
handa <at> m17n.org
Permalink | Reply | 25 comments |
headers
Stefan Monnier | 1 May 2006 05:12
Picon

Re: [PATCH] Unicode Lisp reader escapes

>> I find _that_ distinctly ugly, but more of a problem with it than the
>> aesthetics is that it’s unfamiliar to everyone, Lisp people and Java people
>> alike.

> How about supporting  both the "standard" syntax ("\u0123")
> and a flexible-length syntax like "\u{123}" (I seem to recall this
> a syntax like this being discussed on this list)?

Currently The syntax for \xNNNN hexadeciaml escapes is that it ends whenever
reaching a non-hexadecimal char, and if you need your \xNNN escape to be
followed by an hexidecimal char, then you have to seprate the two with "\ "
(and the Lisp printer does that automatically, of course).
Is there a strong reason not do use the same rule for \u ?

        Stefan
Permalink | Reply | 2 comments |
headers
Stefan Monnier | 1 May 2006 05:14
Picon

Re: Default face problem

> On this selection, auto-scaled font is refused even if
> scalable-fonts-allowed is non-nil.

For what it's worth, "scalable-fonts-allowed" refers to vector-fonts (which
are inherently scalable).  Whereas you're talking about scaling
a bitmap font.

        Stefan
Permalink | Reply | 5 comments |
headers
Miles Bader | 1 May 2006 05:41
Picon
Gravatar

Re: [PATCH] Unicode Lisp reader escapes

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> Currently The syntax for \xNNNN hexadeciaml escapes is that it ends whenever
> reaching a non-hexadecimal char, and if you need your \xNNN escape to be
> followed by an hexidecimal char, then you have to seprate the two with "\ "
> (and the Lisp printer does that automatically, of course).
> Is there a strong reason not do use the same rule for \u ?

That might be sufficient for programmatic output, but anything involving
a significant space seems problematic in general...

-Miles
--

-- 
x
y
Z!
Permalink | Reply | 1 comment |
headers
Richard Stallman | 1 May 2006 06:19
Picon
Picon

Re: emacs doc changes

    The author was Aaron S. Hawley <Aaron.Hawley <at> uvm.edu>; the thred started
    in emacs-devel with the following post:

       http://lists.gnu.org/archive/html/emacs-devel/2006-03/msg00358.html

Did that thread come up with some text that we could use?
If so, could you send it to me?
Permalink | Reply | 3 comments |
headers
Richard Stallman | 1 May 2006 06:19
Picon
Picon

Re: tool-bar-setup overwrites local tool-bar-map

    If one runs tool-bar-mode first, and then MH-E, one sees the one pair of
    Preferences/Help buttons (the ones defined by MH-E). If vice-versa, one
    sees *two* pairs of Preferences/Help buttons (the ones defined by MH-E
    plus the ones defined by tool-bar).

Now I understand the point of your patch.
But it seems to me that ALL the standard tool-bar items
ought to be added to the standard tool-bar map.
Not just Help and Preferences.

Ah, now I see.  All the rest are added using
tool-bar-add-item-from-menu, which uses (default-value 'tool-bar-map).

So I believe your patch is correct.  But I think this is cleaner.
Does it work?

*** tool-bar.el	07 Feb 2006 18:16:16 -0500	1.5
--- tool-bar.el	30 Apr 2006 23:58:17 -0400	
***************
*** 267,280 ****
    ;;(tool-bar-add-item-from-menu 'compose-mail "mail/compose")

    (tool-bar-add-item-from-menu 'print-buffer "print")
-   (tool-bar-add-item "preferences" 'customize 'customize
- 		     :help "Edit preferences (customize)")

!   (tool-bar-add-item "help" (lambda ()
! 			      (interactive)
! 			      (popup-menu menu-bar-help-menu))
! 		     'help
(Continue reading)

Permalink | Reply | 1 comment |
headers
Richard Stallman | 1 May 2006 06:20
Picon
Picon

Re: Problem report #

    > Event const: After this line, the value of "type_seen" is equal to 1
    > Event assignment: Assigning "1" to "type_seen"
    > Also see events: [dead_error_line][dead_error_condition][assignment]

    Uhm, as far as I can tell, type_seen may very well be 0 after this.
    There are several cases where the code won't goto the typeseen label.

I agree.  I think the report is a confusion.
Dan, please mark this as not a real bug.
Permalink | Reply | 0 comments |

Gmane