From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Split `simple.el'? Date: Thu, 5 Apr 2018 11:23:24 -0700 (PDT) Message-ID: References: <<5f1e960c-483f-4902-b4c2-b7a4ca3b04f4@default> <10c96362-297f-db97-d4a9-da3d66d4dd34@cs.ucla.edu> <83in974gwf.fsf@gnu.org> > <<83zi2j2hp4.fsf@gnu.org> > <<83vad51r06.fsf@gnu.org>> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1522952535 24980 195.159.176.226 (5 Apr 2018 18:22:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 5 Apr 2018 18:22:15 +0000 (UTC) Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 05 20:22:11 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f49WU-0006NH-L3 for ged-emacs-devel@m.gmane.org; Thu, 05 Apr 2018 20:22:10 +0200 Original-Received: from localhost ([::1]:46396 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f49YY-0001dr-H7 for ged-emacs-devel@m.gmane.org; Thu, 05 Apr 2018 14:24:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46400) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f49Xv-0001da-IA for emacs-devel@gnu.org; Thu, 05 Apr 2018 14:23:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f49Xu-0002xJ-Jo for emacs-devel@gnu.org; Thu, 05 Apr 2018 14:23:39 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:55516) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f49Xr-0002u8-7Z; Thu, 05 Apr 2018 14:23:35 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w35I3vp7084684; Thu, 5 Apr 2018 18:23:27 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=TpmFgi+2toaVd3VPBtbLeuCNwGxAVaurQzTFjdCH0BA=; b=voavUVWc5Jp9yGtnPxbro5HIgB0JyuMiIl0beim78eJQkZcaMyBNoSPIUACyBK0mDwzK u/ZWffAjItuPfH5IsFAGZ4I0cSwNOIw8PoSlgRL0Q+vMHcJQEd6BxkZnPJciB8FrE93t 9NSMu5dXaPDZwAUsJ+NVt33ZvclazRLT02VdOQI34QmSwBdDhm50eNWfSAhjT8cF8aBd DnOVpKbiCVuCq0Hwrq0HoF84vVNTcGB+cYMSD9vXvbvdTimBejl1pFxSGuW9RqKRbl4y Obr90dEZq/Aww/iTcsKgZxWZhN+XAq80D0A4eoe3YkXKizaQsvqdCf2mqNQS+uUnri4G yQ== Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2h5k4b9uka-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 05 Apr 2018 18:23:27 +0000 Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w35INQan013984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 5 Apr 2018 18:23:26 GMT Original-Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w35INPnk005271; Thu, 5 Apr 2018 18:23:25 GMT In-Reply-To: <<83vad51r06.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4666.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8854 signatures=668697 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=895 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050184 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.85 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:224370 Archived-At: > > I understand the problem now, I think. With my setup I > > automatically fit frames with buffers to their text. > > This happens after the buffer is visited (and thus > > displayed). >=20 > You mean, before it is displayed, right? No, afterward. I essentially tack on frame-fitting at the end of `switch-to-buffer'. (Among other reasons for this, I use `image-display-size' to accommodate frames showing images.) > > The frame-fitting code moves point through the buffer, > > at eol (`end-of-line'), within a `save-excursion', to > > get the longest line length. That movement presumably > > means that fonts are looked for to render the chars in > > each line. >=20 > That must slow down visiting very large files, even if they don't have > special characters in them. No, not noticeably. As I said, if I remove that problematic defcustom from `simple.el' then there is no delay at all - the buffer appears instantly. But sure, with a big enough buffer it could be noticeable. I could always add an option to not fit when `buffer-size' is "too big", but I haven't yet run into buffers that are too big in this regard. > Why not just use a wide-enough frame? Your monitor limits the width > you could set anyway. Dunno what you mean. The idea is to shrink-fit the frame to its buffer(s). A one-window-p buffer with short lines has its frame fit to the width of its widest line, resulting in a narrow frame. (There are user options to limit the max frame width and height and to do other things, but within such constraints the frame is shrink-fit to its content.) If I could easily detect the presence of text that would prove problematic to work with then I could avoid fitting in that case. Dunno how to do that. I could search for a fancy (e.g. non-ASCII) char, but that wouldn't test whether there is a potential problem, which depends on the particular fonts installed and the particular non-ASCII chars present.