July 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [Bug] XEmacs-21.0-b47/pre4; Popup menu at buttom/right 26 years, 2 months

Colin Rafferty

Christoph Wedler writes: >>>>>> "CR" == Colin Rafferty <craffert(a)ms.com> writes: >>> It is the following line in my .Xdefaults: >>> Emacs.geometry: 81x56--9--1 CR> Not for nothing, but the double-negative in the geometry may be the CR> problem. > That might be, but it is a correct X11 specification > Man X> The X offset may be specified in the following ways: [...] > Man X> -XOFF [...] XOFF may be negative, in which case the window's right > Man X> edge will be off the screen. I didn't realize that, though it does make sense now that I think about it. -- Colin

1 participants
0 comments

Re: [Bug] XEmacs-21.0-b47/pre4; Popup menu at buttom/right 26 years, 2 months

Christoph Wedler

>>>>>"CR" == Colin Rafferty <craffert(a)ms.com> writes: >> It is the following line in my .Xdefaults: >> Emacs.geometry: 81x56--9--1 CR> Not for nothing, but the double-negative in the geometry may be the CR> problem. That might be, but it is a correct X11 specification Man X> The X offset may be specified in the following ways: [...] Man X> -XOFF [...] XOFF may be negative, in which case the window's right Man X> edge will be off the screen. - Christoph

1 participants
0 comments

Re: 21.0-pre.5; Move enriched doc to the core distribution 26 years, 2 months

Colin Rafferty

Christoph Wedler writes: > enriched.doc should be moved to the core distribution since the Help menu > entry uses data-directory to find it. Or maybe it should use locate-data-directory instead.

1 participants
0 comments

Re: [Bug] XEmacs-21.0-b47/pre4; Popup menu at buttom/right 26 years, 2 months

Colin Rafferty

Christoph Wedler writes: >>>>>> "KJ" == Kyle Jones <kyle_jones(a)wonderworks.com> writes: KJ> Christoph Wedler writes: >>> >> Didn't see anything related in the pre5 announcement... >>> >> >>> >> My popup menu appears at the buttom/right of my screen (window manager >>> >> ctwm-3.5). '--with-session=no' worked for XEmacs-20.3 (wasn't necessary >>> >> in XEmacs-20.4), but does not help now. KJ> When you get a chance please, do the binary search thing with KJ> your .ctwmrc and figure out what is triggering the behavior. It KJ> willbe useful for the PROBLEMS file even there's no immediately KJ> obvious fix. > It is the following line in my .Xdefaults: > Emacs.geometry: 81x56--9--1 Not for nothing, but the double-negative in the geometry may be the problem. Shouldn't it look like this: Emacs.geometry: 81x56-9-1 When I use your geometry string on an xterm, I get it at position -0-0 (which is not what you want). When I use mine, I get it at the right place. > Looks like XEmacs-21.0 uses it also for the popup menu... This may be because of the double-negative. -- Colin

1 participants
0 comments

21.0-pre.5; Move enriched doc to the core distribution 26 years, 2 months

Christoph Wedler

enriched.doc should be moved to the core distribution since the Help menu entry uses data-directory to find it. - Christoph

1 participants
0 comments

Re: What about Guile ? 26 years, 2 months

Didier Verna

Jens Lautenbacher <jens(a)tellux.de> writes: > But like Oscar, I really would like you all to take into account some other > things beside that hardcore, low level stuff. M-x all-hail-both-of-you

1 participants
0 comments

Re: What about Guile ? 26 years, 2 months

Jens Lautenbacher

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > >>>>> "Oscar" == Oscar Figueiredo <Oscar.Figueiredo(a)di.epfl.ch> writes: > > Oscar> I would completely sacrifice the technical advantages of Scheme > Oscar> or CL in favour of a common extension language used by other > Oscar> free software products, and currently that means Guile. > > That simply is nonsense. Non-Guile Scheme implementations are at least > as common as extension languages as Guile itself. Fortunately, at the > *language* level, the Guile folks have since made sensible choices wrt > language design, reversing some of RMS's insane original ideas, and > basically making Guile a standard Scheme implementation. OK, this is now very very Linux specific, but guile is at least used in the GNOME project and hopefully will replace SIOD as an extension language in GIMP. I can't comment on the relative merits of guile (or malfunctions) when it comes to the implementation of the Scheme standard or the inner workings of that beast. But like Oscar, I really would like you all to take into account some other things beside that hardcore, low level stuff. Just because guile has bindings to gtk that are actively maintained and because of the fact that with the help of gimp and gnome a lot more people get interested in scheme and develop new bindings for guile makes it an option one really has to take into account, even IMHO if there may be some other scheme implementation that's a little bit better from a technical standpoint. Of course this gtk stuff is only an exampe. But it shows that there's now enough momentum in the guile user base that something like this was actually DONE (as easy as it may be) whereas when I looked around 1 or 2 years ago I didn't find any really usuable binding to a GUI toolkit besides some tk stuff. > The trick is to use a standard *language*, not a "standard" > implementation. Then you can make decisions independent of the actual > substrate at hand. This is actually not so difficult with Guile as it > requires minimal cooperation from the C code. That very same property > makes it a problematic choice for an XEmacs substrate. I don't understand that last sentence. Could you elaborate? Regards, jtl

1 participants
0 comments

docstring `write-region-annotate-functions' 26 years, 2 months

Christoph Wedler

Functions in `write-region-annotate-functions' might make another buffer the current one instead of returning a list of annotations. This is a very useful behaviour, it could be mentioned in the docstring to make it official. I could provide a first draft of the new docstring if you want to make this behaviour official. Looking at (fileio.c)build_annotations shows that behavior of functions in `write-region-annotate-functions' is basically the same as the encode functions in format-alist. For the encode functions, it is mentioned that they could change the buffer contexts (see MODIFY in the docstring of `format-alist'). - Christoph P.S. in the alpha version of my package x-symbol, I use a function safely in `write-region-annotate-functions' (since March) where x-symbol-encode copies the contexts to the third arg, switches to that buffer and does changes there... (defun x-symbol-write-region-annotate-function (start end) (and x-symbol-mode x-symbol-token-language (let ((selective selective-display)) (when (x-symbol-encode x-symbol-safe-exec-threshold (null x-symbol-file-has-8bits) (get-buffer-create " x-symbol conversion ")) (setq selective-display selective) t)) (message "X-Symbol Conversion in write-region%s" ; only alpha version (if font-lock-mode " with font-lock" " (fast)"))) nil)

1 participants
0 comments

Re: What about Guile ? 26 years, 2 months

Oscar Figueiredo

>>>>> "Michael" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: >>>>> "Oscar" == Oscar Figueiredo <Oscar.Figueiredo(a)di.epfl.ch> writes: Oscar> I would completely sacrifice the technical advantages of Scheme Oscar> or CL in favour of a common extension language used by other Oscar> free software products, and currently that means Guile. Michael> That simply is nonsense. Non-Guile Scheme implementations are at least Michael> as common as extension languages as Guile itself. Fortunately, at the Michael> *language* level, the Guile folks have since made sensible choices wrt Michael> language design, reversing some of RMS's insane original ideas, and Michael> basically making Guile a standard Scheme implementation. Michael> The trick is to use a standard *language*, not a "standard" Michael> implementation. [...] Be it so. My only concern is that from the user's point of view (the one who's trying to extend XEmacs or other free software) there is only one language to learn and not a different one for each piece of software he uses. If the different implementations of Scheme do not imply changes in the syntax of the language then I have no argument about using one implementation rather than another. Oscar

1 participants
0 comments

This mode-line-canna-mode thing ... 26 years, 2 months

Didier Verna

... is annoying. If I select a japaneese input method temporarily and then go back to my french-postfix, there's a big blank left at the beginning of the modeline.

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 July 1998