Re: When a new version of JED will be released?

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

On 17.11.04, Marko Mahni? wrote:
> I am preparing a version of JED that works with FLTK (fljed).
...
> The work is far from finished. I plan to create a demo release
> by the end of this year.

this sounds really interesting, I am looking forward to it.
 
> When I look at the jed's sl files, I find many IFDEFS that
> deal with system-dependent keycodes. In fljed I created a
> function xkey() that takes a human-readable string
> ("C-x", "C-A-Enter", "C-k Up", ...) and converts it into
> a system keycode.

IMHO, it would be better to use Guidos keydefs.sl in these places, as it
works on all platforms the same. In my jedrc I have

require("keydefs"); % symbolic names for keys

and then

#ifdef XWINDOWS
% On X-Windows, for otherwise unindentified keys we can set the keysyms
% via x_set_keysysm.
% DEL (see also the original .jedrc for this topic)
x_set_keysym (0xFFFF,   0, Key_Del);
x_set_keysym (0xFFFF, '$', Key_Shift_Del);
x_set_keysym (0xFFFF, '^', Key_Ctrl_Del);    
...

and in cua.sl

...
setkey("delete_cmd",                	   Key_Del);
...
setkey("cua_delete_word",                  Key_Ctrl_Del);
...

This scheme is easily extensible for keys currently not in keydefs.sl
(I did this for the numeric keypad).

Maybe, we could reduce startup time by splitting keydefs.sl in
keydefs-x.sl, keydefs-konsole.sl, keydefs-IBMPC.sl and loading only the
appropriate part in site.sl.


> I also managed to do the reverse (with a patch in SLang):
> 
>   char *SLang_make_keystring(unsigned char *s)
>   {
>      if (X_Make_Keystring) return X_Make_Keystring(s);
>      ...
>   }
> 
> Now at least in menus the keys have human-readable names.
> (I tried to create xkey as X_Process_Keystring, but it
>  didn't work well).
>
> It is possible to do the same for other systems, too. I already
> have some code that will cover DOS and windows.

Did you try the variant of expand_keystring() from
http://jedmodes.sf.net/mode/hyperhelp/ ?

 DESCRIPTION
 This function takes a key string that is suitable for use in a 'setkey'
 definition and expands it to a easier readable form
       For example, it expands ^I to the form "\t", ^[ to "\e",
       ^[[A to Key_Up, etc...


It does not convert ^A ... ^Z, as IMHO this is as intelligible as C-A ...
C-Z, but "named" keys come out well (under every OS).


> Another feature in fljed: it recognises keys with multiple
> modifiers (Ctrl-Shift-Arrow, Ctrl-Alt-Shift-Meta-X, etc.)

This is something I really miss just now (for Ctrl-Shift-<Arrow> to mark
wordwise with cuamark.sl).

> I also noticed that jed has a flag VISIBLE_COLUMN_MARK. If
> this means jed will have block regions, I am very much looking
> forward to it. I also propose to add a VISIBLE_LINE_MARK flag.
> (I might add this to mark_window_attributes myself).

What do you want to flag with VISIBLE_LINE_MARK? "Normal" reagions, or 
lines tagged with create_line_mark()? BTW: There is a "slang-widget" for
listings in  http://jedmodes.sf.net/mode/listings/ .


> Would it be possible for the scrap to 'know' with what kind
> of region it was created (the way that brief does)?

As John wrote, you will need some wrapper functions that set e.g. a
Variable Last_Region_is_Block to 1 or 0. Then you could use one paste()
fucntion to call either yp_yank() or insert_rect().


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>.