From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: move-beginning-of-line Date: Tue, 15 Mar 2005 23:23:10 +0100 Message-ID: References: <200503140258.j2E2wbI11194@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1110926155 14112 80.91.229.2 (15 Mar 2005 22:35:55 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 15 Mar 2005 22:35:55 +0000 (UTC) Cc: Luc Teirlinck , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 15 23:35:54 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DBKa1-0006d1-Bo for ged-emacs-devel@m.gmane.org; Tue, 15 Mar 2005 23:32:02 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DBKpy-0004v0-Rz for ged-emacs-devel@m.gmane.org; Tue, 15 Mar 2005 17:48:30 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DBKom-0004cc-Sb for emacs-devel@gnu.org; Tue, 15 Mar 2005 17:47:17 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DBKod-0004Yf-P3 for emacs-devel@gnu.org; Tue, 15 Mar 2005 17:47:08 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DBKod-0004Yc-KV for emacs-devel@gnu.org; Tue, 15 Mar 2005 17:47:07 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DBKRS-0006SB-WB for emacs-devel@gnu.org; Tue, 15 Mar 2005 17:23:11 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1DBKRS-0007zn-9u; Tue, 15 Mar 2005 17:23:10 -0500 Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: (Kim F. Storm's message of "Mon, 14 Mar 2005 09:20:53 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: news.gmane.org gmane.emacs.devel:34621 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34621 storm@cua.dk (Kim F. Storm) writes: > Luc Teirlinck writes: > >> Kim Storm wrote: >> >> As I indicated in another mail today, I have been looking at a problem >> with moving to the beginning of a line in a window with the following >> appearence: >> >> abc >> [ ] >> x[IMAGE]yz >> [ ] >> def >> >> Now, if I place the cursor on x, and do C-e, cursor moves to z. >> If I then do C-a, cursor moves to y, not x. >> >> The IMAGE is layed on top (via a display property) of text that ends >> in a newline, so formally, C-a (beginning-of-line) DTRT. >> >> However, from a user point of view, this is !TRT. >> >> Sorry for replying so late to this, but is there some extremely >> good (that is, absolutely unavoidable) reason why that image is >> layed on top of text that _ends in a newline_ (or just contains >> newlines)? Is that fact, rather than beginning-of-line not the >> problem? Where the overlay is used to give a different appearance to buffer parts (where the text of those buffer parts is under user control), it is not possible to avoid. > For example, this is how insert-image-file works. > Try to eval this in an empty buffer: > > (progn > (insert "\nab") > (insert-image-file "../etc/splash.xpm") > (move-end-of-line 1)=20 > (insert "def\n")) > > > This could be considered a bug in insert-image-file. > > I wonder how preview-latex handles this, as it uses images over > multiline text _a lot_ ...? Does beginning-of-line work ok with > images in the middle of lines? If so, how? As I said, preview-latex moves point out of images, so the cursor will usually end up at the start of the image. The effect is probably not annoying enough as to cause people to complain. preview-latex really puts only a thin veil over the covered entities: if you move with or into a preview, it unfolds again, and the same if you search for text or do a query-replace. So when editing, people understand that they are not dealing with the equivalent of characters. It is only when they are looking at the screen that they want the illusion. For example, we have had to stop AUCTeX from formatting stuff like This is a very long line and continues for a while and then we have $E =3D mc^2$ and then the line continues for another while. since preview-latex would make a single visual line like This is a very long line and continues for a while and then we have [E=3Dmc= =B2] and then the line continues for another while. out of it. So we tricked AUCTeX into using formatting rules that would "coincidentally" keep newlines out of inner structures as long as they could be avoided. And if they could not be avoided, it would break just behind them, at least optionally. >> Trying to "fix" the C-a behavior you consider "wrong" using >> `move-beginning-of-line' is not going to change the fact that every >> other Emacs command or function will still consider the offending >> newline to be the end of a line _and_ to be visible (unless it has >> the invisibility property). Giving newlines a display property is >> a very dubious thing to do. I do not believe that very much in >> Emacs is prepared for newlines with a display property. > > True. False. When Emacs 21.1 was coming up, I was plastering Gerd with bug reports. All sorts of cute little display errors, in particular involving newlines. Emacs took _quite_ a bit of beating in that area. Now that was catering for inconsistent displays: cursor movement and similar are not necessarily involved. I'd be interested in seeing stuff like auto-fill work sensibly in the presence of display properties. The best behavior for stuff like preview-latex would probably result if filling kept track of both the visual line size as well as the real buffer line size and caused a break when either was exceeded. Something like that. But I guess this would not be a sensible filling default in the general case of text properties, just a nice option to have for preview-latex. The sensible default would probably just cater for what is visible, meaning that it would skip across any display properties (filling changes inside of them don't change the appearance). > True. I have tried to put invisibile property on the image text, > but it doesn't give good result for me ... anybody want to > experiment with that, to find something which works ? > > If we can fix the places where a display property gives problems, I > guess we could get rid of move-beginning-of-line (or at least not > have it as the default binding for C-a). I am somewhat skeptical that this can be fixes in general... --=20 David Kastrup, Kriemhildstr. 15, 44793 Bochum