Emacs (nowindows) get confused about line display

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?

Re: Emacs (nowindows) get confused about line display

[Emanuel Berg]

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

> 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?

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 -                   

Re: Emacs (nowindows) get confused about line display

[David M. Karr]

On 05/20/2016 04:28 PM, Emanuel Berg wrote:
> "David M. Karr" <davidmichaelkarr@gmail.com>
> writes:
>
>> 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?
> 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.
>
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?

Re: Emacs (nowindows) get confused about line display

[David M. Karr]

On 05/20/2016 05:45 PM, David M. Karr wrote:
> On 05/20/2016 04:28 PM, Emanuel Berg wrote:
>> "David M. Karr" <davidmichaelkarr@gmail.com>
>> writes:
>>
>>> 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?
>> 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.
>>
> 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?
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.

Re: Emacs (nowindows) get confused about line display

[John Mastro]

David M. Karr <davidmichaelkarr@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

Re: Emacs (nowindows) get confused about line display

[Eli Zaretskii]

> From: John Mastro <john.b.mastro@gmail.com>
> Date: Fri, 20 May 2016 18:19:00 -0700
> Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> 
> David M. Karr <davidmichaelkarr@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.

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.

Re: Emacs (nowindows) get confused about line display

[Emanuel Berg]

"David M. Karr" <davidmichaelkarr@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 -