Need package help
16 years, 1 month
Marcus Harnisch
Hi all
I am sure much of this has been discussed here on this list, but I
still need some help with updating a package. mmm-mode in our packages
is horribly outdated (2001) and I thought it might be a good idea to
integrate the latest (2004 :-) upstream changes.
So far I have integrated all the obvious things, such as new/changed
Lisp, README, texi, etc.
I have also split the ChangeLog into ChangeLog-upstream and
ChangeLog. In the current package upstream changes and XEmacs changes
share the same file which is not such a good idea.
Where I am stuck is the autoconf stuff. MMM has been converted to
autoconf between versions 0.4.7 (in our current package) and 0.4.8.
What about all those files? We have to ship the files for license
reasons, right?
What about generated info files that are part of the upstream package?
I suppose we will regenerate them. Do we still include the
pregenerated files for legal reasons?
Thanks
Marcus
--
note that "property" can also be used as syntaxtic sugar to reference
a property, breaking the clean design of verilog; [...]
(seen on http://www.veripool.com/verilog-mode_news.html)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: yet another XEmacs fork;-)
16 years, 1 month
Stephen J. Turnbull
Julian Bradfield writes:
> Stephen writes:
> >What's wrong with using the approach (and the code) from 21.5 that
> >reads in a charset definition from a Unicode Consortium-format table?
> >These are dumpable AFAIK.
>
> Nothing, and that was my first thought. But then I thought that iconv
> would have the advantage of making it easy to load the translation tables
> on demand - why should I have 20MB (or however much it is) of
> translation tables in main memory of every XEmacs instance, when my
> typical instance only ever sees Latin-1 and maybe few dozen hanzi?
No reason at all. (Just how dumb do you think Ben Wing is, anyway!?
Don't answer that, I know you know better.<wink>) First of all, here
are the numbers from M-x show-memory-usage (I think you need to
compile --with-debug to get that function in 21.5, and it may not be
available in 21.4 at all):
charset from-unicode to-unicode total
total 528448 358440 886888
Yes, those numbers are *bytes*, not "words", "paragraphs", or TiB.
(You're thinking of the Unihan.txt database, no doubt, which is indeed
almost 30MB.) Second, look at how `load-unicode-tables' is
implemented. You'll see that there is no reason why we can't load a
minimal subset and add more on an as-needed basis. Since this is a
once-per-session thing, who cares if it takes 25ms per table?
There currently is no way to request on-demand loading, but I don't
think that would be hard.
> What's the definition of compatibility these days?
"Catering to differences is not too annoying." Differences in basic
Mule functions would be too annoying.
> I haven't used fsfmacs for a decade or more, but my impression is
> that most non-trivial elisp has to cater specially for fsfmacs and
> XEmacs. Is that wrong?
No. For one thing, RMS considers following standards or established
practice for the sake of conforming a form of subordination akin to
slavery, and thus ethically unacceptable in the free software movement.
However, and it's very important, the cores of most applications work
fine in both forks. It's stuff like images that is quite different.
Extents are a little bit annoying but there are several wrapper
packages such as overlay.el in fsf-compat, as well as more specialized
but accurate (within the field of interest) emulations in Gnus and VM
(inter alia). Similarly ez-menu or whatever it's called. Heck, you
know how Kyle feels about GNU and its assignment policy, but he's
always maintained compatibility for VM, including use of the menubar
(he'd basically retired by the time GNU got images and toolbars---
scary thought, isn't it).
Several years ago I was going to write a wrapper package for images,
too, implementing the GNUbie interface, but then I realized that
practically speaking the dox would have to be licensed under the
God-Forsaken Documentation License and I lost all appetite for the
project. (I've grown up a little since then, but that stupid piece of
free-advertising-grubbing hypocrisy *still* rubs me the wrong way.)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
possible bug with `set-glyph-image'
16 years, 1 month
Zajcev Evgeny
Hello there. I tried to change image of the glyph using
`set-glyph-image' and found behaviour that i was not expecting. I
summarized my experiments with a little example:
(setq mg (make-glyph))
(progn
(set-glyph-image mg (xpm-button-create "test" 1 "green" "black"))
(set-extent-end-glyph
(make-extent (point) (point)) mg)
nil) ; (1) form
(progn
(set-glyph-image mg (xpm-button-create "AAA" 1 "red" "black"))
(set-extent-end-glyph
(make-extent (point) (point)) mg)
nil) ; (2) form
I evaluate first form and got nifty looking button as i expected.
Then i evaluated second form in order to get new button and affect
first button to change its image, but instead i got same button as
first one. Is this ok?
I tried it with XEmacs 21.4 (patch 21) and SXEmacs 22.1.10
thanks
--
lg
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: fsf-compat: GNU emacs 22, build in function: read-no-blanks-input
16 years, 1 month
Uwe Brauer
>>>>> "Rodney" == Rodney Sparapani <rsparapa(a)mcw.edu> writes:
> Uwe Brauer wrote:
>>
> Well, I don't know off-hand. But, I suspect aliasing
> it to read-from-minibuffer might get you going.
So I followed boldly your advice and it sort of worked.
I obtained an error message which looks very similar from the attempt
with weblogger, clearly the culprit is
xml-rpc.el (this version works with emacs 22)
Here comes the error
Debugger entered--Lisp error: (error "Selecting deleted or non-existent buffer")
xml-rpc-request-process-buffer(" *URL*")
I do not understand this non-existent buffer message
Here the trace in in full detail
Uwe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
fsf-compat: GNU emacs 22, build in function: read-no-blanks-input
16 years, 1 month
Uwe Brauer
Hello
I tried to get weblogger work with xemacs but failed and it seems that
it is now longer maintained. Just a couple of days ago a new pkg
appeared which works with wordpress (I tested it under GNU emacs 22)
However for Xemacs 21.4.19 (Mule) the problem is a function
read-no-blanks-input
Which according to the GNU Emacs 22 documentation is a built in C
function.
Does anybody have an idea how to implement something similar?
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: possible bug with `set-glyph-image'
16 years, 1 month
Aidan Kehoe
Ar an triú lá déag de mí na Samhain, scríobh Zajcev Evgeny:
> Hello there. I tried to change image of the glyph using
> `set-glyph-image' and found behaviour that i was not expecting. I
> summarized my experiments with a little example:
>
> (setq mg (make-glyph))
> (progn
> (set-glyph-image mg (xpm-button-create "test" 1 "green" "black"))
> (set-extent-end-glyph
> (make-extent (point) (point)) mg)
> nil) ; (1) form
> (progn
> (set-glyph-image mg (xpm-button-create "AAA" 1 "red" "black"))
> (set-extent-end-glyph
> (make-extent (point) (point)) mg)
> nil) ; (2) form
>
> I evaluate first form and got nifty looking button as i expected.
> Then i evaluated second form in order to get new button and affect
> first button to change its image, but instead i got same button as
> first one. Is this ok?
>
> I tried it with XEmacs 21.4 (patch 21) and SXEmacs 22.1.10
>
> thanks
Same behaviour with XEmacs 21.5. The first image is cached; if you delete
the console connection (I normally start my XEmacs within screen from my
system startup scripts, and create gnuclient frames once I start X11)
and create a new connection, both display as the second button.
(set-specifier-dirty-flag (glyph-image mg)) doesn’t change the image
displayed, though it seems like it should.
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
mspools and recent VM.
16 years, 1 month
Aidan Kehoe
Hi --
I’ve been getting the following error for me with recent VM when I
access my primary inbox by means of the mspools.el:
Wrong type argument: stringp, nil
The issue is that the variable vm-spool-files gets modified to look
something like this:
(("~/mail/inbox" "~/mail/inbox.spool" nil) ...)
The solution is the following patch to mspools.el:
--- mspools.el~ 2007-11-08 17:12:02.000000000 +0000
+++ mspools.el 2008-11-12 15:26:37.000000000 +0000
＠＠ -196,7 +196,8 ＠＠
;; Main mailbox
(list vm-primary-inbox
mspools-vm-system-mail ; your mailbox
- vm-crash-box ;crash for mailbox
+ (or vm-crash-box ; crash for mailbox
+ (concat vm-primary-inbox vm-crash-box-suffix))
))
;; Mailing list inboxes
For the XEmacs folk, a helpful piece of code for issues like this on 21.5
is:
(progn
(dontusethis-set-symbol-value-handler
'vm-spool-files
'set-value
'unimplemented)
(setq debug-on-error t))
Bye,
Aidan
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: yet another XEmacs fork;-)
16 years, 1 month
Aidan Kehoe
Ar an cúigiú lá de mí na Samhain, scríobh Julian Bradfield:
> >What you’ve done and what you propose appears, to me, to be less
> >maintainable and less coherent (more horrible) than the 21.5
> >approach. As
>
> That's the kind of response I was looking for ;-) Can you explain why?
> What I'm doing seems ultimately not all that different from the 21.5
> approach, except that I'm taking native UCS and UTF-8 to be the immediate
> goal, and leaving the Mule stuff alone for legacy compatibility; whereas
> 21.5 takes Mule as basic, and treats UCS as a (partly arbitrary)
> collection of Mule charsets, aiming ultimately for a big-bang abolition
> of Mule.
You’re losing unification (thus, often, data), even more than the Mule-UCS
approach does. Your Latin-2, Latin-3, Latin-4, Latin-10 ü code points are
distinct, and you have this extra Unicode encoding for it that the
corresponding coding systems won’t know about. You lose data when you encode
a Latin-10 ü using the iso-8859-1 coding system; you lose data when you
encode a Unicode ü using the Latin-10 coding system.
We’ve fixed this in 21.5 to an extent, in that we don’t normally use the ISO
2022 infrastructure for those coding systems where ISO 2022 encoding is not
the norm. And, in those coding systems, we do look at the Unicode encoding
of a character when deciding whether to trash it or not. We don’t have
robust checks for whether a region is encodable or not--see
http://mid.gmane.org/18509.34907.513276.700290＠parhasard.net for some work
in that direction, and for me severely underestimating the amount of work I
have to do this year--but I can’t see that your approach makes it easier.
Some questions that you may or may not have thought about:
How are you encoding your Unicode characters in the escape-quoted external
encoding? Since this encoding is used for auto-saves and for byte-compiled
ELC files, it needs to be capable of encoding every possible XEmacs
character.
What will Lisp code see when it calls #'split-char on your Unicode
characters?
Given the lack of unification in what you described, what unification rules
do you have in place or do you intend to put in place?
Given that the Mule code points in 21.4 are 19 bits wide, with only #x80000
possible code points, and that Unicode’s code points go up to #x10FFFF,
how do you encode the excess of #x8FFFF code points?
> [...] Sooner or later, the de-unification problem will be sorted out, by
> a combination of language identification (maybe even using those strongly
> discouraged language tag characters) and the definition of suitable sets
> of ideographic variation sequences; but until a consensus is reached on
> how this is to be done in plain text, we will still have documents all
> over the place in all the legacy encodings, with people feeling strongly
> about getting the right glyph for the right character.
Within XEmacs, the way to do that that seems to be correct to me is creating
extents with language tags on the level of the various legacy coding
systems, and picking a default for the Unicode coding systems, depending on
the current language environment.
> >you describe where you’re coming from, to me it seems to be a better idea to
> >fix VM on 21.5 and to improve 21.5’s speed where it matters to you.
>
> You're probably right, really...but meeting non-functional
> requirements is much harder than fiddling with functional
> requirements! I'm kind of hoping the real coders will deal with that.
OK. I hope you’re not holding your breath, but you seem to have thought
about most of what I had to say.
The idea has been floating around that it would be worthwhile converting
SXEmacs to Unicode internally and essentially dumping Mule, using GNU iconv
to handle all external encodings (which it ably can, with the fixable
exception of the ISO IR 196 sequences that we use in escape-quoted
byte-compiled files in 21.5). We can’t easily do that on 21.5 given the need
for Windows support, something SXEmacs has dropped. Had you seen that idea?
> (The really real motivation for this exercise is that I like to have
> some moderately intricate but basically easy task to distract
> me from the hard stuff I do for a living, and a project that makes me
> look hard at the XEmacs sources increases the chance I might one day
> make a real contribution to XEmacs.)
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
yet another XEmacs fork;-)
16 years, 1 month
Julian Bradfield
I think it's about time I came clean about why I've been finding bugs
and asking strange questions recently...
For a very long time, I've been almost but not quite perfectly happy with
XEmacs 21.4. There are two major bummers: the catastrophic slowness in
sequential access to large buffers; and the lack of true Unicode
support. (mule-ucs is pretty good, but requires some set-up, and loses
data if you get your set-up wrong, or find a file with a codepoint you
didn't know you had to deal with. mule-ucs is also really disgusting
to maintain. ccl, ack, splt.) The slowness I could now fix, by
backporting the 21.5.21 improvements to the bufbyte-charpos cache;
this message is about the other issue. (It might be worth saying that
I want extensive multi-lingual support because I write about languages
and non-English things, not because I actually do any non-trivial
document processing in anything other than English. So I have no need
to process a 100MB Japanese document efficiently, say.)
XEmacs 21.5 ought to be an improvement, given the massive changes made
in it, and the many MULE improvements, but for me it isn't enough.
The unicode support is bolted on in a rather horrible fashion, albeit
much more robustly than via mule-ucs; and it doesn't allow one to
distinguish between unicode and legacy stuff (and since I have some
sympathies with the philosophy behind UTF-2000, and specifically
sometimes want to talk about different hanzi shapes in CJK, that
matters to me). Moreover, 21.5 is (for the most part) slower, bigger,
and behaves differently in subtle ways that take a lot of finding in
my single most important application, VM. (My impression from this
list is that these problems are mostly VM's fault, but that doesn't
make them any quicker to fix.)
So for a long time I've been contemplating modifying XEmacs to be
natively UCS and UTF-8, while also preserving perfect backward
compatibility with the existing 21.4 way of doing things.
Three weeks ago I stopped contemplating and started wasting my
evenings (and my days off...) coding;-)
I chose to start from 21.4, both for the reasons above, and because
the 21.4 code base is somewhat less hairy than the 21.5 code base.
Having dealt with it for 21.4, doing the same for 21.5 should not be
too hard.
What I've done so far:
* Changed the Emchar so that it is either a UCS codepoint, or an old
style Mule character with a high bit set.
* Changed the Bufbyte encoding so that it is UTF-8, extended to
encode old-style Mule characters using some of the spare leading
bytes. (Since UCS was restricted to 17 planes, the bytes F5 to
FF are no longer valid leading bytes in UTF-8, so I'm using some
of them in an ad-hoc encoding for legacy characters. This means I'm
taking three bytes for mule official 1-D characters, and four bytes
for the rest, but I'm not too worried about that.)
* Introduced a new type of charset, the ucs charset, to represent
UCS characters. (I've stolen LEADING_BYTE_COMPOSITE for it, since I
don't believe XEmacs is ever going to support composite characters,
and I don't think it ever should.) For legacy compatibility, the
old charsets ascii, control-1 and iso-8859-1 are hard-wired-ly
identified with the first 256 points of ucs; all the other mule
charsets are completely distinct from the ucs charset.
* Made the necessary changes through the rest of the C code for this
to work "as expected". (The C code has far too many numerical
constants that should be #defines, by the way...Finding every
occurrence of 128 meaning MIN/NUM_LEADING_BYTES, or even worse,
4 meaning number of charset types, was acutely painful!)
Where I've got to now (or to be honest, where I will have got to
tomorrow - one or two things to fix up) is an XEmacs which (modulo bugs -
I haven't yet had the nerve to try it out in my actual main desktop)
is fully compatible with 21.4.21 at the Lisp and ccl level, as long as you
don't actually look at the integer representation of a character to
see the high bit flag - if you load mule-ucs, all your Unicode support
will happen the old way - but can also treat Unicode natively (in
which case it needs an iso10646-1 font).
What I still need to do to get to where I want to be:
* Embrace and extend some of the 21.5 chartab and unicode code so
that I can do efficient automatic conversion between ucs and mule
characters as required (needed in particular for quail to work in
utf, since at present decoding an iso2022 file produces mule
characters, not ucs characters); and so that search works properly
with translation tables etc., as I believe it does in 21.5.
This will also allow ucs characters to be displayed in legacy fonts
via a display table; and allow search to identify characters that
are the same in ucs.
* Check performance. For obvious reasons, I have all error-checking
and debugging switched on, with asserts everywhere, and
I dump core at the slightest provocation. It's a bit slow like
that, and I need to check that I haven't made things much slower in
normal use.
* Put back some search optimizations (I switched off boyer-moore and
fastmaps since I haven't thought how to deal with them; though
frankly I'm not convinced it's worth the effort these days!).
* Provide some ethnic cleansing options to force all mule characters
to be converted to ucs on sight; or not; or the other way round.
* (one day far in the future) bidi, combining characters, and all the
rest of it.
* all the things that are on the Mule wishlist - fixed width buffers etc.
Now, this could be a purely private project; or it could be a way that
either SXEmacs or XEmacs might want to consider. I'd be interested in
the views of the XEmacs developers on this idea - especially the
reasons why it's a really bad idea and hasn't already been done!
I guess it'll be a couple more weeks before I'm really ready to let
other people have the code - if you'd like to see it at that point,
drop me a line.
Julian.
P.S. Note new email address. My department has been forced to give up
its own mail service, and the Edinburgh University mail service is slow,
unreliable, and interferes with mail.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta