Mail Archives: djgpp/1997/10/24/04:20:54
SET wrote:
>> I would, if EMACS could work like my favourite editor, but I don't
>> think it can't be made to do some of the major things I like about
>> my favourite editor (scroll-lock,
> What scroll-lock does?
This editor uses the Scroll Lock key to enable/disable the mode where
it keeps the cursor on the same line, and scrolls the file accordingly
as I move around.
>> real-time program output capture,
>> scrollback through captured output and commands, and a few others).
> RHIDE does it and EMACS too.
Not very nicely. It doesn't associate the command with its output,
or let you edit and re-execute old commands by moving through the
captured output. But, no other editor apart from the one I use
does this either. It is one of the nicest features of this editor
IMO. OTH, EMACS's way of doing it would be OK most of the time.
>> These are fundamental design features and can't be added just by
>> binding keys :-) Some time when I have a few days to spare I will
>> try it out, though :-)
> I wasn't talking about EMACS ;-)
> RHIDE captures the errors and shows the line where the error is (the
> column too in Ada ;-).
That doesn't surprise me - I've used Borland's IDE too, remember :-)
>>> With RHIDE these alien files will become identical to Borland helps
>>> (much more slow but same look & feel).
>>
>> Yes! I just hope Borland don't try to sue RH for copying the look
>> and feel of Turbo Debugger! He has done an excellent job!
> RHIDE uses TVision, and Borland distributes it in your Web site.
> Additionally we ,Robert and I, are registered Borland users, they
> can't sue anybody :-)
Well, by selling TurboVision, Borland aren't necessarily saying that
they want you to write a program that uses exactly the same key
combinations and provides the same functionality as one of theirs!
But I'm sure they have more important things to worry about.
BTW, how are you able to distribute the source to a "port of Turbo
Vision"? I thought Turbo Vision was a commercial product...?
>> Yes, RHIDE seems to be great.
> Don't forget to test FSDB currently is harder to use but have some
> interesting features like inspect de GDT and LDT (very pmode specific).
Yes I have had a "quick play" with it. Thanks for that note.
[Intel to AS converter]
>> I don't agree that it wouldn't be useful. First, there is already 32-bit
>> code written in Intel format. Second, even for converting 16-bit Intel
>> code to AS format, converting 16-bit to 32-bit must be done manually but
>> is not tedious, whereas converting from Intel to AS would be tedious,
>> time-consuming and error-prone, and could be done by a program. Don't
>> you think?
>
> No, when I converted my MOD engine (90Kb asm) I found that the manual
> convertion was the best. Anyways, if I remmember well I have a link to a
> converter in my pages (I have over than 260 links).
Okay thanks.
>>> You can use NASM or JASM to write code in Intel style and link it with
>>> DJGPP (for links go to my Home Page).
>>
>> NASM isn't fully MASM/TASM compatible either (doesn't support ASSUME,
>> for starters :-), but I'll check out JASM, thanks.
> JAS is derivated from NASM, just a little more flexible. Anyways both have
> source so can be implemented. But ... wait a minute ... ASSUME?, that
> doesn't have much sense in flat pmode ;-).
True, but I'd still need something for real-mode programs, functions and
interrupt handlers (for dual-mode interrupt handling). But, you're
probably right.
>>>> Info reader bug - when I invoke 'info' with a keyword it doesn't know
>>>> about (e.g. 'info djasm'), it reports 'bad command or filename'
>>>> (probably reported by command.com) then hangs.
I've investigated this and found that info works properly if I remove
my DJGPP environment variable. In this case, 'info djasm' gives:
info.exe: dir: No such file or directory (ENOENT)
I then put the DJGPP environment variable back, and tried commenting out
the INFOPATH line under [info] in djasm.env, and info worked properly
then too. So I tried different settings for the INFOPATH line, for
example INFOPATH=C:/S/DJGPP/INFO, which is a valid directory, but nothing
seemed to work - info would always say 'bad command or file name' and
hang, requiring a reboot.
So it seems that if there is any INFOPATH setting in the [info] section
of djgpp.env, info hangs if the subject on the command line is unknown.
The original INFOPATH line was:
INFOPATH=%/>;INFOPATH%%DJDIR%/info;%DJDIR%/gnu/emacs/info
Suggestions anyone?
> Greetings, SET
Thanks again for your help.
Regards
Kris
--
Kris Heidenstrom kheidens AT actrix DOT gen DOT nz Wellington, New Zealand
Electronic designer and programmer
"Good sense is the most valuable good on the market"
- Raw text -