FR new command: E - edit variable

[GitMensch]

The easiest implementation just works for simple PIC 9 / PIC X, and/or has no validation of the data. A more complex one could do the validation and adjusting as needed (the "upstream" extension should have code in for that).

The E command would be also useful to be handled within the current Variable displays (just popping up as another window).

[GitMensch]

It seems the "C -> change variable" is already available, but only from the variable view.
I'd like to position on a word with the cursor and press a key to change its value.

E may be preferable to C as C is already taken in the main view.

[marcsosduma]

Okay. I got the idea. Thank you.

[marcsosduma]

Hi Simon! The problem is that in one line, I can have several variables. I would have to allow selecting one first or editing all of them.

[GitMensch]

If there are multiple ones in that line you may just an extra select, but if definitely suggest to first check if one of those is under the cursor.

[marcsosduma]

Hello Simon! I included the option to edit the variable in one line. Just click on H and then on "E".

[eugeniodilo]

Hi, I tried the new feature and I think it works great.

I also would suggest three small and simple improvements that can facilitate and simplify usability.

1. At following screen
   
   please substitute "Show Line Variables" with "Show Line Variables (E= Edit)"

2. At following screen
   
   please substitute "Edit Variable" with "Edit Variable (Enter= Confirm: ESC= Cancel)"

3. The documentation manual should be changed .
   Chapter 2.5. Show Command should became 2.5. Show and Edit Command

[marcsosduma]

Hello Prof. Eugenio! Could you forward me the modified 'odt' file?

[eugeniodilo]

Hi Marcos,
here is the updated document.
It is still the V04 version but the date is 20240403.
This document replaces the previous one.

COBGDB-GnuCOBOL-DEBUGGER-V04-20240403.odt

[marcsosduma]

Hello Prof. Eugenio! Thank you very much. I will update the project.

[GitMensch]

Again @eugeniodilo I suggest to move the docs to a subfolder "doc" and use markdown. This way it is easily visible online, can be easily adjusted - also partially - using pull requests and keeps images separated from text.
... and it still should be possible to create a PDF from that, likely also automated when these files are changed, if you feel the need for that.

[eugeniodilo]

Hi Simon, I went to check out your suggestion for which I thank you.
The site https://github.github.com/gfm/ contains the specifications of the markdown language for writing documents in github.
(there are almost seven hundred examples...)
In my work experience I have written many manuals and therefore with a word processor I can do everything I need very quickly and with a final result of a good standard.
While there might be some benefits as you indicated, I frankly don't think it's value-added for me to also learn this new markdown language just to convert this document to this guthub markdown format.
Subsequently, its management could only be carried out by others with the same skill on this markdown language for github.
(We already have some difficulty learning LATEX to handle the GnuCOBOL manual.)
Marcos has also already released version 4 by making the appropriate changes in the .odt document completely independently
I think it is better for me and for any other users to leave the document in a format manageable with WORD or LIBRE OFFICE.

[GitMensch]

OK. Note: there are wysiwyg editors for markdown, too, but if you both can go on with documenting this project I won't complain :-) Note: this issue is fixed, it should be closed.

[eugeniodilo]

Isuue solved.