2 added 587 characters in body
source | link

That script from the Arch Wiki

This invocation of emacs that checks (fboundp 'tool-bar-mode) is testing whether your build of Emacs includes GUI support. It's possible to build Emacs without it to save a little bit of RAM and disk space¹, but it's uncommon. Unless you care about compatibility with Emacs builds that lack GUI support, forget about this bit.

You are thus left with

if [ -n "$DISPLAY" ]; then
  emacsclient -a "" -n -c "$@"
else
  emacsclient -a "" "$@"
fi

And even that level of complexity is necessary only if you want to have the call to emacsclient return immediately if it opens a new GUI window. (If it's running in the terminal, then it has to keep running until you finish using that terminal.) It's up to you to decide whether you like this behavior. If you don't then you can simply run

emacsclient -a "" "$@"

And if you start Emacs with your session anyway, e.g. as a systemd unit, then you don't need to tell emacsclient to start it. So we're left with

emacsclient "$@"

which I cannot simplify further.

Your added requirement

  • stay in the terminal (…) if called with a file (…) or when graphical environment isn't present (…)
  • open a GUI window when called without a file (…) and return immediately

For that you need to test whether the script was called with arguments. I'm going to assume that if you pass any emacsclient option (e.g. --eval), that counts as an argument.

if [ $# -ne 0 ]; then
  emacsclient -nw "$@"
elif [ -n "$DISPLAY" ]; then
  emacsclient -c -n
else
  emacsclient -c
fi

¹ No GUI support means you don't need to have the requisite libraries installed. The emacs program can't start if the libraries it eneds aren't present, even if it isn't going to use the GUI features in that particular session.

This invocation of emacs that checks (fboundp 'tool-bar-mode) is testing whether your build of Emacs includes GUI support. It's possible to build Emacs without it to save a little bit of RAM and disk space¹, but it's uncommon. Unless you care about compatibility with Emacs builds that lack GUI support, forget about this bit.

You are thus left with

if [ -n "$DISPLAY" ]; then
  emacsclient -a "" -n -c "$@"
else
  emacsclient -a "" "$@"
fi

And even that level of complexity is necessary only if you want to have the call to emacsclient return immediately if it opens a new GUI window. (If it's running in the terminal, then it has to keep running until you finish using that terminal.) It's up to you to decide whether you like this behavior. If you don't then you can simply run

emacsclient -a "" "$@"

And if you start Emacs with your session anyway, e.g. as a systemd unit, then you don't need to tell emacsclient to start it. So we're left with

emacsclient "$@"

which I cannot simplify further.

¹ No GUI support means you don't need to have the requisite libraries installed. The emacs program can't start if the libraries it eneds aren't present, even if it isn't going to use the GUI features in that particular session.

That script from the Arch Wiki

This invocation of emacs that checks (fboundp 'tool-bar-mode) is testing whether your build of Emacs includes GUI support. It's possible to build Emacs without it to save a little bit of RAM and disk space¹, but it's uncommon. Unless you care about compatibility with Emacs builds that lack GUI support, forget about this bit.

You are thus left with

if [ -n "$DISPLAY" ]; then
  emacsclient -a "" -n -c "$@"
else
  emacsclient -a "" "$@"
fi

And even that level of complexity is necessary only if you want to have the call to emacsclient return immediately if it opens a new GUI window. (If it's running in the terminal, then it has to keep running until you finish using that terminal.) It's up to you to decide whether you like this behavior. If you don't then you can simply run

emacsclient -a "" "$@"

And if you start Emacs with your session anyway, e.g. as a systemd unit, then you don't need to tell emacsclient to start it. So we're left with

emacsclient "$@"

which I cannot simplify further.

Your added requirement

  • stay in the terminal (…) if called with a file (…) or when graphical environment isn't present (…)
  • open a GUI window when called without a file (…) and return immediately

For that you need to test whether the script was called with arguments. I'm going to assume that if you pass any emacsclient option (e.g. --eval), that counts as an argument.

if [ $# -ne 0 ]; then
  emacsclient -nw "$@"
elif [ -n "$DISPLAY" ]; then
  emacsclient -c -n
else
  emacsclient -c
fi

¹ No GUI support means you don't need to have the requisite libraries installed. The emacs program can't start if the libraries it eneds aren't present, even if it isn't going to use the GUI features in that particular session.

1
source | link

This invocation of emacs that checks (fboundp 'tool-bar-mode) is testing whether your build of Emacs includes GUI support. It's possible to build Emacs without it to save a little bit of RAM and disk space¹, but it's uncommon. Unless you care about compatibility with Emacs builds that lack GUI support, forget about this bit.

You are thus left with

if [ -n "$DISPLAY" ]; then
  emacsclient -a "" -n -c "$@"
else
  emacsclient -a "" "$@"
fi

And even that level of complexity is necessary only if you want to have the call to emacsclient return immediately if it opens a new GUI window. (If it's running in the terminal, then it has to keep running until you finish using that terminal.) It's up to you to decide whether you like this behavior. If you don't then you can simply run

emacsclient -a "" "$@"

And if you start Emacs with your session anyway, e.g. as a systemd unit, then you don't need to tell emacsclient to start it. So we're left with

emacsclient "$@"

which I cannot simplify further.

¹ No GUI support means you don't need to have the requisite libraries installed. The emacs program can't start if the libraries it eneds aren't present, even if it isn't going to use the GUI features in that particular session.