|From:||Richard Kolb II|
|Subject:||Re: [Nano-devel] RFC: the content and aspect of the help lines|
|Date:||Mon, 17 Mar 2014 11:23:17 -0400|
On 3/16/14, Benno Schulenberg <address@hidden> wrote:
> On Tue, Mar 4, 2014, at 20:38, Chris Allegretta wrote:
>> On 3/4/14, Benno Schulenberg <address@hidden> wrote:
>> > The other thing is that the default help lines contain the ^Y and ^V
>> > shortcuts for PageUp and PageDown. I doubt that anyone uses these
>> > key combos -- every keyboard has PageUp and PageDown keys, which work
>> I use these keys (^Y/^V) exclusively. I think someone who wants to do
>> a more advanced function and cant remember the commands should be able
>> to look in the help menu.
> I agree that more advanced and seldom-used functions are material
> that should be looked up in a help text. The help lines should show
> commands that are absolutely necessary to operate the program
> (like ^G and ^X and ^O), that are well-nigh indispensable (like ^W
> and ^K and ^U), and then... well, things that are useful and cannot
> be done in another way. The help lines don't show ^A and ^E either,
> most likely because most people will use Home and End, so why ^Y
> and ^V? Also, as soon as you do a ^G, then ^Y and ^V will be right
> there in the help lines -- anyone with a little sense will guess that
> they will most likely work in the editor itself too.
I understand what you mean, and I really didn't give all rationales
for why things are the way they are today.
One thing I think we need to do /by default/ is look a lot like Pico's
default presentation. If we start straying too from it we risk not
being considered a drop in replacement for Pico and e.g. cease being
some distros' /usr/bin/pico. I realize newer users care less about
that, but of course I still invoke nano as 'pico' all the time. I
assume there are oldbies who do that as well.
I think there is a good argument to be made for e.g. why we don't
start using -O by default. In general though I want to err in the
side of, by default, appearing very similar visually to Pico, since we
have many ways to extend the functionality we have. Take the
search/replace history editing as an example: by default the behavior
very similar to Pico in terms of interacting with the editor, yet we
are able to offer extra functionality by using keys pico previously
did not. Your proposal for keeping the normal shortcut count and
width at 80 columns, but with higher col displays offer something
more, is another great example of this.
>> I am attempting to make ^T more useful with the most recent changes.
>> I think it'd be a shame to hide that work.
> I understand, but it kind of contradicts what you said above, about
> looking up advanced functions in a help text. :)
On that topic: nano's default usage was as an email editor. Having a
spell checker as a default menu option does make sense in that regard.
Since spelling is only useful in that case though, I think it makes
sense to re-purpose that ability based on context. I feel like this
is not inconsistent with nano's MO as mentioned above, but I am
interested in hearing opinions from our users about what they think
about this topic.
Unfortunately as I think you've noticed already it's rather difficult
to get feedback from folks as it seems like we have a very silent
majority who seem happy with what is offered, so sometimes you have do
have to make decisions blindly. I can start asking our Twitter
followers what they think also - does anyone have a preferred polling
software for the web which is Free Software? I think my default
position has been rather conservative on new changes, but if folks are
ok with this I think we can make some visual appearance changes in the
unstable series and gather feedback in the next stable series cycle. I
think even despite our best efforts to communicate them, people can
react negatively to what seem like minor changes.
Nano-devel mailing list
|[Prev in Thread]||Current Thread||[Next in Thread]|