Discussion:
26.1-rc1: global-set-key suggestions
Van Ly
2018-04-29 01:03:42 UTC
Permalink
Hello.

I'd like to suggest the following improvement to the out-of-the-box
behaviour on apple-darwin, NS appkit :-

;;
;; Allow Command-Plus-or-Minus to text-scale fontsize.
;;

(global-set-key (kbd "s-+") #'text-scale-increase)
(global-set-key (kbd "s-=") #'text-scale-increase)
(global-set-key (kbd "s--") #'text-scale-decrease)

Van L
ⓔ ***@scratch.space
Eli Zaretskii
2018-04-29 02:43:59 UTC
Permalink
Date: Sat, 28 Apr 2018 21:03:42 -0400
I'd like to suggest the following improvement to the out-of-the-box
behaviour on apple-darwin, NS appkit :-
;;
;; Allow Command-Plus-or-Minus to text-scale fontsize.
;;
(global-set-key (kbd "s-+") #'text-scale-increase)
(global-set-key (kbd "s-=") #'text-scale-increase)
(global-set-key (kbd "s--") #'text-scale-decrease)
Why not the C-+ etc. bindings used on the other platforms?
Van L
2018-04-29 03:14:56 UTC
Permalink
Post by Eli Zaretskii
From: Van L
I'd like to suggest the following improvement to the out-of-the-box
behaviour on apple-darwin, NS appkit :-
;;
;; Allow Command-Plus-or-Minus to text-scale fontsize.
;;
(global-set-key (kbd "s-+") #'text-scale-increase)
(global-set-key (kbd "s-=") #'text-scale-increase)
(global-set-key (kbd "s--") #'text-scale-decrease)
Why not the C-+ etc. bindings used on the other platforms?
The bindings for font size change are :-

C-x C-+
C-x C--

Going native and being consistent with other apps on the platform is a pleasant experience; and, for beginners, it makes plain and simple sense, at least until, they've done the tutorial and have tried `M-x customize'.

Being unable to naïvely change the fontsize means the beginner has to endure the struggle of reading the wrong sized font for them initially. Or, every beginner has to hit a search engine to discover how to make the change for themselves.

Lastly, the Command-Plus-or-Minus is a simple two finger combination press which is easier to type than the C-x separately followed by C-plus-or-minus. Other native platform keybindings are already there out of the box, such as, Command-W.

--
Van L
Bastien
2018-04-29 10:49:57 UTC
Permalink
Hi,
Post by Van L
The bindings for font size change are :-
C-x C-+
C-x C--
I interactively change the text size often enough to use these custom
keybindings:

(global-set-key (kbd "C-+") 'text-scale-increase)
(global-set-key (kbd "C--") 'text-scale-decrease)
(global-set-key (kbd "C-=") 'text-scale-adjust)

which is what I also use in other applications (e.g. Firefox) on a
GNU/Linux machine. I thought C-+/- was pretty standard.

C-+ and C-= are free in Emacs, but C-- is not, emulating C-u -, but
I don't really mind having to type C-u - instead of C-- when I need.

2 cents,
--
Bastien
Alan Third
2018-04-29 20:34:35 UTC
Permalink
Post by Bastien
I interactively change the text size often enough to use these custom
(global-set-key (kbd "C-+") 'text-scale-increase)
(global-set-key (kbd "C--") 'text-scale-decrease)
(global-set-key (kbd "C-=") 'text-scale-adjust)
which is what I also use in other applications (e.g. Firefox) on a
GNU/Linux machine. I thought C-+/- was pretty standard.
MacOS commonly replaces C-X commands on other platforms with s-X.
Amusingly it means you get both emacs style bindings (e.g. C-a to move
to start of line) alongside CUA type bindings (e.g. s-a to select
all).
Post by Bastien
C-+ and C-= are free in Emacs, but C-- is not, emulating C-u -, but
I don't really mind having to type C-u - instead of C-- when I need.
Looks like the macOS super bindings will interfere with s--, which is
bound to center-line. center-line is also bound to M-o M-s, so I don’t
think that losing the s-- binding would be a huge problem.

This sounds like a good change, too late for Emacs 26, though.
--
Alan Third
Van L
2018-04-30 12:07:13 UTC
Permalink
Hello.
Post by Bastien
(global-set-key (kbd "C-=") 'text-scale-adjust)
Thanks. I like that. I'll use that on my personal "s-=" mapping.

Is there an equally quick way to set permanently the zoomed fontsize? to store in Default's height :-

- M-x customize
+ Faces
+ Basic Faces
+ Default
+ Height

Beyond Emacs 26, having Default's Foreground/Background set colors according to time of day or level of ambient lighting is nice to have. For example, a totally black background reverse video effect is preferable when almost all the lights are off. A behavior that appropriately sets an inversely related foreground color given a slide in background color ranging from gray100 to gray0 would do.
Post by Bastien
2 cents,
Thanks are also owing to siraben who is behind the push to modernise bignum in calc.el.

The three liner at the start of this thread came from siraben. Thanks siraben.
Radon Rosborough
2018-04-29 16:38:43 UTC
Permalink
Post by Van L
Going native and being consistent with other apps on the platform is a pleasant experience;
Absolutely 100% agreed. Binding s-+, s-=, s-- would be an unambiguous
improvement in user experience on macOS with no downsides that I can
see. In fact, I may do this now in my personal configuration.

Binding C-+ etc. instead would be a mistake, at least on macOS.
Clément Pit-Claudel
2018-04-29 21:07:20 UTC
Permalink
Post by Van Ly
Hello.
I'd like to suggest the following improvement to the out-of-the-box
behaviour on apple-darwin, NS appkit
    (global-set-key (kbd "s-+") #'text-scale-increase)
    (global-set-key (kbd "s-=") #'text-scale-increase)
    (global-set-key (kbd "s--") #'text-scale-decrease)
I'd prefer binding these to a function that changes the font size on the whole frame, rather than just the current buffer.
Drew Adams
2018-04-29 21:50:56 UTC
Permalink
Post by Clément Pit-Claudel
Post by Van Ly
    (global-set-key (kbd "s-+") #'text-scale-increase)
    (global-set-key (kbd "s-=") #'text-scale-increase)
    (global-set-key (kbd "s--") #'text-scale-decrease)
I'd prefer binding these to a function that changes the font size on the
whole frame, rather than just the current buffer.
See `zoom-frm-in' and `zoom-frm-out', in `zoom-frm.el'.

Or `zoom-in' and `zoom-out' (same library), which you
can use for both frame zooming and buffer zooming.

,----
| zoom-in is an interactive compiled Lisp function.
|
| It is bound to S-mouse-1, C-wheel-up.
|
| (zoom-in ARG)
|
| Zoom current frame or buffer in.
| With a prefix arg, toggle between zooming frame and zooming buffer.
| Frame zooming uses command ‘zoom-frm-in’.
| Buffer zooming uses command ‘text-scale-increase’.
`----

https://www.emacswiki.org/emacs/download/zoom-frm.el
Alan Third
2018-05-13 13:35:23 UTC
Permalink
Post by Clément Pit-Claudel
I'd prefer binding these to a function that changes the font size on
the whole frame, rather than just the current buffer.
https://github.com/siraben/dotfiles/blob/master/emacs/.emacs.d/modules/siraben-fonts.el
Specifically, this is done by using `set-frame-font' which means elements
such as the mode line are enlarged as well. Note that I am binding the font
size changes to C-+, C-- and C-=, but it could easily be done with s-+, s--
and s-= respectively.
I don't see any conflicting key bindings with macOS. What are other
maintainers' thoughts on this?
I’m no longer sure if we’re talking about just binding these keys on
the NS port or generally, but if it’s just the NS port then I have no
problem with either option. Resizing everything seems to match up most
closely with the other apps I use, but I’m not a heavy user of macOS
specific apps, so I can’t say whether it would be expected behaviour
or not.
--
Alan Third
Tim Cross
2018-05-13 22:09:36 UTC
Permalink
Just to add another perspective....

I use Emacs on macOS at work and on GNU Linux at home. So for me, one of
the great things about Emacs was/is consistency in key bindings across
platforms. If we start making bindings different depending on the platform,
then you lose that level of consistency.

As this is Emacs, this is not a huge issue as it is easy enough to set them
to whatever I want, but thought I'd just mention that making bindings
platform dependent may have a downside for those who work in Emacs from
different platforms.

Tim

P.S. I've been using Emacs for so long, I tend to change the OS bindings to
match with Emacs rather than the other way round. Unfortunately, unlike GNU
Linux, macOS does not offer the same level of flexibility in this area
Post by Clément Pit-Claudel
I'd prefer binding these to a function that changes the font size on
the whole frame, rather than just the current buffer.
https://github.com/siraben/dotfiles/blob/master/emacs/.
emacs.d/modules/siraben-fonts.el
Specifically, this is done by using `set-frame-font' which means elements
such as the mode line are enlarged as well. Note that I am binding the
font
size changes to C-+, C-- and C-=, but it could easily be done with s-+,
s--
and s-= respectively.
I don't see any conflicting key bindings with macOS. What are other
maintainers' thoughts on this?
I’m no longer sure if we’re talking about just binding these keys on
the NS port or generally, but if it’s just the NS port then I have no
problem with either option. Resizing everything seems to match up most
closely with the other apps I use, but I’m not a heavy user of macOS
specific apps, so I can’t say whether it would be expected behaviour
or not.
--
Alan Third
--
regards,

Tim

--
Tim Cross
Stefan Monnier
2018-05-14 04:30:28 UTC
Permalink
Post by Tim Cross
As this is Emacs, this is not a huge issue as it is easy enough to set them
to whatever I want, but thought I'd just mention that making bindings
platform dependent may have a downside for those who work in Emacs from
different platforms.
Indeed, there's a tension in this respect. Ideally, we should provide
sets of customizations which better integrates Emacs into various OSes,
which users can then choose to enable or not.

A kind of "custom-theme" for that would be great, but currently
custom-themes don't work well for that since they can't really provide
key-bindings.


Stefan
Van L
2018-05-14 06:49:08 UTC
Permalink
Post by Stefan Monnier
A kind of "custom-theme" for that would be great, but currently
custom-themes don't work well for that since they can't really provide
key-bindings.
There could be money to be made selling the perfect Emacs physical keyboard with key-binding-themes included, like those stealthy gamer’s keyboards but for programmers and readers.

I switch between the smaller Apple keyboard and fullsize Thinkpad keyboard, both are without the numpad, and I really dislike:

1. typing C-x ; smallest left finger on `caps lock’ ; middle finger on x

2. the four extremely tiny arrow keys and the inverted T configuration
j***@verona.se
2018-05-14 09:12:57 UTC
Permalink
Post by Van L
Post by Stefan Monnier
A kind of "custom-theme" for that would be great, but currently
custom-themes don't work well for that since they can't really provide
key-bindings.
There could be money to be made selling the perfect Emacs physical keyboard with key-binding-themes included, like those stealthy gamer’s keyboards but for programmers and readers.
I find the ergodox good for this.

https://gitlab.com/jave/jv-ergodox

The repo contains a fork of Ergodox firmware, and some elisp to generate
new firmware with new emacs oriented keyboard layouts.
Post by Van L
1. typing C-x ; smallest left finger on `caps lock’ ; middle finger on x
2. the four extremely tiny arrow keys and the inverted T configuration
--
Joakim Verona
***@verona.se
+46705459454
Van L
2018-05-14 11:35:03 UTC
Permalink
Post by j***@verona.se
I find the ergodox good for this.
https://gitlab.com/jave/jv-ergodox
The repo contains a fork of Ergodox firmware, and some elisp to generate
new firmware with new emacs oriented keyboard layouts.
I’d like a dedicated Emacs variant of Vortex Race 3 in color with:

- bottom left fn-key does C-x
- four normal sized oneline of keys right of Spacebar for arrows
- dedicated forward/backward keys for
+ pages
+ paragraphs
+ sentences
+ words
+ characters
- dedicated top/bottom key for programming like begin/end of function goto

ergodox.org doesn’t but ergodox.io does get to a page
Yuri Khan
2018-05-14 12:02:38 UTC
Permalink
I’d like a dedicated Emacs variant of Vortex Race 3 […]
You know you could realistically build one from parts and it would cost not
much over retail price?
Van L
2018-05-15 02:46:07 UTC
Permalink
Post by Yuri Khan
I’d like a dedicated Emacs variant of Vortex Race 3 […]
You know you could realistically build one from parts and it would cost not
much over retail price?
How about a dedicated Emacs mini keypad the size of 13⨯21cm - 5⨯8¼ paper? designed by Moleskine® in Italy, set at the retail price of a mouse and placed diagonally from the top corner of a conventional keyboard.
Richard Stallman
2018-05-14 12:58:27 UTC
Permalink
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Post by Tim Cross
I use Emacs on macOS at work and on GNU Linux at home. So for me, one of
the great things about Emacs was/is consistency in key bindings across
platforms. If we start making bindings different depending on the platform,
then you lose that level of consistency.
I agree.
--
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.
Alan Third
2018-05-15 18:30:36 UTC
Permalink
Post by Tim Cross
Just to add another perspective....
I use Emacs on macOS at work and on GNU Linux at home. So for me, one of
the great things about Emacs was/is consistency in key bindings across
platforms. If we start making bindings different depending on the platform,
then you lose that level of consistency.
The NS port already has over 40 ‘NS‐like’ bindings and has done since
it was merged in ten years ago.
--
Alan Third
Loading...