On Fri, Feb 27, 2009 at 11:56 AM, Edward K. Ream <[email protected]> wrote:
>
>
> On Thu, Feb 26, 2009 at 9:47 AM, Ville M. Vainio <[email protected]> wrote:
>>
>> On Thu, Feb 26, 2009 at 5:24 PM, Edward K. Ream <[email protected]>
>> wrote:
>>
>> > Ville, can you provide the link that you gave in your original post.
>> > I had intended to read it, and now I don't seem to be able to find it.
>>
>> http://ometer.com/free-software-ui.html
>>
>> And to recap, here's a particular quote that has stuck in mind:
>>
>> QQQ
>>
>> Preferences keep people from fixing real bugs. One of the more amusing
>> functions in GNU Emacs is "menu-bar-enable-clipboard." Now that KDE is
>> fixed, Emacs is basically the last remaining X application that
>> insists on having cut and paste that doesn't work correctly. So they
>> have this function "menu-bar-enable-clipboard" which basically means
>> "please make my cut and paste work correctly." Why is this an option?
>> I call this kind of preference the "unbreak my application please"
>> button. Just fix the app and be done with it.
>
> :-)  Let's hope we can keep such options to a minimum.
>
> I think the take-away message is that options are not an unalloyed
> blessing.  I don't think we are at the stage of options overload.  Feature
> overload, probably :-)
>
> What bothers me most is that Leo now has 9 (!) ways of managing external
> files.  True, most people will only use one or two or three of these, but
> this is a sign of something deep that isn't clean, namely sentinels.
>
> Oh, I wish there were a way to make .leo files into "project" files that
> would eliminate sentinels completely.  But 15 years of wishing hasn't
> produced a way that could possibly work.  Any ideas?

Heretical response::

As I understand it, sentinels are required to support a certain set of features,
features which are unique to Leo - clones, <<sections>> ...

Since these features are proprietary to Leo, users do not come
to Leo seeking them, they come to Leo for features they are familiar
with ... configurability, programability, the organizational capabilities of
@auto, @shadow ...

I propose a 2nd version of Leo, the current one would become something
like "Leo Enhanced", or "SuperLeo" and would be the tool of choice
for most Leo old timers.

A version with sentinel-requiring features removed would become
plain old "Leo" Only @auto @shadow @nosent @edit ... would be available.

It seems this could be done purely with configuration of menus,
settings, commands ...
If so, there would remain a single code base, two configurations.

I have no idea if this is feasible, but my sense is that, as Leo
emerges into the larger user community, the advantages
gained by abandoning sentinels would exceed the features sacrificed.

Thanks,
Kent


>
> Edward
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to