Re: [Success] XEmacs 21.5-b27 "fiddleheads" (+CVS-20061025) i686-pc-linux
18 years
Nix
On 28 Oct 2006, BlueSky said:
> remove me from this mailing list. thanks
At the bottom of *every single message* to the mailing list is the text
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Click on that link, and you'll find an unsubscribe link.
(Hm. Perhaps that message should mention unsubscription somewhere? We
have List-Unsubscribe: headers *and* a footer and *still* people exist
who don't understand how to unsubscribe. How those people managed to
cope with XEmacs at all is somewhat beyond me...)
--
`When we are born we have plenty of Hydrogen but as we age our
Hydrogen pool becomes depleted.'
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: [mule] xemacs doesn't recognize some symbols
18 years, 1 month
Aidan Kehoe
Ar an seachtú lá is fiche de mí Deireadh Fómhair, scríobh Andriy Gapon:
> > Yup, because you don’t have any fonts on your system to handle that
> > encoding (the XLFD needs to end with cns11643-1). I have most of a
> > solution to that problem on my hard disk--if the font isn’t available,
> > it tries the Unicode encoding instead--but it needs some more testing
> > and debugging.
>
> I understand your description, but don't understand the origin of the
> problem :-) Did those dashes originally appear in chinese charsets ?
Probably not; adobe-standard had them long before CNS 11643 was published,
for example.
> Don't some iso8859 charsets have them ?
No. In non-East-Asian practice yes, since the Microsoft extensions of the
ISO character sets included them between 0x80 and 0xA0. This range is
defined by the ISO as control characters, and used in East Asia (and in
Emacs internationalisation, since the bulk of the design was done in Japan)
as such.
> I have my own layouts for Ukrainian and Russian, regular layouts have
> poorer repertoire of symbols and do not employ AltGr.
> On the other hand, I've just set the standard ua layout and tried to
> enter small and capital GHE WITH UPTURN, which is bound to backlash/pipe
> key, and I got exactly them, backslash and pipe. At the same time xterm
> input was just fine.
> So Mode_switch was probably my over-imagination, it seems that XEmacs
> falls back either to us layout or some built-in layout.
(If it’s falling back, it’s to the US layout, yes.)
> Maybe I have some problem with my config, here's what I have
> (input/unicode related only):
>
> ;;unicode support in xemacs-mule
> (setq mucs-ignore-version-incompatibilities t) ; xemacs 21.5 with mule
> (require 'un-define)
Mule-UCS isn’t necessary and doesn’t work on 21.5; if you have recent
versions of the packages, that line should give you an error message. Try
(unless (>= 5 emacs-minor-version)
(require 'un-define))
> (set-default-output-coding-systems 'utf-8)
> (set-coding-priority-list '(utf-8))
> (set-coding-category-system 'utf-8 'utf-8)
The rest of your lines seem reasonable.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: [mule] xemacs doesn't recognize some symbols
18 years, 1 month
Aidan Kehoe
Ar an seachtú lá is fiche de mí Deireadh Fómhair, scríobh Andriy Gapon:
> Guys, thank you for your enlightening explanation!
>
> I decided to give a try to xemacs-21.5.27.
> Overall I have more success, but I've encountered somewhat different
> problems.
>
> First and the least important:
> (key-mapping/info) Undefined Unicode key mappings.
> Your keyboard has, among many others, the following keysyms defined:
>
> U20B4 U0301
> ...
> The first symbol is HRYVNIA SIGN (₴), a symbol for Ukrainian currency,
> this is a very very recent addition to Unicode so I don't complain much.
> The second one is COMBINING ACUTE ACCENT that I use as a stress sign for
> cyrillic (e.g. вимовля́ння).
Those should disappear if you use more recent sources, dating since after
this patch was committed:
http://mid.gmane.org/17522.5887.730211.185772＠parhasard.net
> Then, there is a different problem with EM DASH and EN DASH now: they
> seem to get entered, but a tilde is displayed instead of them and the
> following warning is produced:
> (font/notice) Unable to instantiate font for charset chinese-cns11643-1,
> face default
Yup, because you don’t have any fonts on your system to handle that encoding
(the XLFD needs to end with cns11643-1). I have most of a solution to that
problem on my hard disk--if the font isn’t available, it tries the Unicode
encoding instead--but it needs some more testing and debugging.
> I use Terminus monospace font with unicode encoding and it definitely
> has these symbols. This is definitely not an input problem because
> copy/paste has the same result.
>
> Then, I still can not enter CYRILLIC CAPITAL/SMALL LETTER GHE WITH
> UPTURN, but there is no special warning now, maybe because of the following.
>
> Unusual thing with input is that when, e.g., I press AltGr+г to get "ґ",
> I instead get "u" (ascii latin small letter). By "AltGr" I mean
> ISO_Level3_Shift in X. Analogous thing happens for any other AltGr
> combination that results in a "problematic" symbol — AltGr is treated as
> if it was "Mode_switch".
> Now that I wrote it, I realize that most probably this is not a problem
> with XEmacs but rather a feature that is triggered by my hackery of XKB:
> $ xmodmap -pm | fgrep ISO_Level3_Shift
> mod5 Mode_switch (0x5d), ISO_Level3_Shift (0x75),
> ISO_Level3_Shift (0x7c)
> So, maybe XEmacs falls back to Mode_switch interpretation of Mod5 if it
> thinks that ISO_Level3_Shift is no good ? And by "no good" I mean that a
> key has 3rd/4th level and symbols on that level are not NULL(0), but
> they are not valid input for XEmacs.
> I must say that I haven't seen such a behavior from any other program.
> And I don't really have any key bound to Mode_switch (93 is a fake key
> code, it is never produced by a xfree86 keyboard driver).
Can I enable the key layout you’re using with
setxkbmap ua
? If so, I will try to investigate further this evening. I am seeing
unexpected behaviour with GHE WITH UPTURN on this Windows machine’s Cygwin
install, but it’s different to what you’re seeing.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: Mule bugs: misidentification (Latin-1 vs. Chinese), revert issues
18 years, 1 month
Aidan Kehoe
Ar an seachtú lá is fiche de mí Deireadh Fómhair, scríobh Michael Sperber:
> > > > > I open a file with UTF-8 coding-system. I touch that file
> > > > > outside of XEmacs and then do M-x revert-buffer RET. The
> > > > > non-ASCII characters get mangled.
> > > >
> > > > There’s a comment from Ben in the sources about this problem:
> > >
> > > What does Ben's comment have to do with coding systems, other than
> > > that they reduce the utility of replace-mode to zero?
> >
> > The comment doesn’t mention the replacement algorithm not being
> > followed for any content whatsoever; I find it misleading. But you’re
> > right, and Michael’s problem is a separate issue--this code isn’t even
> > buggy, despite what I thought.
> >
> > Mike, I can’t reproduce your problem locally, but does this patch eliminate
> > it for you?
> >
> > --- lisp/files.el~ 2005-11-18 12:12:07.000000000 +0100
> > +++ lisp/files.el 2006-10-24 20:48:22.000000000 +0200
> > [...]
>
> Yes, it does. Thanks! Will you commit this change?
Yes--I’ll get to it this evening, and update Ben’s comment at the same time.
> >
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
[mule] xemacs doesn't recognize some symbols
18 years, 1 month
Andriy Gapon
I am running xemacs-mule (21.4.19) in uk_UA.UTF-8 locale and I try to
enter some multi-lingual text using AltGr and Compose key. For some
symbols this works very well, but for others not.
E.g. I can enter symbols like
«»€
and many cyrillic symbols like
гфіїєэ.
On the other hand I can not enter some other quite basic symbols, xemacs
messages follow:
leftdoublequotemark not defined.
rightdoublequotemark not defined.
endash not defined.
Sh-emdash not defined.
Ukrainian_ghe_with_upturn not defined.
Macedonia_gje not defined.
Where do these messages come from and what do they mean ?
Is this something wrong with the font I use ?
On the other hand, if open a document that already contains the
troublesome symbols they are rendered as they should be. It seems that
the problem is with input.
P.S. the input was done after C-x Ret f and selecting utf-8, default
input method is used.
--
Andriy Gapon
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Bug report...
18 years, 1 month
Greg Montgomery
Hi
Emacs crashed and left instruction to follow. Doing what the instructions
said led to the text with follows.
Greg Montgomery
Astronautics.com
make-local-variable scrambles default value [lookup-syntax-properties garbled]
18 years, 1 month
Ilya N. Golubev
xemacs branch: 21.4.
The code below does use `save-excursion' within `let' as adviced in
<(elisp) Intro to Buffer-Local>. Still the assignment that one
expects to be temporary permanently breaks default
`parse-sexp-lookup-properties' value, and in a way that is hard to
detect. It does not manifest right after the assignment, only after
`make-local-variable' is called. That is, the following code
;; sdv.el
;; visit `0.sh' in `sh-mode'
(set-buffer (get-buffer-create "0.sh"))
(set (make-local-variable 'parse-sexp-lookup-properties) t)
(print (default-value 'parse-sexp-lookup-properties))
;; visit `0.c' in `c-mode'
(set-buffer (get-buffer-create "0.c"))
(print parse-sexp-lookup-properties)
;; evaluate initial `c-emacs-features' value in `cc-defs.el'
(let ((buf (generate-new-buffer " test"))
parse-sexp-lookup-properties)
(save-excursion
(set-buffer buf)
(setq parse-sexp-lookup-properties t))
(kill-buffer buf))
(print parse-sexp-lookup-properties)
(print (default-value 'parse-sexp-lookup-properties))
(make-local-variable 'parse-sexp-lookup-properties)
(print parse-sexp-lookup-properties)
(print (default-value 'parse-sexp-lookup-properties))
when evaluated like this
xemacs -batch -q -l sdv.el
prints:
nil
nil
nil
nil
t
t
Emacs 21.4a invoked the same way prints exactly what one expects.
nil
nil
nil
nil
nil
nil
The call sequence is by no means artificial. It actually occurs in
interactive session like this.
. Visit file in `sh-mode'.
. Visit other file in `cc-mode'.
. . Load `cc-mode' code, which also loads `cc-defs' with its
`c-emacs-features' initial value evaluation.
. The `parse-sexp-lookup-properties' / `lookup-syntax-properties'
default value is now incorrectly set to `t', which triggers other bug
of `update_syntax_cache' <- `string-match'. (Will post
`update_syntax_cache' patch on request.)
The elisp primitive is fairly generic, so the bug affects potentially
unlimited number of packages. In particular, `gnus' depends on
`lookup-syntax-properties' to be `nil' for `string-match' <-
`gnus-extract-address-components' to work around this bug. This call
sequence occurs inside `gnus-group-select-group' interactive command.
Not every `cc-mode' version works this way, but one that does is
current in xemacs packages cvs. Will post patch for it on request.
And this patch would be unnecessary for emacs - or if xemacs behaved
the same way as emacs wrt `parse-sexp-lookup-properties'.
The `update_syntax_cache' bug was introduced in 21.4 branch (in
`syntax.c' revision 1.7.2.18 of 2001/02/09 16:00:37 +0). So 21.5 is
not affected by it, even though in it initial value of
`parse-sexp-lookup-properties' / `lookup-syntax-properties' is `t'.
However, when `t' values in the code abover reversed to `nil', the
code above still shows the same undesired and unexpected change of
default value.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
related to an XEmacs BTS
18 years, 1 month
Stephen J. Turnbull
There's discussion about a BTS for GNU Emacs going on on
emacs-devel(a)gnu.org (ifyou're not subscribed, I think you can access
the archives from Savannah?).
For perspective on my "blockading" tactics (black humor, nobody said
that, but I have to acknowledge a certain amount of truth in it), see
RMS's hardline. Also, my position is not so different from Miles
Bader's. Maybe he says it better than I can. :-)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: Mule bugs: misidentification (Latin-1 vs. Chinese), revert issues
18 years, 1 month
Aidan Kehoe
Ar an ceathrú lá is fiche de mí Deireadh Fómhair, scríobh stephen(a)xemacs.org:
> Aidan Kehoe writes:
>
> > > I open a file with UTF-8 coding-system. I touch that file outside of
> > > XEmacs and then do M-x revert-buffer RET. The non-ASCII characters
> > > get mangled.
> >
> > There’s a comment from Ben in the sources about this problem:
>
> What does Ben's comment have to do with coding systems, other than
> that they reduce the utility of replace-mode to zero?
The comment doesn’t mention the replacement algorithm not being followed for
any content whatsoever; I find it misleading. But you’re right, and
Michael’s problem is a separate issue--this code isn’t even buggy, despite
what I thought.
Mike, I can’t reproduce your problem locally, but does this patch eliminate
it for you?
--- lisp/files.el~ 2005-11-18 12:12:07.000000000 +0100
+++ lisp/files.el 2006-10-24 20:48:22.000000000 +0200
＠＠ -3521,7 +3521,10 ＠＠
after-change-function
after-change-functions
before-change-function
- before-change-functions)
+ before-change-functions
+ ;; #### b-f-c-s is _not necessarily_ the coding system that
+ ;; was used to read in the file. See its docstring.
+ (coding-system-for-read buffer-file-coding-system))
(if revert-buffer-insert-file-contents-function
(funcall revert-buffer-insert-file-contents-function
file-name nil)
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
