Texinfo 5.x and the packages
11 years
Jerry James
Fedora updated its texinfo to version 5.0, and then version 5.1, in
the not-so-distant past. The XEmacs package and the XEmacs packages
packages [1] promptly stopped building, due to errors thrown by
texinfo while processing our texinfo sources. The attached patch is
an emergency patch that I threw together for our packages, just to get
things building for Fedora again. I don't think it is entirely
correct. Package maintainers, if there is a part in here for one of
your packages, and it looks correct to you, please pull that part out
and commit it. If it doesn't look correct, please suggest how to fix
it. Thanks,
Footnotes:
[1] Don't you just love overloaded terms?
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
[CONFIRMED] (was: C-g)
11 years
Uwe Brauer
>> "Jeff" == Jeff Sparkes <jsparkes(a)gmail.com> writes:
> I've fixed this. It's in the new
> bitbucket.org/xemacs/xemacs-gtkrepository as well as my original repo.
> I hope I updated the bug tracker
> correctly.
Hi
I just downloaded your last commit (BTW, the bitbucket webpage indicates
a size of 67.5 Mega, while the download is only 14 Megas, that is a
little confusing)
I compiled it and yes C-g works!
Three comments
- vertical resizing does not work! This is a real problem (I am on
a 12 inch Laptop)
- horizontal resizing sort of works, but after some seconds the
window resizes back to its original state.
- the fonts are still to small and cannot be changed by any means I
know.
Could you please try to solve problem 1? Or shall I also submit it on
the tracker?
As for 2+3, could you provide some documentation how to deal with it?
I would like to continue some testing but without 1+2+3 solved that is
almost impossible.
Thanks for the nice work
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Re: good+bad news BIDI pango
11 years
Uwe Brauer
>> "Jeff" == Jeff Sparkes <jsparkes(a)gmail.com> writes:
> 0 0xb775a430 in __kernel_vsyscall ()
[snip]
>>
> This crash is happening when trying to set the help string of a toolbar
> entry. It's crashing in
> LISP_STRING_TO_EXTERNAL, which is an internal XEmacs function. I'm not
> equipped to debug that.
> One workaround is to compile with --with-toolbars=no. The toolbar doesn't
> actually display anyway. :-) I had to check in a couple of changes to
> make it possible.
Hm I used our configuration, :-D
Are you sure that --with-toolbars=no doesn't do any harm? I recall some
incidence when want to use customize-option and the save button had
disappeared. But I am not sure that it was connected to toolbars or
not. I download and run the modified configuration then.
Uwe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Re: does not work
11 years
Michael Sperber
Jeff Sparkes <jsparkes(a)gmail.com> writes:
> Okay. You can just create an empty xemacs/xemacs-gtk and I can push into
> it. I'll just delete mine; it's not like there are a lot of people
> depending on it. Also, bitbucket let's let you leave a forwarding page.
Done. Thanks for working on this!
--
Regards,
Mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
good+bad news BIDI pango (was: error when compiling xemacs-gtk)
11 years
Uwe Brauer
>> "Jeff" == Jeff Sparkes <jsparkes(a)gmail.com> writes:
> On Fri, Nov 15, 2013 at 12:21 PM, Uwe Brauer <oub(a)mat.ucm.es> wrote:
>> gdk_visual_get_visual_type'
> Most of these were added late in Gtk 2 to make porting to Gtk 3 easier.
> There also were some new accessor functions in 2.22.
> I think I've fixed them all, but I still don't have an Ubuntu-10.04 VM
> built yet to test on.
Here are the good and bad news!
Good news.
- It compiles now, with some warnings but it compiles
- logical hebrew is displayed correctly, (I used the file you sent me)
- input is not very nice, the cursor jumps but it works! So I would
agree with Aidan: we have BIDI support, not as nice as GNU emacs,
but sufficient.
Bad news:
- more or less minor: the fonts are terrible, they are ugly[1] and
they are too small.
- xemacs needs ages to start, I first started with my init files,
but after a couple of minutes I killed it and restarted with
-vanilla, it still needs a long time.
- it seems impossible to resize the windows by a simple mouse movement
- in the upper right corner appears something which looks like a
*scratch* buffer (I could provide a screenshot)
Maybe this is all caused by the use of the old gtk library I am using.
In the current form it is un usable.
But it is great to have BIDI without the need to touch the display
engine.
Uwe Brauer
Footnotes:
[1] in Spanish slang (only in Spain) you could say they are as ugly as
beating a father.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Re: does not work
11 years
Stephen J. Turnbull
Jeff Sparkes writes:
> There's also 4 - push the changes into xemacs/xemacs. I'm
> completely up to date with the main repo. I don't know what others
> think of merging incomplete code.
It's not merely incomplete: of the three users discussing the port on
this list, two are experiencing undiagnosed and consistent crashes on
platforms we want to support. Those must be fixed before we merge, as
far as I'm concerned.
But I would prefer not merging until the port is reasonably feature-
complete, for example there needs to be a convenient way to set face
fonts from XEmacs (flashing in the initial frame when fonts are set in
init.el is OK -- people who care about that can learn how to configure
from gconf or whatever GTK expects). The same issue with Xft has been
a consistent annoyance, for example.
As long as Jeff is OK with it, I prefer the xemacs/xemacs-gtk strategy.
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Re: error when compiling xemacs-gtk
11 years
Stephen J. Turnbull
Jeff Sparkes writes:
>> I need to look into the --with-gtk vs --with-xft issue too.
> Pango can use xft, if you want to unify it that way. Cairo would cover
> more platforms.
Sorry, I wasn't clear. I simply meant avoiding using the current Xft
implementation in XEmacs and GTK at the same time -- it's pretty clearly
going to mess things up. The question is whether configure should fatal
if --with-gtk and --with-xft are specified together, or just issue a
warning and force with_xft=no.
> Ok. Maybe redisplay-xlike can become redisplay-cairo. Long term,
> using more glib might mean less platform specific code.
Yeah, that occurred to me. Except that the people working on the g*
libraries are really careless about backward compatibility (standard GNU
attitude). For example, I tried to check on the next version of glib in
MacPorts (there's a glib-devel port), and they apparently use CLOEXEC
without checking for support (so it doesn't work on my Mac, whose OS is
old enough that there's no support for CLOEXEC at all).
> Gtk 3 has gdkkeysyms-compat.h. I could use that, but there aren't
> that many keys used directly.
I assume that allows you to use the old GDK keysyms in GTK 3 code? No,
please don't do that. GTK 3 is where we want to go; if we're going to
cruftify code, it should be the GTK 2 code.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Re: error when compiling xemacs-gtk
11 years
Stephen J. Turnbull
Jeff Sparkes writes:
> Oops.
No problem, as long as we don't release it that way. I need to look
into the --with-gtk vs --with-xft issue too. (Not your problem unless
you really want it, Xft is my baby more or less.)
> I'll probably get a chance to try this on my ancient Mac soon.
> Maybe it'll crash in the same place and I can figure out
> a solution.
I wouldn't put money on it. Your Mac is a PPC ISTR, and mine is Intel.
> The mac isn't really a priority for Gtk, right?
GTK, probably not, but glib is going to be an issue if Aidan is right
and Pango is the best way forward for state-of-the-art font handling.
I also like the idea of a cairo-based redisplay, which might allow us
to get pretty close to native capability on all consoles cairo
supports. Both pango and cairo depend on glib.
> I didn't want to use #elif so that the HAVE_GTK2 chunks could be
> ripped out easily.
I think the #if (GTK_VERSION == 2) approach handles that. I don't
know about GTK_CHECK_VERSION, but I guess that's equivalent and
built-in to GTK? Keeping config.h (and configure) out of version
checking sounds interesting to me (although there may be problems I
haven't thought through).
Another possibility for the keystroke stuff would be a gtk3keys2gtk2.h
file which just #defines all the gtk3 keys in terms of gtk2 key defines.
> Yes. Some code is disabled, and doesn't call those functions yet.
> Now that Gtk 3 is mostly working, I'll be getting to that.
Great! If you're not testing with clang yet, let me know "when" and
I'll send you the clang warnings (they're different from GCC, and
often useful).
> I haven't thought forward yet. I'm happy to get a single font to
> load and display. :-)
Aha ... "sorry, Uwe, it will be a few iterations." :-P
> Pango works with fontconfig, so I'd be happy to use it.
OK, I'll take a look at it. Unfortunately my (old) Parallels on my
(old) Mac runs Ubuntu at really unusable speeds, so I don't have
regular access to a non-Mac GUI at the moment.
Thanks for your efforts on GTK!
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Re: error when compiling xemacs-gtk
11 years
Uwe Brauer
>> "Jeff" == Jeff Sparkes <jsparkes(a)gmail.com> writes:
> Uwe is running ubuntu 10.04 with an older version of Gtk than I used. I
> think he has 2.20, I just modified configure.ac to include that information.
I just downloaded the last zip.
Now there is a different error. I will try it out without clang.
,----
| device-gtk.o: In function `Fgtk_display_visual_class':
| /home/oub/ALLES/Add-Import/xemacs-gtk/jsparkes-xemacs-gtk-669d16f66129/src/device-gtk.c:500:
| undefined reference to `gdk_visual_get_visual_type'
| device-gtk.o: In function `gtk_init_device':
| /home/oub/ALLES/Add-Import/xemacs-gtk/jsparkes-xemacs-gtk-669d16f66129/src/device-gtk.c:267: undefined reference to `gdk_visual_get_depth'
| device-gtk.o: In function `gtk_device_system_metrics':
| /home/oub/ALLES/Add-Import/xemacs-gtk/jsparkes-xemacs-gtk-669d16f66129/src/device-gtk.c:541: undefined reference to `gdk_visual_get_colormap_size'
| device-gtk.o: In function `gtk_init_device_class':
| /home/oub/ALLES/Add-Import/xemacs-gtk/jsparkes-xemacs-gtk-669d16f66129/src/device-gtk.c:125: undefined reference to `gdk_visual_get_visual_type'
| glyphs-gtk.o: In function `convert_EImage_to_GDKPixbuf':
| /home/oub/ALLES/Add-Import/xemacs-gtk/jsparkes-xemacs-gtk-669d16f66129/src/glyphs-gtk.c:181: undefined reference to `gdk_visual_get_visual_type'
| ui-gtk.o: In function `g_type_to_lisp':
| /home/oub/ALLES/Add-Import/xemacs-gtk/jsparkes-xemacs-gtk-669d16f66129/src/ui-gtk.c:1815: undefined reference to `g_value_get_schar'
| collect2: ld returned 1 exit status
| clang: error: linker command failed with exit code 1 (use -v to see invocation)
| make[1]: *** [xemacs] Error 1
| make[1]: Leaving directory `/home/oub/ALLES/Add-Import/xemacs-gtk/jsparkes-xemacs-gtk-669d16f66129/src'
| make: *** [src] Error 2
`----
Uwe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
