xemacs 21.5.28 autoconf version and berkdb check
17 years, 5 months
Hans de Graaff
The configure script in the xemacs-21.5.28 distribution is generated with
autoconf 2.61, but the comments at the top of the script mention that
autoconf 2.59 is mandatory. I seem to recall that there were some
incompatibilities with autoconf 2.61 initially, but that they were solved
at some point before 21.5.28 was released, so I guess the comment is
outdated?
Furthermore I also needed to apply the following patch to configure.ac to
get Berkeley DB support to actually work for berkdb-4.2.52:
--- configure.ac 2007/05/21 03:50:13 1.59
+++ configure.ac 2007/06/24 08:44:04
＠＠ -5475,7 +5478,7 ＠＠
fi
dnl Berk db 4.1 decorates public functions with version information
- if test "$enable_database_berkdb" != "yes" -a "$dbver" = "4"; then
+ if test "$enable_database_berkdb" = "yes" -a "$dbver" = "4"; then
rm -f $tempcname
echo "#include <$db_h_file>" > $tempcname
echo "configure___ dbfunc=db_create" >> $tempcname
Kind regards,
Hans
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: Ispell for Xemacs 21.1 for windows
17 years, 5 months
Vin Shelton
A little googling turned up
http://aspell.net/win32/
Maybe that would work for you.
HTH,
Vin
On 6/22/07, Edgardo De Leon <edeleon(a)cisco.com> wrote:
> Thanks Vin for the information.
> Actually I did not installed any ispell software. I assumed the Xemacs
> package would have installed.
> So Now that make sence. I do have an Ispell version for cygwin I'll give
> that a try and see if it works.
> If not, where can I find an ispell for Windows Xemacs version?
> thanks.
>
> Vin Shelton wrote:
>
> > On 6/21/07, Edgardo De Leon <edeleon(a)cisco.com> wrote:
> >
> >> I have just installed Xemacs 21.1 for Windows and I have included the
> >> ispell tool package. However, for some reason the ispell program does
> >> not work. Any time I start the ispell buffer, the following error
> >> shows up "Searching for Program: No such file or directory, ispell"
> >
> >
> > I hope you mean 21.4.xx. The current release of 21.4 is 21.4.20. A
> > windows native setup kit can be found here:
> > http://ftp.xemacs.org/pub/xemacs/windows/XEmacs_Setup_21.4.20.exe
> >
> > The problem is probably that you haven't installed an ispell
> > executable. What ispell did you install? Can you run it from a DOS
> > cmd.exe? If so, within XEmacs the directory that contains ispell.exe
> > must be added to the exec-path. C-h v exec-path will give you help on
> > exec-path.
> >
> > HTH,
> > Vin Shelton
> >
>
--
The Journey by Mary Oliver
http://www.poemhunter.com/p/m/poem.asp?poet=6771&poem=30506
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Future of ctags and etags in XEmacs
17 years, 5 months
Hans de Graaff
Hi,
Recently an old Gentoo bug [1] was revived about a file collision between
Exuberant ctags [2] and XEmacs and GNU Emacs. All of these applications
try to install /usr/bin/ctags and would overwrite each other's binaries.
We are currently discussing strategies to solve this issue, but I thought
I'd raise the issue here as well.
My current understanding, and please correct me if I'm wrong, is that:
Exuberant ctags is more featureful (e.g. supports more languages) than
the version shipped with XEmacs, and
Exuberant ctags is not a full drop-in replacement for ctags in XEmacs.
>From a distribution point of view the preferred solution would be to
unbundle ctags from XEmacs and let people decide (with the distro
providing a default) which ctags implementation to use. This would
certainly solve our problem. I'd be happy to explore other solutions as
well, and additional insight into this situation would be helpful.
Kind regards,
Hans de Graaff
Gentoo XEmacs maintainer
1. https://bugs.gentoo.org/show_bug.cgi?id=29398
2. http://ctags.sourceforge.net/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Ediff Confused
17 years, 5 months
Browder, Tom
SInce early this year, ediff-directories has been confused by a trailing slash on default directory names. For example, say I'm in directory
/dir1/dir2
and I start ediff for directory comparison the minibuffer will show "/dir1/dir2/" and I hit return. The minibuffer then shows "/dir1/" and I hit return and I get a response that the two directories are the same. If I do the same sequence but for each directory trim the trailing slash in the minibuffer, everything works as it always has (I believe that the old behavior did not have the trailing slash as the default as it does now).
Thanks.
-Tom
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: decoding base64 with mmencode often hangs (w32)
17 years, 5 months
Adrian Aichner
The following message is a courtesy copy of an article
that has been posted to comp.emacs,comp.emacs.xemacs as well.
Alan <wehmann(a)fnal.gov> writes:
> I have several emails which have PDF files attached (they are encoded
> in base64).
>
> I've been exploring why "call-process" with "mmencode" doesn't always
> work (to decode such attachments)--with
>
> XEmacs 21.4 (patch 19) "Constant Variable" [Lucid] (i586-pc-win32) of
> Sat Jan 28 2006 on VSHELTON-PC2
>
> on a box running MS Windows XP Pro.
>
> Distilling the problem to its essentials, the following hangs in the
> case of one particular base64-encoded PDF file:
>
> (apply 'call-process "mmencode" "d:\\Temporary\\work\
> \base64_coded_07_044" t nil '("-u"))
Hi Alan,
I've seen this problem with cygwin gpg and w3m as well under
xemacs-21.5-b2x for quite some time.
This seems to be some kind of timing issue relative to sending EOF to
the process.
I'm running with a silly workaround, which was good enough to let my
focus on this issue go.
Let's discuss this further on xemacs-beta(a)xemacs.org, if you're
interested in helping solve this problem.
See
http://calypso.tux.org/pipermail/xemacs-beta/2007-May/011237.html
Regards,
Adrian
>
> when evaluated in e.g. the "scratch" buffer ("d:\\Temporary\\work\
> \base64_coded_07_044" is the encoded attachment). If the "mmencode"
> process is terminated with the Windows Task Manager, a partially
> decoded PDF file is inserted in the "scratch" buffer.
>
> In a DOS command window, the following works just fine:
>
> mmencode -u -o d:\Temporary\work\trial_07_044_call_process.pdf d:
> \Temporary\work\base64_coded_07_044
>
> The executable for "mmencode" is the one that came with the XEmacs
> download.
>
> If the same email file is copied to a disk accessible to a Sun
> computer (running Unix), then using "call-process" and "mmencode" in
> that case has no difficulty with this same base64-encoded PDF file.
>
> On the box running Windows XP Pro, the email folder that contains the
> email with the problem attachment has other emails with PDF files
> attached (also base64 encoded), which are successfully decoded with
> the combination of "call-process" and "mmencode".
>
> I'm likely to get a ton of suggestions of how to deal with these email
> attachments in other ways, but I don't necessarily need such
> suggestions, since I'm probably familar with most of those other ways
> of doing things. I'm treating this difficulty as a learning exercise,
> since I'm likely to learn something if I end up understanding this
> behaviour.
>
> I invite comments.
>
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
font-lock-warning-face undefined
17 years, 5 months
Hans de Graaff
Hi,
I just found out that font-lock-warning-face is defined in list/font-
lock.el, but in such a way that code can't make use of it, as there seems
to be one part missing. The following patch fixes things (needs to be
applied to both 21.4 and 21.5).
And yes, I do need this for horrid FSF compatibility reasons. :-)
Kind regards,
Hans
Index: font-lock.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/lisp/font-lock.el,v
retrieving revision 1.31
diff -u -B -r1.31 font-lock.el
--- lisp/font-lock.el 2006/11/01 23:14:33 1.31
+++ lisp/font-lock.el 2007/06/23 07:14:17
＠＠ -721,6 +721,11 ＠＠
It is present only for horrid FSF compatibility reasons.
The corresponding face should be set using `edit-faces' or the
`set-face-*' functions.")
+(defvar font-lock-warning-face 'font-lock-warning-face
+ "This variable should not be set.
+It is present only for horrid FSF compatibility reasons.
+The corresponding face should be set using `edit-faces' or the
+`set-face-*' functions.")
(defconst font-lock-face-list
'(font-lock-comment-face
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Problem with the input of '€' (U+20AC EURO SIGN) with ~/.Xmodmap
17 years, 5 months
Mike FABIAN
My ~/.Xmodmap contains:
keysym e = e NoSymbol EuroSign NoSymbol
keysym c = c NoSymbol 0x010000a2 currency
Using that, I can input '€' (U+020AC EURO SIGN),
'¢' (U+00A2 CENT SIGN), and '¤' (U+00A4 CURRENCY SIGN) by typing
the following key sequences:
AltGr e → €
AltGr c → ¢
Shift+AltGr c → ¤
That works fine in all applications *except* XEmacs.
When I use that key sequence to type an € in XEmacs, the cursor
advances but I don't see a glyph. When positioning the cursor on that
character and checking with 'C-u C-x =' I get:
€Char: € (U+20AC greek-iso8859-7 36) point=1032 of 1128(91%) column 0
i.e. the € has been input correctly, the problem is only that it is
represented in the Greek character set, therefore a Greek font is used
and that doesn't have the € character (X11 core fonts are used, not
Xft).
If I input the € by other means, for example
- pasting from another application
- using the input methods t-latn-pre or t-rfc1345 from scim-m17n
I get
Char: € (U+20AC latin-iso8859-15 36) point=1200 of 1660(72%) column 9
and the € is visible.
Why is the Greek charset used when € is input via ~/.Xmodmap?
When trying to input ¢ via ~/.Xmodmap, it is even worse, I only get
the regular ASCII 'c' than.
But ¢ can be input just fine by pasting from another application and
by using an input method like scim-m17n.
So why doesn't this work with ~/.Xmodmap?
--
Mike FABIAN <mfabian(a)suse.de> http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
I � Unicode
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: Problem with the input of '€' (U+20AC EURO SIGN) with ~/.Xmodmap
17 years, 5 months
Aidan Kehoe
Ar an tríú lá is fiche de mí Meitheamh, scríobh Stephen J. Turnbull:
> Mike FABIAN writes:
>
> > Strange. Why does changing
> >
> > keysym c = c NoSymbol 0x010000a2 currency
> >
> > to
> >
> > keysym c = c NoSymbol cent currency
> >
> > in ~/.Xmodmap make the ¢ work then?
>
> The reason there *can be* a difference is because the former follows
> the path keysym -> Unicode -> Mule, while the latter follows keysym ->
> <X11/keysymdef.h> -> Mule.
That’s true of the X11 side, but not of the XEmacs code.
As I say, I don’t see this :-/ .
> Why there is a difference in practice I'm not sure; there historically
> was a lot of confusion between ASCII and ISO 8859/1 in Mule, maybe
> this is a remnant.
--
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: New mirror of XEmacs in Greece
17 years, 5 months
Adrian Aichner
Kapetanakis Giannis <bilias(a)edu.physics.uoc.gr> writes:
> On Sat, 23 Jun 2007, Adrian Aichner wrote:
>
>> Great, Giannis, this allows me to set everything up!
>>
>> One think I noticed:
>>
>> We added symbolic links recently from the pre-release directory for
>> any packages which only exist in the release directory.
>>
>> See
>> http://ftp.freenet.de/pub/ftp.xemacs.org/tux/xemacs/beta/experimental/pac...
>> for an example of a mirror which already has them.
>
> The links show up there, but they don't work either.
>
>> I don't see these links in
>> http://ftp.gr.xemacs.org/ftp/beta/experimental/packages/
>>
>> Could these links be mirrored as well, please?
>>
>> Please let me know if our mirroring instructions need updating.
>>
>> Adrian
>
> The links exist in my directory.
> However they have absolute path /ftp.
> /ftp does not exist on my system.
>
> I believe that's why apache is refusing to serv them.
> I tried to do a symbolic link of /ftp -> /xemacs/ftp_area
> and everything worked. (in http:// only. ftp:// was still problem)
>
> I would suggest that you do relative path links
> and not absolute path links.
>
> I tried to make the following symbolic link
> ln -sf ../../../packages/Sun-1.16-pkg.tar.gz
> and then I could download Sun package both from http://
> and ftp://
Thanks for the debugging, Giannis!
Norbert, can you please look into this?
Any reason not to use relative links?
Best regards!
Adrian
>
> Giannis
>
>
>
>
>
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta