October 1998 - XEmacs-Beta - XEmacs Mailing List Archives

[Offtopic] VM 6.61 and tm 25 years, 7 months

Marcus Thiessel

I found that when I use tm with VM it doesn't translate the edit buffers to an appropriate MIME buffer before sending. Preview works and this doesn't applied to gnus. When I remember correctly tm/VM have been working. Anyone? --Marcus

1 participants
0 comments

[Offtopic] VM 6.61 and tm 25 years, 7 months

Marcus Thiessel

I found that when I use tm with VM it doesn't translate the edit buffers to an appropriate MIME buffer before sending. Preview works and this doesn't applied to gnus. When I remember correctly tm/VM have been working. Anyone? --Marcus

3 participants
2 comments

Re: Which CVS branch for DLL support? 25 years, 7 months

Hrvoje Niksic

Marat Boshernitsan <maratb(a)cs.berkeley.edu> writes: > > There is identical support in both the 21.0 and 21.2 branches. It > > worked the last time I tested it. > > Ok, thanks. Which one is more stable? 21.0 should be the more stable branch, but I'm not aware of any major destabilizing changes to 21.2, so it should be pretty much OK too. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Which is worse: ignorance or apathy? Who knows? Who cares?

1 participants
0 comments

Re: Kanji font selection (Mule showstopper?) 25 years, 7 months

Jan Vroonhof

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > "Recently" == when? I'd like to test a pre-change XEmacs. (I do see > a "font-menu fix by Jan Vroonhof" in CHANGES-beta for "Norwegian". > I'll assume that's it unless you say otherwise.) No that was a fix for typo in my earlier patch. The font menu change were integrated in early sept. I am not sure exactly which beta that was. > Yes, the ugly font gets selected. Yes, once the ugly kanji gets > installed changing fonts or size through the options menu or through > custom does not affect that ugly kanji font; it is wedged in the same > font, same size. OK, so the customize font handling is messed up with respect to MULE. It would be interesting to see whether it works with FSF EMacs. > Jan> 4. If you have an old .xemacs-options from an XEmacs that > Jan> worked and you used a 'option-save-faces = t' to save them, > Jan> what are the settings saved for the fonts. > > No, I don't have one. If you have some users running 20.4 it would be very nice to have one. > Wel, as Martin pointed out, the XEmacs view of fonts is also > lacking. I am afraid in this case customize is the culprit. Its way of modifying the default face needs to be improved (may be do it more like the old font-menu used to. The code is still there. FYI AFAIK customize constructs a totally new font whereas the old font-menu basically took the old one and applied changes. The latter method probably keeps some of the MULE settings. Jan

1 participants
0 comments

Bug: bbdb 1.02, autoloads missing and keymap undefined 25 years, 7 months

Heiko Münkel

If I'm running vm, the function `bbdb-migration-query' will be called, but at this time there is no autoload for this function. If I'm defining such an autoload, the function `bbdb-auto-notes-hook' will be called, for which also no autoload is defined at this time. After defining an autoload for `bbdb-auto-notes-hook' the command will fail because of an undefined bbdb keymap. All of them, the autoloads and the keymap are defined in the function `bbdb-initialize'. Therefore it seems, that the function `bbdb/vm-update-record' should at first call `bbdb-initialize' (havn´t checked that).

2 participants
1 comments

Re: Kanji font selection (Mule showstopper?) 25 years, 7 months

Jan Vroonhof

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > It has _not_ been in this state for a while. It was _not_ in this > state in 20.4, and not in some sufficiently early 21.0 betas. Note that I changed the font-menu to be Custom aware quite recently. I probably messed something up there or uncovered an hidden problem. If I am correct your problem is that choosing a different font from the font menu screws up other fonts (in this case the Kanji ones)? If so could you tell me 1. Where this also happens if you make exactly the same change with Customize (i.e. M-x customize-face RET default RET) 2. If you save options and then restart XEmacs are the fonts OK? 3. If setting font-menu-ignore-scaled-fonts to nil really early (i.e. before the first access to the font-menu) helps. 4. If you have an old .xemacs-options from an XEmacs that worked and you used a 'option-save-faces = t' to save them, what are the settings saved for the fonts. The options menu differs - from customize-face in that it contains some trickery to update the other fonts. This however is more or less the same as in the old font-menu. - from the old font-menu in that it now just informs customize of the change and let it change the default font. The old fontmenu used its own mechanism to derive the new font from the old. Maybe that preserved the mule info better. Unfortunately in order to 'keep it simple for the User' and to preserve compatibility with FSF Emacs the customize view of fonts is decidedly more primitive than the XEmacs one. Jan

2 participants
1 comments

Re: Which CVS branch for DLL support? 25 years, 7 months

Marat Boshernitsan

SL Baur <steve(a)xemacs.org> writes: > Marat Boshernitsan <maratb(a)cs.berkeley.edu> writes in xemacs-beta(a)xemacs.org: > > > Hi, > > I'd like to give the experimental DLL support a try, and perhaps do some > > work on it. Which CVS branch should I grab off the cvs.xemacs.org? > > There is identical support in both the 21.0 and 21.2 branches. It > worked the last time I tested it. Ok, thanks. Which one is more stable? (I am sorry if this is an obvious question, but I sort of lost track of which branches live in the CVS repository and what their tags and purposes are; perhaps this info could be put on cvs.xemacs.org?) Thanks, Marat.

1 participants
0 comments

Re: [patch] enhancements to package-ui.el 25 years, 7 months

Greg Klanderman

>>>>> "Darryl" == Darryl Okahata <darrylo(a)sr.hp.com> writes: Darryl> >> * M-x pui-list-packages now takes a prefix argument. With the >> prefix argument, it prompts for a package-get-base.el filename >> (using a sane default) which it then loads before doing anything >> else. Darryl> Darryl> Could you please separate the code that grabs the new Darryl> package-get-base.el into a separate function (in package-admin.el or Darryl> package-get.el -- and not package-ui.el)? Reasons: Darryl> Darryl> * Sometimes you just want to update package-get-base.el. Darryl> Darryl> * People who access these functions via menu picks cannot specify a Darryl> prefix (there's no way to specify a prefix using menu picks). We'll Darryl> probably have to provide a separate (?) menu pick that updates Darryl> package-get-base.el, and maybe yet-another-menu-pick (ugh) that Darryl> updates package-get-base.el before entering the visual package Darryl> installer. All this package-get-base.el stuff is such a pain. Now there's the incremental updates to deal with... blech. I wish we could just reliably and automagically snarf the current one off ftp.xemacs.org. Suggestions anyone? >> Maybe it should just always do this? Darryl> Darryl> Dunno. I can think of reasons to do it, and reasons to not do it. Darryl> [...] >> * In the *Packages* buffer, `x' (pui-install-selected-packages) now >> prompts for the directory in which to install packages, after >> confirming that you'd like to install the selected packages. Darryl> Darryl> This feature needs to be added, but your implementation has Darryl> potential problems: Darryl> Darryl> * The package install directory information needs to be managed by Darryl> package-admin.el. It's best if all the directory information is Darryl> maintained by one module. Darryl> Darryl> * Do we really want to allow installations into arbitrary directories Darryl> (that is, ones which will NOT be located by XEmacs' automatic package Darryl> path finder)? This is an issue for novice users. Personally, I think Darryl> we should restrict package installations to specific "system" Darryl> locations (e.g., to the package-paths specified at configure time) or Darryl> to the user-local location ("~/.xemacs/packages"???). Creating a good Darryl> user-interface for this is a pain, though, and so we might want to Darryl> just settle for some kind of warning if the user enters a "bad" path. I would definitely like to be able to specify anywhere, though I'd settle for a command which requires a prefix argument to allow that. OK, how about if I create 2 variables: package-get-default-install-dir and package-get-default-conflict which serve as the values of those arguments to package-get when unspecified (ie, nil). Then I add 2 pui commands to set them. How's that sound? (the CONFLICT argument sets the behavior when a package version already exists - should we re-install or ignore) >> The remaining issue for me is that if I have a newer version of a >> package installed than in package-get-base, it will happily overwrite >> it with the older version. Being able to disable installation of Darryl> Darryl> This sounds like a bug. Newer versions should never be overwritten Darryl> with an older one (well, maybe we should provide yet another prefix Darryl> arg/variable that forces an installation for advanced users). OK, I'll make it a warning if the version passed to package-get is nil (and do no update). Otherwise if a specific version is requested, it'll really get it. This is like a 2 line patch. greg

1 participants
0 comments

Re: Proposed version number change for 21.2 25 years, 7 months

SL Baur

Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: > SL Baur <steve(a)xemacs.org> writes: >> I would like to drop the beta designation as it currently exists and >> change the version to a triplet -- 21.2.XX. > This will be very confusing for users accustomed to Stallman's > numbering, where betas of 21.2 would be numbered 21.1.xx. Also, it is > highly non-obvious that 21.2 comes *after* 21.2.xx. This problem did > not exist with 21.2 coming after 21.2-*beta*-xx. There wouldn't be a 21.2. That's part of the point. There would be a 21.2.XX where XX is the number where we finally release.

3 participants
2 comments

Re: Proposed version number change for 21.2 25 years, 7 months

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > There wouldn't be a 21.2. That's part of the point. There would be > a 21.2.XX where XX is the number where we finally release. But then we introduce a .XX which is totally redundant from the users' point of view. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- there's a beast upon my shoulder / and a fiend upon my back

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta October 1998