EiffelStudio support for common entry tasks

[Bertrand Meyer]

In the forthcoming EiffelStudio 24.05 we have added a couple of mechanisms to facilitate common operations. We are interested to know (for future releases) of operations that require keyboard entry and that you perform frequently in your Eiffel work, for which EiffelStudio support would be useful.

 

The two examples implemented so far are the following.

 

#1: Producing a setter. If there is an attribute (or argumentless function)

                  a: T

 

one may need a procedure

 

                  set_a (x: T)

                                                       -- Make `x’ the new value of `a’.

                                     do

                                                       a := x

                                     ensure

                                                       a_set: a = x

                                     end

 

There is now a menu entry to produce this procedure automatically (with some parameterization).

 

#2: Producing a basic creation procedure. If a class has attributes a, b, c, … of types T1, T2, T3…, the idea is similarly to let EiffelStudio generate a creation procedure

 

                  make (x: T1; y: T2; z: T3…)

                                                       -- Initialize with values `x’ for `a’, `y’for `b’, `z’ for `c’…

                                     do

                                                       a := x

                                                       b := y

                                                       c := z

                                                       …

                                     ensure

                                                       a_set: a = x

                                                       b_set: b = y

                                                       c_set: b = z

                                     end

 

again with parameterization, e.g. you can choose names for the procedure and its formal arguments, and include only some of the attributes rather than all of them.

 

We have a short internal demo of the mechanisms at

 

https://bit.ly/3wRxrhK

 

It is an informal presentation of a development in progress and will be removed once the mechanism is finalized; details will change. But it gives the idea.

 

If you think that idea is good and have noticed other repetitive tasks in your own work, for which you would welcome environment support, please share your suggestions.

 

Note that at this point while we are not necessarily excluding sophisticated program composition tools (e.g. AI-based), we are more focusing on the low-hanging fruit – simple tools that simplify everyday tasks and in particular reduce the amount of typing needed. (Clarification to preëmpt the inevitable joke: we are NOT at the present stage considering removing typing, in the sense of assigning types to entities, queries and expressions, from the Eiffel programming language. The only “typing” we are proposing to remove is the use of one’s hands to type program texts using a keyboard.)

 

Comments welcome.

 

-- BM

 

[Thomas Goering]

In the forthcoming EiffelStudio 24.05 we have added a couple of mechanisms to facilitate common operations. We are interested to know (for future releases) of operations that require keyboard entry and that you perform frequently in your Eiffel work, for which EiffelStudio support would be useful.

 

The two examples implemented so far are the following.

 

#1: Producing a setter. If there is an attribute (or argumentless function)

                  a: T

 

one may need a procedure

 

                  set_a (x: T)

                                                       -- Make `x’ the new value of `a’.

                                     do

                                                       a := x

                                     ensure

                                                       a_set: a = x

                                     end

Could someone please explain to me how a setter (procedure) like the example above (set_a) would work for an argumentless function? I simply don't get it, especially because there is already a way to add a new feature in EiffelStudio (menu Tools -> New Feature, then select feature type "Function") that suggests that this makes sense.

In general, my feedback to the new "Composer" functionality would be to streamline it with similar existing functionality (like menu Tools -> New Feature) and to avoid different parameterization (e.g. not possible to set the setter as the assigner command?) or to avoid duplicate functionality at all.

There is now a menu entry to produce this procedure automatically (with some parameterization).

 

#2: Producing a basic creation procedure. If a class has attributes a, b, c, … of types T1, T2, T3…, the idea is similarly to let EiffelStudio generate a creation procedure

 

                  make (x: T1; y: T2; z: T3…)

                                                       -- Initialize with values `x’ for `a’, `y’for `b’, `z’ for `c’…

                                     do

                                                       a := x

                                                       b := y

                                                       c := z

                                                       …

                                     ensure

                                                       a_set: a = x

                                                       b_set: b = y

                                                       c_set: b = z

                                     end

 

again with parameterization, e.g. you can choose names for the procedure and its formal arguments, and include only some of the attributes rather than all of them.

 

We have a short internal demo of the mechanisms at

 

https://bit.ly/3wRxrhK

 

It is an informal presentation of a development in progress and will be removed once the mechanism is finalized; details will change. But it gives the idea.

 

If you think that idea is good and have noticed other repetitive tasks in your own work, for which you would welcome environment support, please share your suggestions.

 

Note that at this point while we are not necessarily excluding sophisticated program composition tools (e.g. AI-based), we are more focusing on the low-hanging fruit – simple tools that simplify everyday tasks and in particular reduce the amount of typing needed. (Clarification to preëmpt the inevitable joke: we are NOT at the present stage considering removing typing, in the sense of assigning types to entities, queries and expressions, from the Eiffel programming language. The only “typing” we are proposing to remove is the use of one’s hands to type program texts using a keyboard.)

Please also "harvest the low-hanging UI fruits" ;-) by giving them higher priorities. I'm sure that this will also simplify everyday tasks because users will be less distracted by UI-related bugs or inconsistencies. A good way to deal with this could be to dedicate a full release to UI "improvements" because I know that these kinds of issues are often not easy to solve, thus focusing on them could be useful.

Thanks,

Thomas

 

Comments welcome.

 

-- BM

 

 

[Brother Bill]

1. Keyboard scroll up/down by one line.  In other IDEs, this is done with Control + up-arrow and Control + down-arrow.
If already there, I don't know how to find it.

2. Also add menu item of "dictionary" of ALL keyboard shortcuts.

They work better if developers can find them.

3. Support Rename of attributes and local variables.

4. When using auto-complete for filling in actual arguments, after actual argument added, remove type as not needed.  Either automatically, or Control + SPACE or something similar.

5. Auto-correct casing of CLASS_NAMES, Constants, feature_names.  The compiler knows the rules, and can apply them.  This may be a setting to enable or disable.  There should be a way to let the developer go manual and win.

[Ulrich Windl]

Hi!

In my personal taste I'd like to see templated requirements for each parameter, like:
valid_x: true -- please adjust

Ulrich

27.05.2024 16:30:40 Thomas Goering <tho...@goering.com>:

> frequently

[Ulrich Windl]

Hi!

Typically I don't need #1. Instead I use a function that re-centers the current line vertically in the window, a function to jump at start or end of the current block (much like navigating in XML

Regards,
Ulric)

[Bertrand Meyer]

Good idea. (It took me a while to understand what you mean but yes, it's the right thing to do.) Thanks.

-- BM

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/1423571b-1bb2-4d16-802b-229a01f3312d%40gmail.com.

[Gary Smithrud (GMS134)]

What I really want for the UI is either support for high-contrast mode or themes, and the ability to turn off syntax coloring.  For some reason the latter seems to be popular, but for me there will always be case where I cannot read the text.  Just start up Eiffel’s Studio in high-contrast mode (black background version) and let me know what the buttons’ labels are.

Sent from my iPhone

On May 26, 2024, at 3:15 PM, Bertrand Meyer <Bertran...@inf.ethz.ch> wrote:



--

You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/0f2801daafa1%2406fe8570%2414fb9050%24%40inf.ethz.ch.

[Ian Joyner]

While I can see the need for the occasional set_x, we should be careful to note that getters and setters in other languages are to make up for the fact that annotating everything with ‘()’ breaks the Uniform Access Principle by exposing that anything with a getter or setter is a field. That breaks functional access, where ‘a’ could be a constant, field, or computation.

I can see the exception is the need to set a single value in an object.

However, getters are never needed with UAP, and expose the fact their is a data feature in the class, breaking encapsulation, almost as much as ‘()’ does.

So, there is my caution in this.

https://www.quora.com/Why-use-setters-and-getters-for-private-data-only-used-inside-the-class/answer/Ian-Joyner-1

Ian

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/087EA4EB-60ED-4A53-B4B0-44324DA87F7A%40gmail.com.

[Finnian Reilly]

In the forthcoming EiffelStudio 24.05 we have added a couple of mechanisms to facilitate common operations. We are interested to know (for future releases) of operations that require keyboard entry and that you perform frequently in your Eiffel work, for which EiffelStudio support would be useful.

For years I have been using a small utility integrated into EiffelStudio via the external tools facility. It allows you type directly into the source a shorthand for common text entry tasks. The tool then expands the entries. There is also a separate tool to display a list of feature category abbreviations you can use. It also does some sorting operations on feature names.

See class FEATURE_EDITOR_APP for documentation details.

I have had the occasional mishap but now it seems to be very reliable.

The only thing I am not happy with is the @set expansion. I might change it to allow explicit types for arguments instead of like x idiom if the type is known. I can think of lots of other expansions that could be performed.

It is part of a suite of development tools packaged into one executable.

-- Finnian

[Chris Tillman]

Nice. Now just add the MAKE_CLASS_NULL_SAFE one for completeness 😁😁

--

You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/26274655-f0fd-1726-4317-59d29d7f074f%40eiffel-loop.com.

[Jimmy Johnson]

I'ld like to see a spell checker [for comments].

jjj

[Jimmy Johnson]

Oh, and and vertical line to mark the right-hand margin (i.e. at 78 to 80 characters) settable by user of course.

jjj

[Ulrich Windl]

Hi!

I use Emacs for most programming, and you can spell-check single words or "regions" (contiguous text blocks) there. On UNIX-like OS it's done using ispell (or hunspell) running in the background. That's probably the problem: platform -independent spell checking is tricky unless you want to re-invent the wheel...

Regards,
Ulrich

[Ulrich Windl]

Hi!

Typically I set the window width to 80 characters and do line breaks accordingly. However when using proportional fonts that won't work.
However people have quite different opinions about line widths.
When resizing a PuTTY window in Windows, a small window shows the size in lines and columns while resizing. Maybe Eiffel studio could try something like that for fixed-width fonts.

[Bertrand Meyer]

Thank you for all the interesting suggestions received. We are collating them to see what can be included in the next (November) release. While suggestions are welcome at any time, we will close a first list by next Monday (June 3). So if you have any further suggestions ready please share them now.

 

Thanks,

 

-- BM

 

From: Bertrand Meyer <Bertran...@inf.ethz.ch>
Sent: Sunday, 26 May, 2024 21:15
To: 'eiffel...@googlegroups.com' <eiffel...@googlegroups.com>
Cc: 'me...@inf.ethz.ch' <me...@inf.ethz.ch>
Subject: EiffelStudio support for common entry tasks

 

In the forthcoming EiffelStudio 24.05 we have added a couple of mechanisms to facilitate common operations. We are interested to know (for future releases) of operations that require keyboard entry and that you perform frequently in your Eiffel work, for which EiffelStudio support would be useful.

 

The two examples implemented so far are the following.

[Brother Bill]

Provide "Expand/Explode" similar to Visual Studio, where a routine or entire feature can collapse and expand.

This makes it easier to focus on selected code.

[Gary Smithrud (GMS134)]

Explode?!?  Well, I suppose it will give me an excuse to buy a new computer.

Sent from my iPhone

On Jun 2, 2024, at 8:33 AM, Brother Bill <brother...@gmail.com> wrote:

Provide "Expand/Explode" similar to Visual Studio, where a routine or entire feature can collapse and expand.

--

You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/3692fcb8-818b-4d8f-8712-4c76cb381243n%40googlegroups.com.

[Brother Bill]

Another nicety would be to recognize when an additional right parentheses would be improper, and just moves the cursor one place to the right.  C# does this.

[Gary Smithrud (GMS134)]

I disagree with this if it does it when I’m typing.  Frequently I’m not paying attention to autocomplete and will type the ending ‘)’.  It would be really annoying, if I end up with “))”.

Sent from my iPhone

On Jun 3, 2024, at 5:06 PM, Brother Bill <brother...@gmail.com> wrote:

Another nicety would be to recognize when an additional right parentheses would be improper, and just moves the cursor one place to the right.  C# does this.

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/17be4dcf-3179-4897-82ec-281a36460d0en%40googlegroups.com.

[Brother Bill]

The C# approach with typing ) when not needed doesn't add another one, but just nudges you after the parentheses.  It is actually pleasant to use.

[Brother Bill]

Another nice feature is to label each "actual argument" with the "formal argument name", as in:  do_something (formal_argument_name: 42, another_formal_argument_name: "Foo")
To keep it simple, we could require that the positioning doesn't change.  This would aid self-documenting.

[Ian Joyner]

I think that should be a heads-up display, ie., move cursor over argument and it shows what the definition is, the name and the type.

Ian

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/fe2571d0-493f-4d07-8e8b-6fb18e024fbbn%40googlegroups.com.

[Ulrich Windl]

Hi!

In Emacs the feature is called "electric parentheses" (AFAIR). When closing a parenthesis, the cursor will either jump shortly to the corresponding opening parenthesis (text terminal), or the opening parenthesis will be highlighted (graphical environment). All if it's "onscreen"; otherwise a dtatus line reports what has been closed.


--

Kind regards,
Ulrich Windl

04.06.2024 00:06:09 Brother Bill <brother...@gmail.com>:

> Another nicety would be to recognize when an additional right parentheses would be improper, and just moves the cursor one place to the right.  C# does this.
>
> On Sunday, June 2, 2024 at 4:59:31 PM UTC-4 GMS wrote:
>> Explode?!?  Well, I suppose it will give me an excuse to buy a new computer.
>>
>> Sent from my iPhone
>>
>>> On Jun 2, 2024, at 8:33 AM, Brother Bill <brother...@gmail.com> wrote:
>>>
>>> Provide "Expand/Explode" similar to Visual Studio, where a routine or entire feature can collapse and expand.
>>> This makes it easier to focus on selected code.
>>>
>>> On Sunday, June 2, 2024 at 6:26:16 AM UTC-4 Bertrand Meyer wrote:
>>>>
>>>> Thank you for all the interesting suggestions received. We are collating them to see what can be included in the next (November) release. While suggestions are welcome at any time, we will close a first list by next Monday (June 3). So if you have any further suggestions ready please share them now.
>>>>
>>>>  
>>>>
>>>> Thanks,
>>>>
>>>>  
>>>>
>>>> -- BM
>>>>
>>>>  
>>>>

>>>> *From:* Bertrand Meyer <Bertran...@inf.ethz.ch>
>>>> *Sent:* Sunday, 26 May, 2024 21:15
>>>> *To:* 'eiffel...@googlegroups.com' <eiffel...@googlegroups.com>
>>>> *Cc:* 'me...@inf.ethz.ch' <me...@inf.ethz.ch>
>>>> *Subject:* EiffelStudio support for common entry tasks

>>>>
>>>>  
>>>>
>>>> In the forthcoming EiffelStudio 24.05 we have added a couple of mechanisms to facilitate common operations. We are interested to know (for future releases) of operations that require keyboard entry and that you perform frequently in your Eiffel work, for which EiffelStudio support would be useful.
>>>>
>>>>  
>>>>
>>>> The two examples implemented so far are the following.
>>>>
>>>>  
>>>>

>>>> *#1: Producing a setter*. If there is an attribute (or argumentless function)

>>>>
>>>>                   a: T
>>>>
>>>>  
>>>>
>>>> one may need a procedure
>>>>
>>>>  
>>>>
>>>>                   set_a (x: T)
>>>>
>>>>                                                        -- Make `x’ the new value of `a’.
>>>>

>>>>                                      *do*
>>>>
>>>>                                                        a := x
>>>>
>>>>                                      *ensure*
>>>>
>>>>                                                        a_set: a = x
>>>>
>>>>                                      *end*

>>>>
>>>>  
>>>>
>>>> There is now a menu entry to produce this procedure automatically (with some parameterization).
>>>>
>>>>  
>>>>

>>>> *#2: Producing a basic creation procedure*. If a class has attributes a, b, c, … of types T1, T2, T3…, the idea is similarly to let EiffelStudio generate a creation procedure

>>>>
>>>>  
>>>>
>>>>                   make (x: T1; y: T2; z: T3…)
>>>>
>>>>                                                        -- Initialize with values `x’ for `a’, `y’for `b’, `z’ for `c’…
>>>>

>>>>                                      *do*

>>>>
>>>>                                                        a := x
>>>>
>>>>                                                        b := y
>>>>
>>>>                                                        c := z
>>>>
>>>>                                                        …
>>>>

>>>>                                      *ensure*

>>>>
>>>>                                                        a_set: a = x
>>>>
>>>>                                                        b_set: b = y
>>>>
>>>>                                                        c_set: b = z
>>>>

>>>>                                      *end*

>>>>
>>>>  
>>>>
>>>> again with parameterization, e.g. you can choose names for the procedure and its formal arguments, and include only some of the attributes rather than all of them.
>>>>
>>>>  
>>>>
>>>> We have a short internal demo of the mechanisms at
>>>>
>>>>  
>>>>
>>>> https://bit.ly/3wRxrhK
>>>>
>>>>  
>>>>
>>>> It is an informal presentation of a development in progress and will be removed once the mechanism is finalized; details will change. But it gives the idea.
>>>>
>>>>  
>>>>
>>>> If you think that idea is good and have noticed other repetitive tasks in your own work, for which you would welcome environment support, please share your suggestions.
>>>>
>>>>  
>>>>
>>>> Note that at this point while we are not necessarily excluding sophisticated program composition tools (e.g. AI-based), we are more focusing on the low-hanging fruit – simple tools that simplify everyday tasks and in particular reduce the amount of typing needed. (Clarification to preëmpt the inevitable joke: we are NOT at the present stage considering removing typing, in the sense of assigning types to entities, queries and expressions, from the Eiffel programming language. The only “typing” we are proposing to remove is the use of one’s hands to type program texts using a keyboard.)
>>>>
>>>>  
>>>>
>>>> Comments welcome.
>>>>
>>>>  
>>>>
>>>> -- BM
>>>>
>>>>  
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

>>> To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/3692fcb8-818b-4d8f-8712-4c76cb381243n%40googlegroups.com[https://groups.google.com/d/msgid/eiffel-users/3692fcb8-818b-4d8f-8712-4c76cb381243n%40googlegroups.com?utm_medium=email&utm_source=footer].

>
> --
> You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/17be4dcf-3179-4897-82ec-281a36460d0en%40googlegroups.com[https://groups.google.com/d/msgid/eiffel-users/17be4dcf-3179-4897-82ec-281a36460d0en%40googlegroups.com?utm_medium=email&utm_source=footer].

[Brother Bill]

Highlighting matching parentheses would be helpful.  Select one parentheses, open or closed, and the matching other one is highlighted, such as being bold.

[Brother Bill]

Similar to setters, have default creation routine generator that does the boilerplate of the signature and setters.

[Ulrich Windl]

For Eiffel it should be "end" matching (and similar), too.