emacsclient minibuffer

emacsclient minibuffer

[Stephen Chadfield]

Using Emacs 24.3 in RHEL7. When I open a new frame with "emacsclient -c"
the minibuffer is the wrong size with the text:

"When done with the frame, type C-x 5 0"

partially duplicated (can only see the top half of the second version).

Clicking in the scratch buffer clears the minibuffer and sets it to the
correct size but it is still kind of annoying.

Any fixes, workarounds?

-- 
Stephen Chadfield

Re: emacsclient minibuffer

[Emanuel Berg]

Stephen Chadfield <stephen@chadfield.com> writes:

> Using Emacs 24.3 in RHEL7. When I open a new frame
> with "emacsclient -c" the minibuffer is the wrong
> size with the text:
>
> "When done with the frame, type C-x 5 0"
>
> partially duplicated (can only see the top half of
> the second version).
>
> Clicking in the scratch buffer clears the minibuffer
> and sets it to the correct size but it is still kind
> of annoying.

This sounds like a window manager issue. I have
(emacs-version t)

    GNU Emacs 24.4.1 (x86_64-pc-linux-gnu) of
    2014-10-25 on trouble, modified by Debian

and I don't get your situation. Can you tell us what
else you are using? X, GNOME, KDE, Openbox, fvwm...?

-- 
underground experts united

Re: emacsclient minibuffer

[Stephen Chadfield]

Using Gnome Shell.
-- 
Stephen Chadfield

Re: emacsclient minibuffer

[Emanuel Berg]

Stephen Chadfield <stephen@chadfield.com> writes:

> Using Gnome Shell.

Wow, that was some application! Took me ages to
install and slowed the computer down instantly. But I
just realized that I don't have a GUI Emacs anyway but
the /usr/bin/emacs24-nox ("no X") so I can't test
anyway. But it works in xterm and gnome-terminal from
X with Openbox and Gnome Shell. But yeah, it would
have been strange otherwise...

-- 
underground experts united

Re: emacsclient minibuffer

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> ... I just realized that I don't have a GUI Emacs
> anyway but the /usr/bin/emacs24-nox ("no X") ...

By the way, you can find out what Emacs executable you
use with

    readlink -e `type emacs`

which will track down the last symlink.

There, I have /usr/bin/emacs24-nox which is the
binary.

-- 
underground experts united

Re: emacsclient minibuffer

[Bob Proulx]

Emanuel Berg wrote:
> By the way, you can find out what Emacs executable you
> use with
>     readlink -e `type emacs`

Small typo.  You wanted `type -p emacs` there.  :-)

> which will track down the last symlink.

Or you can run update-alternatives to query it for what is active.
This is a Debian specific feature.  On a server:

  rwp@despair:~$ update-alternatives --display emacs
  emacs - auto mode
    link currently points to /usr/bin/emacs23-nox
  /usr/bin/emacs22-nox - priority 25
    slave emacs.1.gz: /usr/share/man/man1/emacs.1emacs22.gz
  /usr/bin/emacs23-nox - priority 26
    slave emacs-128x128.png: /usr/share/icons/hicolor/128x128/apps/emacs23.png
    slave emacs-16x16.png: /usr/share/icons/hicolor/16x16/apps/emacs23.png
    slave emacs-24x24.png: /usr/share/icons/hicolor/24x24/apps/emacs23.png
    slave emacs-32x32.png: /usr/share/icons/hicolor/32x32/apps/emacs23.png
    slave emacs-48x48.png: /usr/share/icons/hicolor/48x48/apps/emacs23.png
    slave emacs-document.svg: /usr/share/icons/hicolor/scalable/mimetypes/emacs23-document.svg
    slave emacs.1.gz: /usr/share/man/man1/emacs.emacs23.1.gz
    slave emacs.svg: /usr/share/icons/hicolor/scalable/apps/emacs23.svg
  Current 'best' version is '/usr/bin/emacs23-nox'.

The idea is that documentation and man pages are also linked to the
alternative.  As alternatives are selected the documentation follows.

Some time ago I wrote up a mailing list message describing the Debian
alternative system.  If you are interested in the rationale behind
things I think this is a good explanation of it.

  https://lists.debian.org/debian-user/2002/08/msg02808.html

Bob

Re: emacsclient minibuffer

[Stephen Chadfield]

Stephen Chadfield <stephen@chadfield.com> writes:

I recompiled emacs using lucid instead of gtk and noticed that the
minibuffer problem - along with some other annoying problems - went
away. It seems emacs+gtk still needs a little work...

-- 
Stephen Chadfield

Re: emacsclient minibuffer

[Emanuel Berg]

Stephen Chadfield <stephen@chadfield.com> writes:

> I recompiled emacs using lucid instead of gtk and
> noticed that the minibuffer problem - along with
> some other annoying problems - went away. It seems
> emacs+gtk still needs a little work...

OK, it was a graphics library compilation (?) problem,
not a WM problem: close enough! No, of course a
terminal Emacs wouldn't have this kind of problem.
What could go wrong? It is all an orchestra of strings
- doing unbelievable things...

But, even though I don't use the X GUI Emacs myself, I
suspect that Emacs has sufficient experience under
GNOME and GTK for it to work without visible bugs
(both desktops GNOME and KDE - KDE, which uses Qt
instead of GNOME's GTK - are projects of the
middle-late 90s).

-- 
underground experts united

Re: emacsclient minibuffer

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

...
> But, even though I don't use the X GUI Emacs myself, I
> suspect that Emacs has sufficient experience under
> GNOME and GTK for it to work without visible bugs
> (both desktops GNOME and KDE - KDE, which uses Qt
> instead of GNOME's GTK - are projects of the
> middle-late 90s).

Unfortunately there are still problems.  Emacs --daemon doesn't work
properly with GTK+.  That's because of a GTK+ side problem.

Although GTK+ is old it changes frequently.

BR,
Robert Thorpe