Re: XJed do not set XWINDOWS with -batch

["G. Milde" <g.milde@xxxxxx>]

On  5.06.05, Joerg Sommer wrote:
> "G. Milde" <g.milde@xxxxxx> wrote:
> > On  2.06.05, Joerg Sommer wrote:
> >  
> >> one example:
> >
> >> message("You run "+
> >> #ifdef XWINDOWS
> >>         "XJed"
> >> #else
> >>         "Jed"
> >> #endif
> >>         );
> >
> >> $ xjed -batch -n -l /tmp/test.sl
> >> You run Jed
> >  
> >> Why this?
> >
> > Try `xjed` on a console, and you'll find that it runs jed (instead of
> > complaining about missing DISPLAY).
> 
> I thought it execs jed if DISPLAY is missing. 

Well, that is what I wanted to say. 

> Is gpm support missing if I use xjed in the console?

I do not know. 
 
> > I suppose a similar scheme works with -batch: the X layer is (seemingly)
> > not needed and hence not activated.

More precisely, xjed -batch seems to exec jed (as if DISPLAY is missing).

Example

if (is_defined("x_insert_selection"))
  message("x_insert_selection is defined");
else
  message("x_insert_selection is not defined");

$ xjed -batch -n -l /tmp/test.sl
...
You run Jed
x_insert_selection is not defined


------------------------------------------------------------------------
 
> >> A second problem, that arises with this issue: You can't use
> >> precompiled slang files with different jed types. 

> > You can use precompiled files with proper care. However, as the
> > preprocessor options are evaluated during the byte-compile,
> > distinguishing between jed and xjed with XWINDOWS doesnot work in
> > commonly used byte-compiled files.

> Because it is used in jed-lib, should we must create different byte
> compiled files in Debian for jed and xjed?

Short answer: Currently, Debian ships one set of byte compiled files for
jed and xjed, and no related bugs are open.

Long answer: We must make sure that either the related files are not
byte-compiled, or not used by the "wrong" jed variant.

The recommended way of byte-compiling the standard files (using preparse.sl)
generally takes care of this (by preparsing only a selection of files).

Lets grep for XWINDOWS in the jed-library-path:

/usr/share/jed/lib/keycode.sl:17:#ifdef XWINDOWS
/usr/share/jed/lib/keycode.sl:26:#ifdef XWINDOWS

keycode.slc exists, (preparsed with jed in Debian jed-common).
In jed it works as expected, in xjed it doesnot show the X keysym.

keycode.sl is listed in bytecomp.sl as "to be byte-compiled"

John, as keycode is rather sparingly used, could it be dropped from the
list in bytecompile.sl?

/usr/share/jed/lib/os.sl:9:#ifdef XWINDOWS
/usr/share/jed/lib/os.sl:21:#ifdef MSWINDOWS XWINDOWS MOUSE
/usr/share/jed/lib/os.sl:53:#ifdef XWINDOWS

os.sl says explicitely
 % This file should not be byte-compiled.
 % It is loaded from site.sl and permits various flavors of jed to share the
 % same set of S-Lang files. Much of it is written in RPN for efficiency.

/usr/share/jed/lib/runpgm.sl:1:#ifdef XWINDOWS

runpgm.sl is not byte compiled either. (It is small and not loaded by
default).


> >> Currently I use the .slc files build with jed with xjed. This fails, if
> >> they include XJed specific code.
> >
> > This is why I use "#ifdef XWINDOWS" only in  .jedrc.
> 
> But #ifdef is better, because your if (is_defined...) evaluates everytime
> to the same value. Or does slang optimize such constructs?

This is a tradeoff: 

   1. separate libraries for jed and xjed
   2. no byte compiling
   3. evaluate 'if (is_defined("...")' with every call


1. this adds IMHO too much complication and double effort (if I update a
   mode, I will have to remember to do this in 2 libraries and
   byte-complile both with the correct (x)jed.
   
2. this is ok for small/seldom used files or jed.rc   
   (for efficiency, I have moved most of my private custimization to a
    byte-compiled file "gm.sl" required by my jed.rc)

3. if sparingly used, the load implied by the evaluation of an additional
   'if (is_defined("...")' should not cause marked delays. 
   
   On way to ensure economic use of this feature is "outsourcing" of
   xjed code to a special file, e.g.
   
   if (is_defined("x_copy_region_to_selection"))     % XWINDOWS
     if(strlen(expand_jedlib_file("cuamouse.sl"))) 
        require("cuamouse"); % configurable cua-like mouse interface


grep in the local extensions library brings (besides some occurences in
comments)

/usr/local/share/jed/lib/latex.sl:672:#ifdef XWINDOWS
/usr/local/share/jed/lib/latex.sl:884:#ifdef XWINDOWS

this is your variant of latex.sl and could be stripped down to one
if (...) clouse

-#ifdef XWINDOWS
-      % Fix me!
-      variable Key_Shift_Return="\e[25$";
-      x_set_keysym(0xff0d, '$', Key_Shift_Return);
-      definekey("latex->newline_with_completion", Key_Shift_Return, BIB_KEYMAP);
-#endif

% Fix me! (is there a standard keystring for Key_Shift_Return?)
custom_variable(Key_Shift_Return, "\e[25$");  % xkeydefs.sl uses "\e[8$"
if (is_defined("x_set_keysym"))
   x_set_keysym(0xff0d, '$', Key_Shift_Return);
   
and in both keymaps simply define the key using Key_Shift_Return.


sincerely

Günter

   
-- 
G.Milde web.de

--------------------------
To unsubscribe send email to <jed-users-request@xxxxxxxxxxx> with
the word "unsubscribe" in the message body.
Need help? Email <jed-users-owner@xxxxxxxxxxx>.