jed-users mailing list

[2004 Date Index] [2004 Thread Index] [Other years]
[Thread Prev] [Thread Next]      [Date Prev] [Date Next]

Issues building jed 0.99-17


Hi Jedders,

Some time ago John Skilleter reported about some issues compiling jed on
windows. I was also trying to compile Jed on Windows, and found some
problems. My environment is:
- Windows 2000 server
- Visual Studio 6

(I have also cygwin installed, but here I'm talking about the native windows
version).

The Makefile generated with 'mkmake WIN32 VC' would work, but it has two
calls to the program 'touch', witch is not provided by Windows nor Visual
Studio. I remember that Borland used to pack some Unix-style tools with the
compilers.
Looking around I cannot find a good replacement, but the task is really
trivial for a C program: Windows implements the function _utime(). So I
wrote that small program, Added a configuration-dependent variable named
TOUCH, and set it to 'touch' for almost every configuration, except for VC.
The attached patch 'configurable-touch-for-vc.diff' implements this.

As John Skilleter noticed some time ago, there are a few missing calls to
jed_insert_chars(). Just in case these are still not fixed, the patch
'convert_chars_to_nbytes.diff' does the work.

The other missing function is jed_open_process_pipe(). But from a quick look
at the code, it seems to me that under Windows pipes are used anyway
(forgive me is this is not true, I'm far more used to the Unix interface).
So the patch 'win_define_jed_open_process_pipe.diff' defines the missing
function as a clone of jed_open_process().

The last fix to C code is really trivial: jprocess.c needs close-fold-mark.
This is in 'fix_missing_folding_mark.diff'.

An issue with the slang files is that the new CUA mode and folding mode both
generates errors with default wjed configuration. The windows-style menubar
is configured by default, but CUA calls menu_set_menu_bar_prefix(), which
gives an error if no Global menubar is found. folding.sl tests
'Menu_Popups_Loaded' variable, defined in menus.sl. We can put a check in
both, but I don't now if these two are the only offenders.

So I would prefer to have the standard menu bar even for windows. The
windows-style menubar has a different API, it's not synchronized with the
standard menubar, is by far less rich of features and configurability. But I
don't know what others windows users think about this.
The 'right thing' would be implementing a Windows style menubar that exports
the same interface used by the standard menubar. 

Later,
							Dino

Attachment: convert_chars_to_nbytes.diff
Description: Binary data

Attachment: configurable-touch-for-vc.diff
Description: Binary data

Attachment: fix_missing_folding_mark.diff
Description: Binary data

Attachment: win_define_jed_open_process_pipe.diff
Description: Binary data

Attachment: use-standard-menus-on-win.diff
Description: Binary data


[2004 date index] [2004 thread index]
[Thread Prev] [Thread Next]      [Date Prev] [Date Next]