April 1999 - XEmacs-Beta - XEmacs Mailing List Archives

build problem with-mule 25 years, 7 months

T. Kurosaka - Sun Professional Services

Hello, I'm trying to build Mule enabled xemacs-21.2.9 from xemacs-21.2.9.tar.gz file I downloaded from the XEmacs beta page. My machine is Sun Ultra running Solaris 2.6 in Japanese locale. This is what I did: $ ./configure --with-mule --with-xim $ make This resulted in an obscure ld error: ld: fatal: option -B has illegal argument `export' ld: fatal: Flags processing errors *** Error code 1 make: Fatal error: Command failed for target `temacs' Current working directory /home/kuro/ARCHIVE/xemacs-21.2.9/src *** Error code 1 make: Fatal error: Command failed for target `src' I could find a problem in src/Makefile and fixed it there by changing this line: ld_dynamic_link_flags=-Wl,-Bexport to: ld_dynamic_link_flags=-Wl,-Bdynamic Then I rerun "make" in src directory. temacs seems to have been built OK but it failed to find a mule lisp file. The build stopped with this message: Loading /home/kuro/ARCHIVE/xemacs-21.2.9/lisp/dialog.elc... (1740) Load file mule-charset: not found Fatal error during load, aborting *** Error code 1 (ignored) *** Error code 1 make: Fatal error: Command failed for target `xemacs' and I'm stuck here. Am I supposed to download mule-charset.el as a separate piece? Thank you in advance. -kuro

1 participants
0 comments

Re: possible bugs with key maps? 25 years, 7 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes: > > > > The behavior now may be correct, but that doesn't mean it can't be > > > improved. (I can think of several options: for example, defining a > > > key to be 'undefined could override the value of > > > retry-undefined-key-binding-unshifted, or the value of this variable > > > could be "local" to each keymap. > > > > Yes, that would be useful indeed. Like a "keymap property". Except > > that it's non-trivial to do, because keymaps actually hold subkeymaps, > > and the property should be propagated correctly. > > What is wrong with the "if explicitly bound to 'undefined do not do > the lookup' solutions? Nothing, I hope. To quote a woman, keymap.c is shpxvat whznawv.

1 participants
0 comments

Re: ethiopic.el missing 25 years, 7 months

Hrvoje Niksic

Oscar Figueiredo <Oscar.Figueiredo(a)di.epfl.ch> writes: > I just made a CVS update 21.2 and tried to build: it seems that > ethiopic.el is missing from the server. Yes; the new files were missing from Olivier's patch. For a quick workaround, just touch ethiopic.el and ethiopic.elc (and the other missing files), or hack dumped-lisp.el to not require it.

1 participants
0 comments

Re: possible bugs with key maps? 25 years, 7 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > > The behavior now may be correct, but that doesn't mean it can't be > > improved. (I can think of several options: for example, defining a > > key to be 'undefined could override the value of > > retry-undefined-key-binding-unshifted, or the value of this variable > > could be "local" to each keymap. > > Yes, that would be useful indeed. Like a "keymap property". Except > that it's non-trivial to do, because keymaps actually hold subkeymaps, > and the property should be propagated correctly. What is wrong with the "if explicitly bound to 'undefined do not do the lookup' solutions? It is even FSF compatible. On the face up it it doesn't seem that difficult. Just move the Qundefined -> Qnil mapping done in process_event_binding_result in the call to event_binding, to somewhat higher up. Maybe even add a an extra parameter to event_binding to tell it whether to do the mapping, but that should bit. Jan

1 participants
0 comments

ethiopic.el missing 25 years, 7 months

Oscar Figueiredo

I just made a CVS update 21.2 and tried to build: it seems that ethiopic.el is missing from the server. Oscar

1 participants
0 comments

Re: possible bugs with key maps? 25 years, 7 months

Hrvoje Niksic

John H Palmieri <John.H.Palmieri.2(a)nd.edu> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes: > > > I guess `princ' could be changed to `prin1' without too many > > problems, but binding keys to anonymous functions and then > > complaining about `C-h k' output is ridiculous. > > You might even say that binding keys to anonymous functions is > ridiculous, I was very careful not to say that because it wouldn't be true. Although not stylistically "nice", binding keys to anonymous functions is very convenient and perfectly legal. But when you do that, you really shouldn't expect that part of `C-h k' output to be nice. > but if someone does it in some lisp code, and some else tries to get > help on the key, they should get helpful help. If using `prin1' > will make the help message better, why not change it? No reason not to -- if you want to do it, I believe the patch will be accepted. It's just that I don't see it as a bug that would require our attention, if it can be considered a bug at all. > (Certainly, once I find out about that variable, I'll have some idea > what it is. I tend to rely on the info files for documentation, so > if the variable isn't mentioned in those, I'm not likely to find it. > My second option is to browse through Emacs lisp files. I haven't > done anything approaching a thorough search, but I haven't found the > variable in any of those, either. I guess I'll have to start > reading the c source code, like you said...8-|) If it makes you feel better, I believe I stumbled upon the variable accidentally. > > Whether the resulting behaviour in your case is correct is another > > question. I think it is. > > I'm not sure what you mean by "correct". As far as I can tell, the > behavior I see agrees with the documentation, so it is "correct". Accordance with the documentation is only one measure of correctness. There are others, such as Emacs 18 compatibility (very strong in keymap.c and event-stream.c), FSF Emacs compatibility, "intuitiveness", etc. > (Only as far as I can tell, though: does some info file actually say > what happens in a keymap if shifted keys are undefined?) I don't know. A perfunctory search yielded no matches, which might mean the feature is undocumented, along with the `retry-undefined-key-binding-unshifted' variable. > On the other hand, I think it would be better if one could actually > define keymaps in which "a" does something and "A" does not. (For > example, one might want to do this in dired mode. For another > example, when typing TeX documents, one might want a keymap for > typing Greek letters and other symbols, so hitting `g will insert > "\gamma", `G will insert "\Gamma", `a will insert "\alpha", and `A > will beep, because there is no "\Alpha" in TeX. But you can do that. Just bind "A" to a function that will signal error. Or bind it to `keyboard-quit'. > The behavior now may be correct, but that doesn't mean it can't be > improved. (I can think of several options: for example, defining a > key to be 'undefined could override the value of > retry-undefined-key-binding-unshifted, or the value of this variable > could be "local" to each keymap. Yes, that would be useful indeed. Like a "keymap property". Except that it's non-trivial to do, because keymaps actually hold subkeymaps, and the property should be propagated correctly.

1 participants
0 comments

shell mode cursor movement snafu. - Part II 25 years, 7 months

Rodney Stromlund

>>>> original text >>>> I am experiencing a problem in shell using XEmacs 21.2-b13 (and in 21.2-b9). When I am running a program that produces lots of output and I press page up or cursor up or page down or cursor down (etc...), the display freezes. The cursor movement will not display until *after* the program exits. If I break it (^C^C), the display will unfreeze when the break reaches the program. The break (^C^C) can take 10 or more seconds to take place and about 1000 more lines received in the buffer. Has anyone else experienced this? I search the mailing-list and found nothing on this. Please help, >>>> end >>>> P.S. I forgot to mention that rsh and telnet do *not* exhibit this behaviour. =============================== Rodney Stromlund Southwest Airlines Co. Systems Department Sales & Revenue Accounting Group mailto:rstromlu＠wnco.com (214) 792-6484 ===============================

1 participants
0 comments

shell mode cursor movement snafu. 25 years, 7 months

Rodney Stromlund

I am experiencing a problem in shell using XEmacs 21.2-b13 (and in 21.2-b9). When I am running a program that produces lots of output and I press page up or cursor up or page down or cursor down (etc...), the display freezes. The cursor movement will not display until *after* the program exits. If I break it (^C^C), the display will unfreeze when the break reaches the program. The break (^C^C) can take 10 or more seconds to take place and about 1000 more lines received in the buffer. Has anyone else experienced this? I search the mailing-list and found nothing on this. Please help, =============================== Rodney Stromlund Southwest Airlines Co. Systems Department Sales & Revenue Accounting Group mailto:rstromlu＠wnco.com (214) 792-6484 ===============================

1 participants
0 comments

Re: possible bugs with key maps? 25 years, 7 months

John H Palmieri

Hrvoje Niksic <hniksic(a)srce.hr> writes: > I guess `princ' could be changed to `prin1' without too many problems, > but binding keys to anonymous functions and then complaining about > `C-h k' output is ridiculous. You might even say that binding keys to anonymous functions is ridiculous, but if someone does it in some lisp code, and some else tries to get help on the key, they should get helpful help. If using `prin1' will make the help message better, why not change it? > > make `A undefined. This seems like better behavior to me: the > > default is still to have "A" act like "a" (so SHFT-SPC acts like > > SPC), but it's not hard to unbind "A" if one wants to. (Plus, one > > might actually be led to try this by reading the documentation.) > > The name of the variable `retry-undefined-key-binding-unshifted' > suggests that undefined keys should be retried unshifted. Obviously, > the code in keymap.c considers a key being bound to `undefined' as > "undefined", which looks correct to me. (Certainly, once I find out about that variable, I'll have some idea what it is. I tend to rely on the info files for documentation, so if the variable isn't mentioned in those, I'm not likely to find it. My second option is to browse through Emacs lisp files. I haven't done anything approaching a thorough search, but I haven't found the variable in any of those, either. I guess I'll have to start reading the c source code, like you said...8-|) > Whether the resulting behaviour in your case is correct is another > question. I think it is. I'm not sure what you mean by "correct". As far as I can tell, the behavior I see agrees with the documentation, so it is "correct". (Only as far as I can tell, though: does some info file actually say what happens in a keymap if shifted keys are undefined?) On the other hand, I think it would be better if one could actually define keymaps in which "a" does something and "A" does not. (For example, one might want to do this in dired mode. For another example, when typing TeX documents, one might want a keymap for typing Greek letters and other symbols, so hitting `g will insert "\gamma", `G will insert "\Gamma", `a will insert "\alpha", and `A will beep, because there is no "\Alpha" in TeX. I'd much rather have it beep than insert "\alpha".) The behavior now may be correct, but that doesn't mean it can't be improved. (I can think of several options: for example, defining a key to be 'undefined could override the value of retry-undefined-key-binding-unshifted, or the value of this variable could be "local" to each keymap. As it stands, I still can't tell how to use this variable in any way that's helpful rather than annoying (considering things like SHFT-SPC, etc.).) -- John H. Palmieri e-mail: palmieri.2(a)nd.edu 205 Computing/Math Bldg. URL:http://www.nd.edu/~jpalmier/ University of Notre Dame (219) 631-8846 Notre Dame, IN 46556

1 participants
0 comments

Re: possible bugs with key maps? 25 years, 7 months

Jan Vroonhof

John H Palmieri <John.H.Palmieri.2(a)nd.edu> writes: > I'm not sure what you mean by this. Since `C-h k' is one of the basic > help commands available, its output should be as clear and unambiguous > as possible. The problem is that clear and unambiguous (i.e. readable in the lisp sence, output by prin1) is not always readable in the "for humans sense". I personally think it is a bug but I am not sure how to fix it. Changing that particular princ to prin1 is trivial, but the kind of output you would really want is unavailable in Emacs. > make `A undefined. This seems like better behavior to me: the default > is still to have "A" act like "a" (so SHFT-SPC acts like SPC), but > it's not hard to unbind "A" if one wants to. (Plus, one might > actually be led to try this by reading the documentation.) On the face of it this looks like a good idea. I don't think it would be that difficult to do, it would just ugly the code by taking the Qunbound special casing to a somewhat higher level. > Is this variable documented anywhere (in an info file, that is: I know > how to type C-h v)? You need to know to type C-h a :-). Seriously, I only found it after I had found the part of the source code that does this transformation. The C-h v documentation seems to be all there is. > How should I have found out about it, besides > asking people familiar with the source code? C-h a shift RET :-) > > Does "bind" in the last sentence mean that I should use `let'? Yes. It probably also means that whoever wrote that help string thought you would only use it in a situation where you were sitting in a tight loop reading in user input. You would then surround that loop with a (let. Note that this is at input time, not at the time the keymap is defined.) Jan

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 April 1999