Emacs (nowindows) get confused about line display

[David M. Karr]

On my CentOS laptop, I have a CentOS VM that I created with Vagrant. I
have Emacs 24.3.1 on the VM.

I start a terminal window on the laptop and ssh to the VM. I run Emacs,
but I don't have X11, so it's in "no windows" mode.

Sometimes, when I start emacs on the VM, it starts up fine and displays
properly.

Quite often, and pretty continuously when it gets into this state, it
will start up with a blank editor view, with no menu bar, and the cursor
displays on the SECOND line of the window. When I then view or edit
files, it appears that Emacs is confused about its line rendering. The
cursor appears at the bottom of the window, even though it "thinks" it's
on the top line of the file I'm viewing. I can scroll the cursor to the
right, and it will jump back to the beginning when it reaches the length
of the first line, and so on.

Emacs is completely useless in this state.

What can I do at this point?

[Emanuel Berg]

"David M. Karr" <davidmic...@gmail.com>
writes:

You can analyze the whole chain of invocation.
What is the terminal emulator, shell, ssh
command, and Emacs invocation command? And if
you have tmux or something to that extent in
between any of those, that can influence, also.

--
underground experts united .... http://user.it.uu.se/~embe8573
Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic
- so far: 36 Blogomatic articles -

[David M. Karr]

Ok, well, $TERM appears to be "xterm-256color", shell is bash, I got
there with "vagrant ssh", and I execute Emacs with "emacs".

That gave me the idea to run "emacs -q", and that does provide a clue.
The display is fine after that, but when I load my .emacs after the fact
(eval-current-buffer), it's then messed up. Before I do a binary search
to narrow down what initially creates the symptom, are there any other
guidelines for narrowing down something like this?

[David M. Karr]

Actually, narrowing it down didn't take very long, but I'd still like to
understand this better.

The 2-3rd line of my .emacs file has this:
--------------------------
(set-frame-position (selected-frame) 0 0)
(set-frame-height (selected-frame) 60)
----------------

This is obviously not relevant in a emacs-nw situation, but I copied
this from my "home" .emacs file. Why would this cause the symptom that
I'm seeing?

It's easy enough to wrap this with a "(display-graphic-p)" call, but I'd
like to understand why this is happening.

[John Mastro]

David M. Karr <davidmic...@gmail.com> wrote:
> Actually, narrowing it down didn't take very long, but I'd still like to
> understand this better.
>
> The 2-3rd line of my .emacs file has this:
> --------------------------
> (set-frame-position (selected-frame) 0 0)
> (set-frame-height (selected-frame) 60)
> ----------------
>
> This is obviously not relevant in a emacs-nw situation, but I copied this
> from my "home" .emacs file. Why would this cause the symptom that I'm
> seeing?
>
> It's easy enough to wrap this with a "(display-graphic-p)" call, but I'd
> like to understand why this is happening.

It looks like the problem is with the call to `set-frame-height'
specifically. `set-frame-position' has no effect on a tty frame.

Further, (set-frame-height (selected-frame) (frame-height)) didn't cause
any problems in my experiments; only when I set a wrong frame height did
I get Emacs into a bad state. So it's not that `set-frame-height'
inherently breaks things on a tty.

However, I don't know whether there are scenarios where it makes sense
to call `set-frame-height' on a tty frame, or if this is just one of
those "well don't do that" situations.

John

[Emanuel Berg]

"David M. Karr" <davidmic...@gmail.com>
writes:

> That gave me the idea to run "emacs -q", and
> that does provide a clue. The display is fine
> after that, but when I load my .emacs after
> the fact (eval-current-buffer), it's then
> messed up. Before I do a binary search to
> narrow down what initially creates the
> symptom, are there any other guidelines for
> narrowing down something like this?

Well, probably not. Binary search is a brute
force method that is rather the opposite of
educated heuristics.

Here are some thoughts on binary search and
Emacs:

http://user.it.uu.se/~embe8573/blogomatic/emacs/binary-search-to-find-bugs-in-emacs-init-files.html

--
underground experts united .... http://user.it.uu.se/~embe8573
Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic

- so far: 37 Blogomatic articles -

[Eli Zaretskii]

> From: John Mastro <john.b...@gmail.com>
> Date: Fri, 20 May 2016 18:19:00 -0700
> Cc: "help-gn...@gnu.org" <help-gn...@gnu.org>

I suggest to upgrade to a later version of Emacs, but in general, my
advice is not to use set-frame-height in TTY sessions. That function
does produce a non-trivial effect on a TTY, but the effect is only
useful for debugging Emacs, not for normal usage.