info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
You learn something every day...
16 views
Skip to first unread message
Skip Montanaro
Apr 12, 2018, 3:26:44 PM4/12/18
to Help GNU Emacs
I've been using some version of Emacs since 1981, when I installed
Gosling Emacs from a DECUS tape on VMS. (I had gotten used to a "full
screen" editor on the PR1ME computers we used at school, and
complained about what was effectively an ed(1)-style editor on VMS.
Not sure EDT was available yet.) So though I long ago stopped messing
with Emacs at the Lisp level other than to define some keys in my init
file, I have used many versions of Emacs, plumbed the depths of its
user interface and have tried any number of packages.
Still, there is always something new under the sun. Today I learned
about M-n and M-p in the minibuffer. I pass this along in case there
are any other Emacs users as apparently oblivious as I've been all
these years.
For the past couple days, I have been monitoring the logfile from an
uncooperative server process using occur to match and highlight
interesting bits. A simple keyboard macro looks like this:
* revisit the log file
* return to the top
* execute occur, accepting the default pattern
* scroll the *Occur* buffer to the end
* return point to the log file
This all goes swimmingly, unless I need to tweak the pattern or use
occur for some other task. The pattern grows and shrinks over time,
but basically looks like this:
subpat1 \| subpat2 \| ... \| subpatN
where N is generally five or less and the various subpatterns aren't
too complex, often just simple strings.
It was getting to be a royal PITA to have to retype the pattern from
scratch any time I wanted to alter it. As I went looking for how to
load the last regular expression into the minibuffer to edit it, I
stumbled on the Minibuf menu and its M-n and M-p bindings. I almost
*never* use the graphical menu (remember how long I've been using
Emacs, old habits die hard - I used to suppress it altogether as a
waste of screen space). I don't know what possessed me to glance at
the menu bar at just the right time, but that glance saved me a trip
down a deep, dark rabbit hole.
M-p-is-your-friend-ly, y'rs,
Skip
Yo, Adam...
Gosling Emacs from a DECUS tape on VMS. (I had gotten used to a "full
screen" editor on the PR1ME computers we used at school, and
complained about what was effectively an ed(1)-style editor on VMS.
Not sure EDT was available yet.) So though I long ago stopped messing
with Emacs at the Lisp level other than to define some keys in my init
file, I have used many versions of Emacs, plumbed the depths of its
user interface and have tried any number of packages.
Still, there is always something new under the sun. Today I learned
about M-n and M-p in the minibuffer. I pass this along in case there
are any other Emacs users as apparently oblivious as I've been all
these years.
For the past couple days, I have been monitoring the logfile from an
uncooperative server process using occur to match and highlight
interesting bits. A simple keyboard macro looks like this:
* revisit the log file
* return to the top
* execute occur, accepting the default pattern
* scroll the *Occur* buffer to the end
* return point to the log file
This all goes swimmingly, unless I need to tweak the pattern or use
occur for some other task. The pattern grows and shrinks over time,
but basically looks like this:
subpat1 \| subpat2 \| ... \| subpatN
where N is generally five or less and the various subpatterns aren't
too complex, often just simple strings.
It was getting to be a royal PITA to have to retype the pattern from
scratch any time I wanted to alter it. As I went looking for how to
load the last regular expression into the minibuffer to edit it, I
stumbled on the Minibuf menu and its M-n and M-p bindings. I almost
*never* use the graphical menu (remember how long I've been using
Emacs, old habits die hard - I used to suppress it altogether as a
waste of screen space). I don't know what possessed me to glance at
the menu bar at just the right time, but that glance saved me a trip
down a deep, dark rabbit hole.
M-p-is-your-friend-ly, y'rs,
Skip
Yo, Adam...
Loris Bennett
Apr 13, 2018, 2:17:48 AM4/13/18
to
was trying to access the history and realised that the arrows keys
weren't the way to go ...
However, being a relative newbie, having only used Emacs since the late
'80s, I have never come across the "Minibuf menu". What's that?
Cheers,
Loris
--
This signature is currently under construction.
Eli Zaretskii
Apr 13, 2018, 3:56:23 AM4/13/18
to help-gn...@gnu.org
> From: "Loris Bennett" <loris....@fu-berlin.de>
> Date: Fri, 13 Apr 2018 08:17:45 +0200
menu bar: you will find a "Minibuf" item there. Clicking it with the
mouse will show some minibuffer-related commands.
> Date: Fri, 13 Apr 2018 08:17:45 +0200
>
> However, being a relative newbie, having only used Emacs since the late
> '80s, I have never come across the "Minibuf menu". What's that?
Assuming you didn't disable the menu bar, type "M-x" and look at the
> However, being a relative newbie, having only used Emacs since the late
> '80s, I have never come across the "Minibuf menu". What's that?
menu bar: you will find a "Minibuf" item there. Clicking it with the
mouse will show some minibuffer-related commands.
Loris Bennett
Apr 13, 2018, 4:29:50 AM4/13/18
to
fairly subliminally (since I'm usually looking at the minibuffer at the
bottom of the screen while the "Minibuf" item is active at the top of
the screen).
I see that there is an menu item "Enter". Under what circumstances
might it be advantageous to use this rather than hitting the Enter key?
to...@tuxteam.de
Apr 13, 2018, 4:41:30 AM4/13/18
to help-gn...@gnu.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
There's a trick for that: just when you are in the minibuffer, type
C-h k ("describe-key") and then click on the menu point "enter".
You'll see that this menu entry is bound to (exit-minibuffer).
Likewise, if you "C-h k", then <ENTER>, you'll see that this is bound
to minibuffer-complete-and-exit.
Now I can't say what the exact difference is and why it is there,
but that's a way to start the research :-)
Cheers
- -- t
(quickly running away to not fall into *that* rabbit hole ;-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlrQbSsACgkQBcgs9XrR2kaGcACcC/76KITyqnlRReJFJRr5oGLS
uVwAnRjyQBCcX2Vn5M5JT/BLy84uLQlv
=IFwl
-----END PGP SIGNATURE-----
Hash: SHA1
C-h k ("describe-key") and then click on the menu point "enter".
You'll see that this menu entry is bound to (exit-minibuffer).
Likewise, if you "C-h k", then <ENTER>, you'll see that this is bound
to minibuffer-complete-and-exit.
Now I can't say what the exact difference is and why it is there,
but that's a way to start the research :-)
Cheers
- -- t
(quickly running away to not fall into *that* rabbit hole ;-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlrQbSsACgkQBcgs9XrR2kaGcACcC/76KITyqnlRReJFJRr5oGLS
uVwAnRjyQBCcX2Vn5M5JT/BLy84uLQlv
=IFwl
-----END PGP SIGNATURE-----
Eli Zaretskii
Apr 13, 2018, 4:57:53 AM4/13/18
to help-gn...@gnu.org
> From: "Loris Bennett" <loris....@fu-berlin.de>
> Date: Fri, 13 Apr 2018 10:29:47 +0200
invokes, you can see that if you use "C-h c" and then click that menu
item.
> Date: Fri, 13 Apr 2018 10:29:47 +0200
>
> I see that there is an menu item "Enter". Under what circumstances
> might it be advantageous to use this rather than hitting the Enter key?
That menu item invokes a command that is different from what RET
> I see that there is an menu item "Enter". Under what circumstances
> might it be advantageous to use this rather than hitting the Enter key?
invokes, you can see that if you use "C-h c" and then click that menu
item.
Eli Zaretskii
Apr 13, 2018, 4:58:49 AM4/13/18
to help-gn...@gnu.org
> Date: Fri, 13 Apr 2018 10:41:15 +0200
> From: <to...@tuxteam.de>
> From: <to...@tuxteam.de>
>
> There's a trick for that: just when you are in the minibuffer, type
> C-h k ("describe-key") and then click on the menu point "enter".
> You'll see that this menu entry is bound to (exit-minibuffer).
>
> Likewise, if you "C-h k", then <ENTER>, you'll see that this is bound
> to minibuffer-complete-and-exit.
>
> Now I can't say what the exact difference is and why it is there,
> but that's a way to start the research :-)
The completion part is the difference.
> There's a trick for that: just when you are in the minibuffer, type
> C-h k ("describe-key") and then click on the menu point "enter".
> You'll see that this menu entry is bound to (exit-minibuffer).
>
> Likewise, if you "C-h k", then <ENTER>, you'll see that this is bound
> to minibuffer-complete-and-exit.
>
> Now I can't say what the exact difference is and why it is there,
> but that's a way to start the research :-)
Marcin Borkowski
Apr 13, 2018, 10:42:38 AM4/13/18
to Skip Montanaro, Help GNU Emacs
On 2018-04-12, at 21:26, Skip Montanaro <skip.mo...@gmail.com> wrote:
> M-p-is-your-friend-ly, y'rs,
On a related note: yesterday I rediscovered M-n right after the command
expecting some minibuffer input (in this case, counsel-rg).
Best,
--
Marcin Borkowski
http://mbork.pl
Gene
Apr 15, 2018, 1:00:55 PM4/15/18
to
On Friday, April 13, 2018 at 4:29:50 AM UTC-4, Loris Bennett wrote:
> Eli Zaretski writes:
If I, for one, could have the minibuffer displayed at the TOP near the menu bar via a configuration option I WOULD.
It's annoying and time consuming to have to re-register one's focus back and forth from top to bottom.
How software engineers, developers, and users can manifest AWARENESS of the time wasted in removing one's hands from the keyboard -- to use a mouse or touch pad -- due to the time of re-acquiring finger positions on the keys BUT not extend this to visual re-acquisition when one is compelled to remove ones focus from something figural at the top XOR the bottom -- or NOT, having missed it entirely due to being too far out in the peripheries of one's visual field -- then having one's eyes having to make the return trip.
Hell, I don't think I'd mind having the mini-buffer appear atop the pull-down menu ... so long as the two could be juxtaposed side-by-side.
Optional socket-plug match-ups a bonus. (read supporting text below)
"Imagine ..." -- John Lennon
Imagine a minibuffer popping up beneath the menu bar.
Now imagine the ^ character being allowed in the character string one composes in the minibuffer.
Image this `^' character pointing to an item in the menu bar.
Imagine elisp code smart enough to make the correspondences between the pointed-to and referenced-from items and then `do something useful, informative, productive, or interesting'.
Just a few thoughts on Human-Computer interface design and visual ergonomics.
Cheers!
> Eli Zaretski writes:
>
>>> From: "Loris Bennett"
>>> Date: Fri, 13 Apr 2018 08:17:45 +0200
>>>
>>> However, being a relative newbie, having only used Emacs since the late
>>> '80s, I have never come across the "Minibuf menu". What's that?
>>
>> Assuming you didn't disable the menu bar, type "M-x" and look at the
>> menu bar: you will find a "Minibuf" item there. Clicking it with the
>> mouse will show some minibuffer-related commands.
>>> From: "Loris Bennett"
>>> Date: Fri, 13 Apr 2018 08:17:45 +0200
>>>
>>> However, being a relative newbie, having only used Emacs since the late
>>> '80s, I have never come across the "Minibuf menu". What's that?
>>
>> Assuming you didn't disable the menu bar, type "M-x" and look at the
>> menu bar: you will find a "Minibuf" item there. Clicking it with the
>> mouse will show some minibuffer-related commands.
> (since I'm usually looking at the minibuffer at the bottom of the screen
> while the "Minibuf" item is active at the top of the screen).
Which kinda sets one yearning to juxtapose BOTH side-by-side, one-over-the-other to facilitate noticing these two operationally related visuals, rather than having one's visual field divided by the WHOLE HEIGHT of the intervening buffer.
> while the "Minibuf" item is active at the top of the screen).
If I, for one, could have the minibuffer displayed at the TOP near the menu bar via a configuration option I WOULD.
It's annoying and time consuming to have to re-register one's focus back and forth from top to bottom.
How software engineers, developers, and users can manifest AWARENESS of the time wasted in removing one's hands from the keyboard -- to use a mouse or touch pad -- due to the time of re-acquiring finger positions on the keys BUT not extend this to visual re-acquisition when one is compelled to remove ones focus from something figural at the top XOR the bottom -- or NOT, having missed it entirely due to being too far out in the peripheries of one's visual field -- then having one's eyes having to make the return trip.
Hell, I don't think I'd mind having the mini-buffer appear atop the pull-down menu ... so long as the two could be juxtaposed side-by-side.
Optional socket-plug match-ups a bonus. (read supporting text below)
"Imagine ..." -- John Lennon
Imagine a minibuffer popping up beneath the menu bar.
Now imagine the ^ character being allowed in the character string one composes in the minibuffer.
Image this `^' character pointing to an item in the menu bar.
Imagine elisp code smart enough to make the correspondences between the pointed-to and referenced-from items and then `do something useful, informative, productive, or interesting'.
Just a few thoughts on Human-Computer interface design and visual ergonomics.
Cheers!
Eli Zaretskii
Apr 15, 2018, 1:16:02 PM4/15/18
to help-gn...@gnu.org
> Date: Sun, 15 Apr 2018 10:00:53 -0700 (PDT)
> From: Gene <gene.s...@gmail.com>
However, IME nothing in Emacs gets done until motivated individual(s)
step(s) forward to implement the thoughts and ideas that seem worthy.
In this case, some real code changes will be needed, because the
assumption that the minibuffer is at the bottom is hard-coded into
Emacs on the C level.
Patches to allow this to be customizable will be very welcome. I hope
someone will feel interested enough to sit down and do it.
> From: Gene <gene.s...@gmail.com>
>
> Just a few thoughts on Human-Computer interface design and visual ergonomics.
Thanks.
> Just a few thoughts on Human-Computer interface design and visual ergonomics.
However, IME nothing in Emacs gets done until motivated individual(s)
step(s) forward to implement the thoughts and ideas that seem worthy.
In this case, some real code changes will be needed, because the
assumption that the minibuffer is at the bottom is hard-coded into
Emacs on the C level.
Patches to allow this to be customizable will be very welcome. I hope
someone will feel interested enough to sit down and do it.
Skip Montanaro
Apr 15, 2018, 5:49:01 PM4/15/18
to Gene, Help GNU Emacs
> If I, for one, could have the minibuffer displayed at the TOP near the menu bar via a configuration option I WOULD.
I wonder if minibuffer-frame-alist or default-frame-alist could be
coaxed into defining the layout as you desire. The default value for
all the *-frame-alist variables) is nil. A quick mess around with
minibuffer-frame-alist didn't yield any useful results. Probably need
to poke around frame.el to see how it works (and maybe frame.c).
Skip
0 new messages