I meant: "respectful and visible disagree IS healthier in any
community." :-)
On 08/03/16 10:34, Offray Vladimir Luna Cárdenas wrote:
Hi,
I think that the aliases work fine, so we can have both, one letter
shortcuts and long descriptive names. On the agree to disagree issue,
I think that my best way to disagree was to implement some
cross-pollination ideas between Leo + IPython + Smalltalk in Pharo,
with my own styling for code and expectations for code completion,
interactivity and easy installation and with focus mainly on the task
where I used Leo before. As I told several times, for me Leo brings an
important experience, tool and community and respectful and visible
disagree in healthier in any community.
Cheers,
Offray
On 08/03/16 07:31, john lunzer wrote:
On Tuesday, March 8, 2016 at 4:09:34 AM UTC-5, Edward K. Ream wrote:
On Mon, Mar 7, 2016 at 4:31 PM, Offray Vladimir Luna Cárdenas
<[email protected] <javascript:>> wrote:
As far as Leo's code goes,
w
e are going to have to disagree about this one. Leo's one-letter
abbreviations work for me, and longer names simply wouldn't.
Longer names for truly important items like c, g, p, c.p, p.v,
etc would be unbearable. Ditto for d, w, etc.
I agree with you on the code base Edward. In my mind it is the onus
of the developer to learn the truly justifiable time saving
one-letter abbreviations. There is only a couple handfuls of the and
they are generally phonetically linked to their intended full
meaning. I do not believe that anyone interested in developing for
Leo will find them a barrier to development. Their usage's are well
documented in the appropriate section. In the end the effort of
memorizing 10 OLAs helps the developer as it reduces code clutter
significantly in Leo's case.
In contrast, the argument against one/two/three letter abbreviations
for commands is much higher when you start getting into having
hundreds or thousands of commands. Even sprinkling in abbreviations
in the vanilla distribution is a slippery slope. Intentional
abbreviations created by the user is a much safer policy.
Leo already has all of this. Short names avoid the need for code
completion or tab completion. This seems like a small thing but
definitely is /not./ I think I am reliable judge of what is and
isn't convenient when dealing with Leo's code base.
Edward, you are a reliable judge! I will reiterate what Edward said,
code completion and tab completion is anything but trivial and
certainly has no chance of making it into 5.2, nor should it as that
has not been on the radar.
I would love to see full code/tab completion implemented into Leo as
I'm sure everyone else would. But this is a huge wishlist item,
months worth of work and eventual bugs. As I use Leo more I find
myself coming around more and more to Edwards points of view on Leo
related issues. If anyone wants code/tab completion that programmer
can use many other editors. It's prevalence elsewhere makes it feel
like a "standard feature" and that without it something feels off.
But that kind of thinking misses the point of Leo and Edwards life
work completely.
There are bigger and more important problems/barriers in programming
that still need to be investigated and solved. These are the barriers
that Edward has chosen to focus on and I'm behind his decision
one-hundred percent. Anyone with Qt/Python/Jedi/Rope knowledge could
come in and get code/tab completion working. Few others in the world
of programming and editors have the vision for turning code into
something other than a wall of text.
That said, one day tab/code completion would be great to have and
would as OVLC said help create a good first impression because it
removes one more of those "but that editor has this" thoughts. One
day we will get there but I feel it is safe to say that it is not a
high priority.
Edward
--
You received this message because you are subscribed to the Google
Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
