nano-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] Re: sample Python regexes, revisited


From: David Lawrence Ramsey
Subject: Re: [Nano-devel] Re: sample Python regexes, revisited
Date: Mon, 03 Apr 2006 10:42:53 -0400
User-agent: Thunderbird 1.5 (X11/20051201)

John M. Gabriele wrote:

<snip>

>> In the meantime, I'll try to help you get Alt-Space working.
>
> Very good.

<snip>

> Debian Etch (and Sid) with IceWM and xterm. Same thing happens with aterm.
> Same thing with left Alt as with right Alt. Here's some xev output from
> hitting Alt-Space (first left Alt, then right).
>
> KeyPress event, serial 30, synthetic NO, window 0x1600001,
>     root 0x4c, subw 0x0, time 14054305, (1221,-259), root:(1227,732),
>     state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
>     XLookupString gives 0 bytes:
>     XmbLookupString gives 0 bytes:
>     XFilterEvent returns: False
>
> FocusOut event, serial 30, synthetic NO, window 0x1600001,
>     mode NotifyGrab, detail NotifyAncestor
>
> [then that window X11 window menu pops up. When I get rid of it: ]
>
> FocusIn event, serial 30, synthetic NO, window 0x1600001,
>     mode NotifyUngrab, detail NotifyNonlinear
>
> KeymapNotify event, serial 30, synthetic NO, window 0x0,
> keys: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>
>
>
> KeyPress event, serial 30, synthetic NO, window 0x1600001,
>     root 0x4c, subw 0x0, time 14090915, (877,-460), root:(883,531),
>     state 0x0, keycode 113 (keysym 0xffea, Alt_R), same_screen YES,
>     XLookupString gives 0 bytes:
>     XmbLookupString gives 0 bytes:
>     XFilterEvent returns: False
>
> FocusOut event, serial 30, synthetic NO, window 0x1600001,
>     mode NotifyGrab, detail NotifyAncestor
>
> [same X11 window menu. Then, ]
>
> FocusIn event, serial 30, synthetic NO, window 0x1600001,
>     mode NotifyUngrab, detail NotifyNonlinear
>
> KeymapNotify event, serial 30, synthetic NO, window 0x0,
> keys: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>
>
> Funny... I'm not seeing any
>
> KeyPress event, serial 30, synthetic NO, window 0x1600001,
>     root 0x4c, subw 0x0, time 17099918, (1429,-25), root:(1435,966),
>     state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
>     XLookupString gives 1 bytes: (20) " "
>     XmbLookupString gives 1 bytes: (20) " "
>     XFilterEvent returns: False
>
> KeyRelease event, serial 30, synthetic NO, window 0x1600001,
>     root 0x4c, subw 0x0, time 17100046, (1429,-25), root:(1435,966),
>     state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
>     XLookupString gives 1 bytes: (20) " "
>
> in there. Does anyone else have the Alt-Space problem?

I think I know what the problem is.  See below.

<snip>

>>> - nano doesn't have an undo.
>> The rewrite will have this.
>
> Very good.

Be warned, though: the rewrite will take a while to get all of nano
1.4's features, much less stabilize on its own.  See these threads in
the mailing list archives for more info:

http://lists.gnu.org/archive/html/nano-devel/2005-12/msg00003.html
http://lists.gnu.org/archive/html/nano-devel/2006-01/msg00014.html
http://lists.gnu.org/archive/html/nano-devel/2006-02/msg00007.html

<snip>

>> but some terminals can't tell the difference between an arrow key and
>> Ctrl-[arrow key].
>
> Gah!

"Gah" indeed.  And that's not even the worst of it.  See below.

<snip>

>> Thanks again.  It's in the changelog.  By the way, your nano page is
>> very well done.
>
> Thanks!

No problem.

>> Three suggestions: you might want to add something like
>>
>> "cut to end of file    Alt-t"
>
> I didn't put that one in because I never had a use for it.
> It doesn't seem very often that someone would need to do that,
> so I left it out (after all, nano has pretty good online help
> for options that you forget the key-combos to).

Okay then.

>> to the "Selecting/Cutting/Copying/Pasting" section, you might want to
>> change the "search/replace" key entry to "Ctrl-\ (or Alt-r)" in the
>> "Searching" section,
>
> As an aside, I'm not too fond of using *both* the Ctrl key and the
> Alt key for various commands. I tend to mix them up. :) Personally,
> I'm happier if everything is accessible via Ctrl, so I'm hesitant
> to present and try to remember the Alt equivalents unless they're
> much more helpful (as in, using Alt-w instead of Ctrl-w Enter to
> "find again").
>
> I mean, either you memorize Ctrl-\ as being search an replace, or
> else you memorize the difference between Alt-r and Ctrl-r. I'd
> rather just stick with the former without getting Alt into the mix.
> Just my opinion anyhow. The emacs users in the crowd may
> disagree. :)

The problem is in the other limitation of text mode, namely, there are
only 33 control characters: Ctrl-@, Ctrl-A through Z, Ctrl-[, Ctrl-\,
Ctrl-], Ctrl-^, Ctrl-_, and Ctrl-?.  (Technically, if you count the
high-bit versions of them, except for Ctrl-?, there are 65, but since
you'd have to turn 8-bit input back on and use Ctrl-Alt to get them, I'm
not considering them control keys here.)  There are certain aliases for
them (e.g. Ctrl-` is an alias for Ctrl-@), but there's no way to add any
more without breaking the limitations of terminals.

Back when the multibuffer support was first being added, the original
suggestion for the keystrokes to switch between buffers was Ctrl-< and
Ctrl->, but they didn't generate any control characters, so Alt-< and
Alt-> had to be used instead.  Using the Alt key, or should I say, the
Meta key, doesn't have this limitation because it's equivalent to
putting Escape in front of a key, and you can do that with any key.  On
the other hand, some of the few control characters available are
reserved.  Ctrl-] is equivalent to Escape, and Ctrl-? is equivalent to
either Delete or Backspace, depending on whether the terminal is VT100-
or VT220-based.  In any case, the only control character that is not
currently used is Ctrl-[, mainly because I can't think of an intuitive
use for it (and no, I don't want to change the bracket match searching
key to it).  And the only Meta letter sequences that are not currently
used are Meta-U and Meta-E, because I'd like to reserve them for Undo
and Redo when they're implemented.

>> and if/when we can work out your Alt-Space problem,
>> you might want to mention the solution to it there.
>
> Sure. Although I'm not using nano for anything at the moment, I've
> re-subscribed to this list for now, so if you come up with a solution,
> just post about it and I'll update my page.

From what I've been able to find out (I don't use icewm), it appears
that icewm overrides that particular key to show the window menu. According to

http://users.tkk.fi/~tkarvine/linux/doc/icewm/preferences

, the icewm preferences file should have a line like

KeyWinMenu="Alt+Space"

in it, which will need to be changed if you want to use Alt-Space for
something else.

>>> Now,.. about the Ruby patterns... ;)
>> Argh...
>
> Well, you've already got one for Perl and for Python,... :)

True, but Ruby's another language I don't write in, plus I don't think
I've ever seen a Ruby source file.  I've at least seen Perl and Python
source files, although I never looked at the latter in detail until I
fixed the triple-quoted string coloring.  If there's another attempt at
it on the web that you can point me toward, though... ;)

> BTW, are the regexes that go into the nanorc PCRE? An older
> sed style? Something else? You might mention something in the
> nanorc man page about them.

They're extended regular expressions, as opposed to basic.  In other
words, they're the kind of expressions that work with egrep (grep -E) as
opposed to plain grep.  But you're right, that should be mentioned, if
not in the nanorc manpage, somewhere prominent.

> Hm... I seem to recall asking about where you preferred
> docs on the nanorc to go: into the sample nanorc, or the
> man page. Which do you favor?

In the case of non-escaped quotes, both.  It's important enough that I
don't mind the redundancy in this case.

>> Good luck.  Sorry that some nano inconveniences led you to switch to the
>> dark side ;) although I hope that the nano rewrite will eventually pull
>> you back.
>
> Oooh, well, as long as you're looking to pull me back, :) I've
> got one more feature request: find previous. Possibly, when you
> hit Ctrl-w to find the next occurrence, have an option there to
> hit Ctrl-w again or something (just like how you can hit Ctrl-c
> to cancel the search) to go back to the previous search result.
>
> Hmm... weird. Currently, Ctr-w Ctrl-w moves me up-by-paragraph,
> just like Alt-9. (!) So, maybe that makes it a good candidate
> for find-previous?

That's one of Pico's odder keystrokes.  Ctrl-W at the search prompt
moves you to the previous paragraph.  What it's doing in the search menu
when it's clearly a movement function and not a search function per se
is beyond me.  The help at the search prompt should show you the rest;
it's the only place other than the main window where not all keystrokes
are shown at the bottom of the screen.

As for finding the previous search, if you're pressing Ctrl-W again, why
don't you just press Alt-B to toggle backwards searching before you
press Enter again?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]