bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#37564: [PATCH] don't export LINES and COLUMNS env vars in term to fi


From: Eli Zaretskii
Subject: bug#37564: [PATCH] don't export LINES and COLUMNS env vars in term to fix ncurses applications
Date: Mon, 20 Jan 2020 21:30:28 +0200

> From: Stefan Kangas <stefan@marxist.se>
> Cc: Glenn Morris <rgm@gnu.org>,  Eli Zaretskii <eliz@gnu.org>,
>   37564@debbugs.gnu.org
> Date: Mon, 20 Jan 2020 20:10:49 +0100
> 
> Matthew Leach <matthew@mattleach.net> writes:
> 
> > Glenn Morris <rgm@gnu.org> writes:
> >
> >> I think the point is that no terminal emulator / shell combination
> >> actually exports LINES and COLUMNS as environment variables, except for
> >> Emacs term.el. So no application can be relying on the LINES and COLUMNS
> >> environment variables (since there aren't any applications specifically
> >> for use inside Emacs's term). So term.el should stop setting them, since
> >> it actually causes problems.
> >
> > Exactly that.  By exporting these variables it's causing more problems
> > than it solves.
> 
> That sounds reasonable to me.  Should we go ahead and install the
> original patch on the master branch then, or is there more to discuss?

Sorry, but I need more than just assertions to convince me.  I have
yet to see an application that doesn't cater to LINES and COLUMNS.
Heck, Emacs itself does!  It is true that these variables nowadays are
mostly kept for the users, but that doesn't yet mean Emacs cannot use
them to affect the programs it runs.  As for "causing more problems
than it solves", I don't think I saw any evidence for that: even the
one use case which started this bug report was later shown to behave
as expected.  Or maybe I was just confused, in which case I'd
appreciate a clear and concise description of how these variables are
harmful for ncurses programs.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]