bug#18001: default behavior changes

[Joel F Rodriguez]

OK Eli, my apology. I don't often resort to consulting with bug lists and I
had just spent a solid day upgrading my FreeBSD system.

I agree, it appears -nw is not the answer and my initial observations that
it solved the problem have since disappeared.

So ok, I just rebuilt which amounts to running 'freebsd-update -r
9.2-RELEASE upgrade' followed by ' /usr/sbin/freebsd-update install'.

The procedure is documented at
http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html

Portmaster was installed and run after the successful upgrade and the system
spent the night rebuilding all the ports.

The next day when I used putty to SSH to the server and start emacs I would
get a fixed width version (80cols)  of emacs running in a resizable window.
If I resized the window emacs would disappear from view.  When I stated
default behavior, that is what I meant, I do not customize emacs in anyway
shape or form, I use just what the port install gives me. So naturally I
started playing with the config files to no avail. I also rebuilt the
emacs-devel version. Four hours later I submitted my bug report.

The version of emacs installed via ports is version 24.3.1.

SSH and emacs are my go to tools to maintain my servers, so I was a bit
bummed with the fixed width stuff. So much so I installed the latest version
of Cygwin on my win7 workstation. An xterm session to the host revealed that
emacs was resizing correctly so this issue was limited to SSH. The xterm
session also lacks some cut/paste features I use and I'm not that fond of
bash.

After that I tried the -nw option which seemed to work.

To continue with the story, I then built gnome2 to checkout their
desktop(kinda sucks) and spent another day installing various X11 stuff and
Gnome2 tools. Somewhere along the way my 'emacs -nw' alias stopped working
and viola emacs started correctly resizing in a SSH window.

Thanks for your persistence.

Joel




-----Original Message-----
From: Eli Zaretskii [mailto:eliz@gnu.org] 
Sent: Saturday, July 12, 2014 8:57 PM
To: Joel F Rodriguez
Cc: rgm@gnu.org; 18001@debbugs.gnu.org
Subject: Re: bug#18001: default behavior changes

> From: "Joel F Rodriguez" <joel@tahoestores.com>
> Cc: <18001@debbugs.gnu.org>
> Date: Sat, 12 Jul 2014 14:28:36 -0700
> 
> The problem seems far too simple as to require extensive explanations 
> and details un-related to solving the problem.

And yet even now, after half a dozen exchanges, neither you nor we
understand why the problem happened to you, why you couldn't resize a
graphics frame.

> No, I got far too much static relative to semantics and no answers.

It is unfortunate that so many messages have come and gone without any real
understanding of your problem.  Perhaps it would have helped if you answered
our questions.

> The answer was so simple, I forgot it. I guess I confused the issue 
> when I asked what changed.

Going to -nw is _not_ the answer.  GUI frames _can_ be resized, I do that
every day.  Their initial size _can_ be controlled, both from the
command-line arguments you use to invoke Emacs, and from your ~/.emacs init
file.

> After 40 years in this field I can assure you it is much more 
> important to come up with a simple answer, then to go off on a rage on 
> bug reporters not being familiar with your specific jargon. I mean who 
> still talks about text-terminals in the real world? This is indicative 
> of the emacs docs on the whole, its primary keys are technical 
> specific terms which makes it nearly impossible to format a query to 
> google unless you have had your head buried in the source codes for
months.

The text-mode sessions are still widely used and are completely covered in
the documentation.

> Again, sorry for the ruckus, but I do like the old saying, "if it 
> ain't broke, break it".

Evidently, something _is_ broke on your system, or in how you invoke/use
Emacs.