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