From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Several suggestions for image support Date: 21 Apr 2004 14:51:40 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1082546427 17037 80.91.224.253 (21 Apr 2004 11:20:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 21 Apr 2004 11:20:27 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Apr 21 13:20:19 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BGFm7-0007Gv-00 for ; Wed, 21 Apr 2004 13:20:19 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BGFm6-0001SC-00 for ; Wed, 21 Apr 2004 13:20:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BGFhv-0008TY-2P for emacs-devel@quimby.gnus.org; Wed, 21 Apr 2004 07:15:59 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BGFY4-0007DA-Dm for emacs-devel@gnu.org; Wed, 21 Apr 2004 07:05:48 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BGFPs-000655-IP for emacs-devel@gnu.org; Wed, 21 Apr 2004 06:57:51 -0400 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.30) id 1BGFKi-0005ay-Lo for emacs-devel@gnu.org; Wed, 21 Apr 2004 06:52:00 -0400 Original-Received: (qmail 24178 invoked from network); 21 Apr 2004 10:51:59 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 21 Apr 2004 10:51:59 -0000 Original-To: David Kastrup In-Reply-To: Original-Lines: 61 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:21985 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21985 David Kastrup writes: > Ok, here is the next problem I see: assume that I have the input in > preview-latex: > > > \begin{smallmatrix} 1&2\\ 3&4 \end{smallmatrix} > > This will produce a single image split into 4 slices that I want to > have arranged > > 12 > 34 > > This stuff we will split into 4 overlays covering > \begin{smallmatrix} 1& > 2\\ > 3& > 4 \end{smallmatrix} > > Now here come the somewhat ugly things: in order to have this > composition arranged properly, the first overlay will also have to > contain a before-string of "\n", and the second and fourth overlay > will contain an after-string of "\n". Cursor up/down will not produce > any sensible results. Sounds like a problem with cursor motion in the presense of newlines in before and after string properties -- maybe something for our "line-move" experts to look into. > > Ok, I mean with preview-latex the solution is not too bad: require the > source to be formatted appropriately, or the image does not get > sliced, period. Namely, have a newline after every row and only a > constant non-printing fillprefix before each row (as a requirement for > slicing). As in: .. (newline) \begin{smallmatrix} 1&2\\ (newline) 3&4 \end{smallmatrix} (newline) I.e. if input is like this, image can be sliced; otherwise, image is not sliced. Sounds like a sensible approach to me -- if the latex-mode (or whatever) can help you write in the proper format and warn (different coloring like in makefile-mode) if there are things which breaks that format. > And better use align-current to align all & signs > (optionally, will make cursor movement nicer). If we place those > requirements on source formatting, we won't be needing any > before-string and after-string, and things get slightly more sane. > > So I think we might get along without more heavyweight support here > for now. Good. -- Kim F. Storm http://www.cua.dk