Re: [Nano-devel] [poll] which features would you like to see in nano?

Trevor Brown <[email protected]> Sun, 12 Jul 2015 07:27:12 -0600
Newsgroups gmane.editors.nano.announce
Message-ID <CAM7n+D=TmoWd6KzZsNoWwfVc1107gvK4GDFdn+ERaq9dYQ=8Uw__37324.8858530589$1436714253$gmane$org@mail.gmail.com>
--===============5490618482684320594==
Content-Type: multipart/alternative; boundary=089e0149bbb0109560051aad904a

--089e0149bbb0109560051aad904a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 26 June 2015 at 03:20, Benno Schulenberg <[email protected]> wrote:

>
> On Fri, Jun 26, 2015, at 06:59, Eitan Adler wrote:
> > On 21 June 2015 at 03:28, Benno Schulenberg <[email protected]>
> wrote:
> > > c)  Find next occurrence backward / find next occurrence forward.
> > > (So you don't have to toggle the search direction with ^W M-B first.)
> >
> > +0 I have no opinion on this other than to be concerned about an
> > explosion of complexity.
>
> I understand.  It's just something that I really would like to have.
> All other command-line editors have a find-forward and find-backward.
> What nano has feels like what graphical editors have: check boxes that
> one can click to toggle Direction, Case Sensitivity and Regular
> Expressions.
>
> An alternative would be to have a bindable WhereWas function: the same as
> WhereIs but with the Backward direction toggled always on.
>

+1 for this. I can't tell you how many times I've wanted to be able to use
both while searching without having to toggle an option.


>
> > > d)  Save the current file without any prompting (if it has a name).
> >
> > +1.  I'd also be okay with this being an option to default save to the
> > same name as previously asked.
>
> Hm.  The option you're suggesting is how --tempfile should behave,
> but it doesn't.  In Pico the -t option will save the file straightaway
> upon a ^O or ^X.  But nano will do that only for the latter.  (Bug
> has been filed as https://savannah.gnu.org/bugs/index.php?45415.)
>
> > > e)  An option to consider underscores to be part of a word.
> >
> > -1 as is.  I'd be +0 if it were "an option to list characters to be
> > considered part of a word".  In particular I don't like how specific
> > this option is.
>
> You're right, it was too specific.  And being able to define which
> characters should also be considered parts of words nicely fits
> with nano's other options like 'set brackets' and 'set punct'.
>

+1 in this form, especially when programming


>
> By the way, Pico always considers hyphens and underscores to be
> parts of words (but also all brackets and other things, which is
> not good).  So we could also consider nano's current behaviour
> as a bug.  The -W (--wordbounds) option makes nano behave more
> like Pico, but worse: it will also put the cursor on an opening
> bracket, something that Pico never does.
>
> Thanks for the detailed response.
>
> Benno
>
> --
> http://www.fastmail.com - Access all of your messages and folders
>                           wherever you are
>
>
> _______________________________________________
> Nano-devel mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/nano-devel
>
>


--=20
Mit freundlichen Gr=C3=BC=C3=9Fen and 73s,
Trevor Brown
KE7RTO

--089e0149bbb0109560051aad904a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 26 June 2015 at 03:20, Benno Schulenberg <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:[email protected]" target=3D"_blank">[email protected]=
et</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""=
><br>
On Fri, Jun 26, 2015, at 06:59, Eitan Adler wrote:<br>
&gt; On 21 June 2015 at 03:28, Benno Schulenberg &lt;<a href=3D"mailto:bens=
[email protected]">[email protected]</a>&gt; wrote:<br>
</span><span class=3D"">&gt; &gt; c)=C2=A0 Find next occurrence backward / =
find next occurrence forward.<br>
&gt; &gt; (So you don&#39;t have to toggle the search direction with ^W M-B=
 first.)<br>
&gt;<br>
&gt; +0 I have no opinion on this other than to be concerned about an<br>
&gt; explosion of complexity.<br>
<br>
</span>I understand.=C2=A0 It&#39;s just something that I really would like=
 to have.<br>
All other command-line editors have a find-forward and find-backward.<br>
What nano has feels like what graphical editors have: check boxes that<br>
one can click to toggle Direction, Case Sensitivity and Regular Expressions=
.<br>
<br>
An alternative would be to have a bindable WhereWas function: the same as<b=
r>
WhereIs but with the Backward direction toggled always on.<br></blockquote>=
<div><br></div><div>+1 for this. I can&#39;t tell you how many times I&#39;=
ve wanted to be able to use both while searching without having to toggle a=
n option.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D""><br>
&gt; &gt; d)=C2=A0 Save the current file without any prompting (if it has a=
 name).<br>
&gt;<br>
&gt; +1.=C2=A0 I&#39;d also be okay with this being an option to default sa=
ve to the<br>
&gt; same name as previously asked.<br>
<br>
</span>Hm.=C2=A0 The option you&#39;re suggesting is how --tempfile should =
behave,<br>
but it doesn&#39;t.=C2=A0 In Pico the -t option will save the file straight=
away<br>
upon a ^O or ^X.=C2=A0 But nano will do that only for the latter.=C2=A0 (Bu=
g<br>
has been filed as <a href=3D"https://savannah.gnu.org/bugs/index.php?45415"=
 rel=3D"noreferrer" target=3D"_blank">https://savannah.gnu.org/bugs/index.p=
hp?45415</a>.)<br>
<span class=3D""><br>
&gt; &gt; e)=C2=A0 An option to consider underscores to be part of a word.<=
br>
&gt;<br>
&gt; -1 as is.=C2=A0 I&#39;d be +0 if it were &quot;an option to list chara=
cters to be<br>
&gt; considered part of a word&quot;.=C2=A0 In particular I don&#39;t like =
how specific<br>
&gt; this option is.<br>
<br>
</span>You&#39;re right, it was too specific.=C2=A0 And being able to defin=
e which<br>
characters should also be considered parts of words nicely fits<br>
with nano&#39;s other options like &#39;set brackets&#39; and &#39;set punc=
t&#39;.<br></blockquote><div><br></div><div>+1 in this form, especially whe=
n programming</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
By the way, Pico always considers hyphens and underscores to be<br>
parts of words (but also all brackets and other things, which is<br>
not good).=C2=A0 So we could also consider nano&#39;s current behaviour<br>
as a bug.=C2=A0 The -W (--wordbounds) option makes nano behave more<br>
like Pico, but worse: it will also put the cursor on an opening<br>
bracket, something that Pico never does.<br>
<br>
Thanks for the detailed response.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Benno<br>
<br>
--<br>
<a href=3D"http://www.fastmail.com" rel=3D"noreferrer" target=3D"_blank">ht=
tp://www.fastmail.com</a> - Access all of your messages and folders<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 wherever you are<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
_______________________________________________<br>
Nano-devel mailing list<br>
<a href=3D"mailto:[email protected]">[email protected]</a><br>
<a href=3D"https://lists.gnu.org/mailman/listinfo/nano-devel" rel=3D"norefe=
rrer" target=3D"_blank">https://lists.gnu.org/mailman/listinfo/nano-devel</=
a><br>
<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature">Mit freundlichen Gr=C3=BC=C3=9Fen and 73s,<b=
r>Trevor Brown<br>KE7RTO</div>
</div></div>

--089e0149bbb0109560051aad904a--


--===============5490618482684320594==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Info-nano mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/info-nano

--===============5490618482684320594==--