setedit-users — General list about setedit

Patched eterm

[salvador <sal...@in...>]

Hi All!

For those we want to experiment running the editor in X without losing those
lovely keys like Shift+Arrows I uploaded a patched eterm that supports the
special mode needed for it.
The installation is tricky and involves the description found in
/usr/share/setedit/eterm
I uploaded the sources of eterm 0.8.10, the patches added by Debian
maintainer and my patches. I also uploaded a .deb compiled for Potato
systems.
All is in Source Forge.

SET

--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set...@bi... se...@co...
                    se...@ie...
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013

Re: Key assignment

[Ivan B. <lu...@ad...>]

	Hello.
	Since we are there, I think it would be better if all the configuration
of the editor was in text format, text configuration files are the most
flexible of all configuration files.
	It would be nice (if the configuration changes from binary to text) to
be able to include configuration files from one file to other, something
like the #include "" in CPP, in this way the editor can come with
standard configuration files and then the user can include them from
their own main configuration file or just copy&paste and change some
things.
	The problem with text files, is that the editor would have to try hard
to not screw up the user hand-made changes.
	On the other hand, if the editor is fully configurable via SLisp
commands, then the configuration files could be simple SLisp files
specifying things and doing some actions, that would give a lot of
flexibility, but how the editor can change the configuration files made
by the user?
	Though, all that seems very complex, so as Thiago suggests: the
.keybinds.dat should be a text file.
	Goodbye.

P.s.: just a suggestion and see if it is possible...


"Thiago F.G. Albuquerque" wrote:
> 
> Hi,
> 
> I have some things to say about the key assignment in SETEDIT.
> 
> First of all, I think ".keybinds.dat" should be a text file.
> 
> I change most of the default key assignments. For me it is easier/faster to edit a file than to
> reassign key by key using the GUI. And when I get a new version of SETEDIT I don't have to do it
> all again; I can just copy the file. Yes, right, I can do that with the binary file too. But if
> the file format changes from one version to the other (like the pmacros file changed, for
> instance), it is possible for me to peek at the files, see what has changed and make the
> necessary modifications.
> 
> The list of key assignments doesn't show the keys assigned by the menues. This can be pretty
> annoying; I reassigned f9 to "make", but it didn't take effect because some menu assigned it to
> SDG. I think all key assignments should be in the same place.
> 
> One possible solution to this: menubind.smn doesn't assign keys. At most, it specifies the name
> of the key that shows in the menu, but the actual key assignment is in keybinds.dat. Drawback:
> the information in the menus can get "old" (in the sense of not corresponding to the reality
> anymore). If you reassign a key related to some menu, you have to edit menubind.smn and change
> the key name. Not a very big problem, though.
> 
> Another (better) idea:
> 
> New file: ~/seteditrc -> user-specific macros and key assignments. Loaded at startup.
> New sLisp command: (bind keys command/macro)
> 
> e.g.:
>     (bind "^L" cmcOpenFile) ; assigns CTRL-L to cmcOpenFile
>     (bind "#^M"  my_macro)  ; CTRL-SHIFT-M to my_macro
> 
> where
> ^ == CTRL
> # == SHIFT
> @ == ALT
> 
> This way you can define your macros and assign them to a key in the same file, like in Emacs.
> 
> This solution also addresses another issue: the lack of user-specific macros. The macros file is
> system-wide and you can edit it only if root lets you do so.
> 
> What do you think, SET?
> 
> Thiago
> 
> _______________________________________________
> Setedit-users mailing list
> Set...@li...
> http://lists.sourceforge.net/lists/listinfo/setedit-users

-- 
Ivan Baldo:
lu...@ad... - http://go.to/ibaldo - ICQ 10215364
Phone: (598) (2) 613 3223.
Caldas 1781, 11400 Malvin, Montevideo, Uruguay, South America.

(If you have problems with the previous addresses, try this ones:
ib...@us..., http://members.xoom.com/baldo.1).

Technical keyboard stuff about TV lib.

[salvador <sal...@in...>]

Hi All:

There are a known race when a user debugs an Allegro application using
RHIDE. This race is between the keyboard handlers of BIOS and Allegro. The
problem is that Ctrl+F9 is the shortcut and then BIOS sees the Ctrl key-down
message, but not the key-up. So when you hit a breakpoint and BIOS gets the
control again the Ctrl key remains pressed because the key-up message was
absorved by Allegro.
It can be solved from the Allegro side like this:
If a key-up message is received before a key-down and it belongs to a
modifier key clean this bit in the variable that holds the BIOS state.
But it can be solved in TV like this:
In the Resume we could just clean any keys modifier, after all you shouldn't
expect that a amodifier will survive to a suspend/resume of the library.
Opinions?

SET

--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set...@bi... se...@co...
                    se...@ie...
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013

Linux PPC: Turbo Vision

[salvador <sal...@in...>]

Wow!

  It compiled perfectly in a Power PC, there are some small problems that=

are obvious:
1) Shadows are painted wrongly.
2) Alt+Key doesn't work, but the mouse works.

  Note this target is *big endian*, I introduced some endian corrections =
in
the last releases mostly thanks to Jos=E9 Angel Sanchez Caso.

BTW the /proc/cpuinfo says:

processor       : 0
cpu             : 604ev5 (MachV)
clock           : 375MHz
revision        : 1.0
bogomips        : 373.56
total bogomips  : 373.56
zero pages      : total 0 (0Kb) current: 0 (0Kb) hits: 0/80936 (0%)
machine         : CHRP IBM,7043-150

SET

--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set...@bi... se...@co...
                    se...@ie...
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013

Linux Alpha: Turbo Vision

[salvador <sal...@in...>]

Hi All!

Now that we are using Source Forge we have a very interesting facility: The
Compile Farm.
Developers registered in source forge can make a ssh connection to various
Linux machines to test their code.
Today I tested a target of Turbo Vision that I had almost solved but that I
didn't test in more than two years: Linux running on Alpha processors.
The good news are that just commenting a line I was able to compile the
TV demo without any problem in a machine powered by an Alpha CPU with Debian
Potato GNU/Linux installed (glibc 2.1.3).

SET

--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set...@bi... se...@co...
                    se...@ie...
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013

Re: use-indent size option not saved

[salvador <sal...@in...>]

ma...@pl... wrote:

> I'm greatfull you added the use-indent-size tab option I have been
> nagging you about ;-), but there's one small problem:
> The value of the option is not preserved between runs, and neither does
> setting it in the global options work. My guess is that you
> forget to save it in the dst file.

Thanks, that's why I label as beta those releases. I need people really
interested in these new features to test them. As I never use it my testing
is quite poor, just at the moment I implement and debug the feature.

> About the new list location: yay! I think it's an improvement.
> To subsribe to the topica list I have to retry severeal times
> because my connection to topica is broken each time during the
> subscription process (probably because I have a very slow
> mobile phone modem).

And I hope we will enjoy other benefits of Source Forge.

SET

--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set...@bi... se...@co...
                    se...@ie...
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013

Re: .setedit dir in home

[salvador <sal...@in...>]

ma...@pl... wrote:

> Right now the editor dumps all it's files (keybind.dat, the
> main tcedit.dst and the er* files) in the homedirectory of the user
> (linux).

True and the ammount of files is starting to be quite annoying.
That's why last night I modified it. But I forgot er* files, I'm putting it
in my schedule.
Also note that er* files are very important, and now the Linux ones are as
important as the DOS ones.
Now the editor not only tries to dump unsaved text to these files but also
the stack trace. I also created a small Linux application equivalent to
djgpp's symify to convert the addresses dumped there into source+line. And
what is even better: now the Linux version of the editor can be configured
to use gdb to dump the full calling stack (including values of the arguments
and local variables) to these er* files. Is also possible to automagically
call gdb and pass the control to gdb. The last two options must be enabled
by the user and the installed editor must install a binary with debug info
and have nm and gdb tools installed but that's really powerful because you
can go directly to gdb if the editor generates a SIGSEGV or gets a
SIGINT from a kill. What's even more funny is that: if the editor is under X
a separated xterm is launched to run the gdb there ;-), is really funny to
see the second window popping with gdb showing the stack frame and offering
a propmpt to analize why the editor died.

> Would it be very hard to out them in a .setedit directory
> instead?

Is done. I hope I'll put in in the CVS in less than a week.

> This would also fix another annoying feature:
> When you use the editor for the first time in a new directory
> it copies the tcedit file from your home directory, including
> any files that may be open there.

True, now the default tcedit.dst is first loaded from ~/.setedit/tcedit.dst
avoiding loading the one in ~/tcedit.dst which usually contains some opened
windows.

> This is hardly ever what you want,
> so it would be more logical to put the defaults in a ~HOME/.setedit
>  directiry (IMHO ofcourse)

Yes, and that's how is supposed to work now. Of course it will need a lot of
beta testing.
Additionally I added a new detail. As you could have files like deflopts.txt
as hidden files in your home (~/.dflopts.txt) from old versions a surprising
behavior will be exposed: the editor will load this file (which is
intentionally plain text) and if you modify it the file will be stored in
~/.setedit/deflopts.txt. So if you load manually the old file you'll get
surprised, the modifications aren't there, but they are working. So now when
the editor loads a configuration file from a directory and stores the
modified in another place a dialog informs the user where the file was
stored.

SET

--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set...@bi... se...@co...
                    se...@ie...
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013

Re: Key assignment

[salvador <sal...@in...>]

"Thiago F.G. Albuquerque" wrote:

> I have some things to say about the key assignment in SETEDIT.
>
> First of all, I think ".keybinds.dat" should be a text file.

Sorry, but the answer is no. this file is a complex tree and must be loaded before anything (unlike
pmacros files, keywords for syntax highlight, errors.cle, etc. which are loaded on demand).
Parsing it every time is a real waste of time.
I agree that a de/compiler of this file could be a very good idea.

> I change most of the default key assignments. For me it is easier/faster to edit a file than to
> reassign key by key using the GUI.

Yes, but isn't safe. When you do it using the TUI you *must* type the key you want. Under DOS you
won't get any surprise, the key you type is exactly what the editor gets and the name is quite
right. But under other OSs or when you have a non-us keyboard the name could be really different or
the key could be absent. A good example is Linux, some key combinations doesn't generate any code
that the editor can understand, that's configurable at OS level (in Debian
/etc/console-tools/default.kmap.gz).
If you edit a file by hand you can get very bad surprises.

> And when I get a new version of SETEDIT I don't have to do it
> all again;

That's, mainly, my fault. The editor should backup old configuration files, specially if they could
be modified.
But is also yours, you should also backup it ;-)

> I can just copy the file. Yes, right, I can do that with the binary file too. But if
> the file format changes from one version to the other (like the pmacros file changed, for
> instance), it is possible for me to peek at the files, see what has changed and make the
> necessary modifications.

Usually the editor is able to load files in the old format. Currently the editor can load desktop
files created back in 1998.
There are another detail that I think I never documented, mainly because is untested. DOS is the
problem, in Linux if you modify the keybind.dat file it won't be saved over the original one (a
normal user can't write to /usr/share/setedit), intead the file will be stored in the users home.
When I coded it I added to the DOS version the posibility to load configuration files from the
directory pointed by the HOME environment variable.
And here I'm asking for beta testing: You should try to define HOME (in autoexec.bat or in
djgpp.env) to point to a directory, lets say c:/usr/tfga and put your keybind.dat there. Then just
overwrite the one in %DJDIR%/share/setedit (or %SET_FILES%/share/setedit) and look if the editor is
loading the right file.

> The list of key assignments doesn't show the keys assigned by the menues.

Of course.

> This can be pretty
> annoying; I reassigned f9 to "make", but it didn't take effect because some menu assigned it to
> SDG. I think all key assignments should be in the same place.

Is impossible. The keys assigned to menues and status bar accelerators are configured in the
menubind.smn file.
It can't be in another way. If you don't modify the menu at the same time you modify the
accelerator you will get really silly situations. Suppose you put Shift+F9 == SDG, but you don't
modify the menu, then the menu will clearly say SDG==F9 and that's more than confusing.
I know the documentation is quite hard to read because is mainly a lot of separated pieces and not
one coherent description. But what a hell that's currently 6438 lines, 29997 words and 192990
characters long! I really need help to put all together.
I'm sure the keyboard configuration section should clearly state how to configure the menues and
status bar accelerators by pointing to the section that describes it. But beleive me that writing
such a huge documentation is hard specially when you must express complex stuff in a foreign
language.

> One possible solution to this: menubind.smn doesn't assign keys. At most, it specifies the name
> of the key that shows in the menu, but the actual key assignment is in keybinds.dat.

Sorry but I won't do that.

> Drawback:
> the information in the menus can get "old" (in the sense of not corresponding to the reality
> anymore). If you reassign a key related to some menu, you have to edit menubind.smn and change
> the key name. Not a very big problem, though.
>
> Another (better) idea:
>
> New file: ~/seteditrc -> user-specific macros and key assignments. Loaded at startup.
> New sLisp command: (bind keys command/macro)

That's in my "todo", I don't know if I'll do it exactly like that, but yes I want to add sLisp
commands to assign keys.

> e.g.:
>     (bind "^L" cmcOpenFile) ; assigns CTRL-L to cmcOpenFile
>     (bind "#^M"  my_macro)  ; CTRL-SHIFT-M to my_macro
>
> where
> ^ == CTRL
> # == SHIFT
> @ == ALT

I think it will be much more coherent if I use the same names used in menubind.smn and keybind
dialogs (CtShAlM == Strl+Shift+Alt+M)

> This way you can define your macros and assign them to a key in the same file, like in Emacs.
>
> This solution also addresses another issue: the lack of user-specific macros. The macros file is
> system-wide and you can edit it only if root lets you do so.

That's incorrect. In Linux you should copy this file to your home directory and modify this copy.
BTW, in the WIP version I changed the loading/storing sequence of configuration files a little bit.
Just for systems oriented to users (not DOS nor Win32). Now the editor tries to load the file in
the following sequence:
1) ~/.setedit/name
2) ~/.name
3) ~/name
4) $(SET_FILES)/name or /usr/share/setedit/name or /usr/local/setedit/name (The one that contained
syntaxhl.shl at start up)

When writing:
1) ~/.setedit/name if the editor fails to create the directory or the user doesn't have write
access there (I think that's impossible) then
2) ~/.name

As you can see the editor will load /usr/share/setedit/keybind.dat and the modified file will be
stored in ~/.setedit/keybind.dat
You should do the same for macros.slp.

Again: Is my fault the lack of documentation, but I really need help.

SET

--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set...@bi... se...@co...
                    se...@ie...
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013

.setedit dir in home

[<ma...@pl...>]

Hi set,

Right now the editor dumps all it's files (keybind.dat, the
main tcedit.dst and the er* files) in the homedirectory of the user
(linux). Would it be very hard to out them in a .setedit directory
instead? This would also fix another annoying feature:
When you use the editor for the first time in a new directory
it copies the tcedit file from your home directory, including
any files that may be open there. This is hardly ever what you want,
so it would be more logical to put the defaults in a ~HOME/.setedit
 directiry (IMHO ofcourse)

 gr

 --
 Martijn Versteegh

Key assignment

[Thiago F.G. A. <tf...@za...>]

Hi,

I have some things to say about the key assignment in SETEDIT.

First of all, I think ".keybinds.dat" should be a text file.

I change most of the default key assignments. For me it is easier/faster to edit a file than to 
reassign key by key using the GUI. And when I get a new version of SETEDIT I don't have to do it 
all again; I can just copy the file. Yes, right, I can do that with the binary file too. But if 
the file format changes from one version to the other (like the pmacros file changed, for 
instance), it is possible for me to peek at the files, see what has changed and make the 
necessary modifications.

The list of key assignments doesn't show the keys assigned by the menues. This can be pretty 
annoying; I reassigned f9 to "make", but it didn't take effect because some menu assigned it to 
SDG. I think all key assignments should be in the same place.

One possible solution to this: menubind.smn doesn't assign keys. At most, it specifies the name 
of the key that shows in the menu, but the actual key assignment is in keybinds.dat. Drawback: 
the information in the menus can get "old" (in the sense of not corresponding to the reality 
anymore). If you reassign a key related to some menu, you have to edit menubind.smn and change 
the key name. Not a very big problem, though.

Another (better) idea:

New file: ~/seteditrc -> user-specific macros and key assignments. Loaded at startup.
New sLisp command: (bind keys command/macro)

e.g.:
    (bind "^L" cmcOpenFile) ; assigns CTRL-L to cmcOpenFile
    (bind "#^M"  my_macro)  ; CTRL-SHIFT-M to my_macro

where
^ == CTRL
# == SHIFT
@ == ALT

This way you can define your macros and assign them to a key in the same file, like in Emacs.

This solution also addresses another issue: the lack of user-specific macros. The macros file is 
system-wide and you can edit it only if root lets you do so.

What do you think, SET?

Thiago

use-indent size option not saved

[<ma...@pl...>]

Hi Set,

I'm greatfull you added the use-indent-size tab option I have been
nagging you about ;-), but there's one small problem:
The value of the option is not preserved between runs, and neither does
setting it in the global options work. My guess is that you
forget to save it in the dst file.

About the new list location: yay! I think it's an improvement.
To subsribe to the topica list I have to retry severeal times
because my connection to topica is broken each time during the
subscription process (probably because I have a very slow
mobile phone modem).


Martijn Versteegh

Announce: SETEdit 0.4.47 Beta sources released (CVS also available)

[salvador <sal...@in...>]

Hi All:

  That's the announcement that I released sources for the beta version of
setedit v 0.4.47.
  I also released a beta version of Turbo Vision (v 1.1.1).
  For those who don't know setedit is the editor and help system used by
RHIDE since 1996.
  The editor is mainly oriented to programmers and is quite powerful.
  I think this release is really stable but until I don't get enough
feedback I won't tag it as a stable release.
  Right now only sources for Linux and DOS (DJGPP) are available. But I hope
to upload binaries also because now I have all the disk space I need (thanks
to Source Forge).
  The DOS files can be compiled to create a Win32 native application with
the free BC++ 5.5 compiler. I consider this target in alpha stage, be
careful.

  http://setedit.sourceforge.net/

  You'll need Turbo Vision library, it is available from: (last beta is
1.1.1)

  http://www.geocities.com/setedit2001/tvision.html

  I also moved the editor mailing list to Source Forge and last sources are
available through CVS. All the information is in the above mentioned page.

Enjoy!
SET

--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set...@bi... se...@co...
                    se...@ie...
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013