1. Cuny's Editor Bug?

Dear David,
I use a Latinamerican keyboard layout, and can't make the
followig keys:

backslash               some_key+ALT GR
aroba (@)               2 + ALT GR
number (#)              3 + ALT GR
... and all other "normal" keys accesed with a ALT GR combination.

Unfortunatly this make your editor "unusuable" to me (and maybe
other not english language users). Could you fix it please?

Suggestions: You could add and internal interface with eprint.ex,
and besides the excelent help facility add the ed.ex way of looking the
refman.doc and library.doc.

Regards,
--

            ************************************
            This message sent by Daniel Berstein
            ************************************
     email: architek at geocities.com
 homepages: http://www.geocities.com/SiliconValley/Heights/9316
            http://www.cybercity.hko.net/silicon_valley/architek

new topic     » topic index » view message » categorize

2. Re: Cuny's Editor Bug?

Daniel Berstein wrote:

> I use a Latinamerican keyboard layout, and can't make the
> followig keys:

> backslash               some_key+ALT GR
> aroba (@)               2 + ALT GR
> number (#)              3 + ALT GR
> ... and all other "normal" keys accesed with a ALT GR combination.

Sorry about that. I've changed the way that the Alt+Gr works, but
I obviously did a poor job of it.

I'm was making the assumtion that in order to get the aroba key, for
example, you would hold down "AltGr", and then the "2" key.

The way the key handler is *supposed* to work is as follows:

1. The "AltGr" is read as an AltPressed, and the pre-menu routine in
   the editor is activated.

2. The "2" is pressed, and since the AltGr is pressed, DOS converts it
   to the proper keystroke. The pre-menu now needs to determine how to
   handle it. The options are:

      A. AltReleased has two possibilites:

          a. If there is a key in the buffer, then the user just
             entered a code via Alt+Keypad. The code is inserted
             into the MLE, and the pre-menu remains active.

          b. If there is no key in the buffer, the user simply
             let go of the Alt key. The AltReleased key and control
             are passed to the menu routine.

      B. 125-255 is assumed to be an extended key code entered into
         the buffer via the AltGr key, and is inserted into the MLE.
         The pre-menu routine remains active.

      C. Alt1-Alt0 toggles to the appropriate file, and the pre-menu
         routine remains active.

      D. If none of the above apply, The pre-menu routine gives the
         key and control to the menu routine.

I'm making a couple of assumptions:

   1. To access an AltGr key combination, you hold down the AltGr key
      first, then press the other key (example: "AltGr", then "2").

   2. The codes created by AltGr are in the range 125-255.

I suspect that the second assumtion is wrong, and the codes are lower than
125. Could you confirm this? If this is the case, it should be easy to fix,
by changing the logic of the pre-menu routine to test for the keys in this
order:

    1. AltReleased       - alt released
    2. Alt1-Alt0         - toggle screen
    3. 'a'-'z', '0'-'9'  - menu key
    4. Other             - AltGr key

Any better ideas?

> You could add and internal interface with eprint.ex

Printing is on the to-do list, after integration with PP.

> add the ed.ex way of looking the refman.doc and library.doc.

A lot of people have asked for these. I don't use them because
my 386 is too slow, but I'll add them to the help menu in the
near future.

There are two fixes to the help routine planned:

   1. Better indexing. Right now, only the first 8 chars are unique, so
      if two keywords have the same first 8 chars, there is a collision.

   2. Hyperlinks. This would allow a more Windows-like help system.

Don't hold your breath on those, though - they are low-priority.

Thanks.

 -- David Cuny

new topic     » goto parent     » topic index » view message » categorize

3. Re: Cuny's Editor Bug?

Cuny, David wrote:

> I'm was making the assumtion that in order to get the aroba key, for
> example, you would hold down "AltGr", and then the "2" key.

        When I said the ALTGR+2 I meant the key "2" in the normal
keyboard (the one that has the doble-quotes over it).

> I'm making a couple of assumptions:
>
>    1. To access an AltGr key combination, you hold down the AltGr key
>       first, then press the other key (example: "AltGr", then "2").

        That right, first the ALTGR and after that the combo key.

>    2. The codes created by AltGr are in the range 125-255.
>
> I suspect that the second assumtion is wrong, and the codes are lower than
> 125. Could you confirm this? If this is the case, it should be easy to fix,
> by changing the logic of the pre-menu routine to test for the keys in this
> order:

        I think the problem is that, the @,#,etc... keys are under value 125,
so your routine fails over them. Other problem may be that you're checking
the keypad numbers, and I'm using the normal keyboard for these combos.

> Any better ideas?

        I think the solution would be to "free" the ALT GR key from doing
functions that the ALT can do: ALT-0 toggle screen, ALTGR-0 prints ascii 0.

> Printing is on the to-do list, after integration with PP.

        What is PP?

> Thanks.

        Thank you!

Bye,
--

            ************************************
            This message sent by Daniel Berstein
            ************************************
     email: architek at geocities.com
 homepages: http://www.geocities.com/SiliconValley/Heights/9316
            http://www.cybercity.hko.net/silicon_valley/architek

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu