From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id XpKsCu6O02BTzAAAgWs5BA (envelope-from ) for ; Wed, 23 Jun 2021 21:43:42 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id SJesBe6O02DMZAAAbx9fmQ (envelope-from ) for ; Wed, 23 Jun 2021 19:43:42 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 5A8CC1B05E for ; Wed, 23 Jun 2021 21:43:41 +0200 (CEST) Received: from localhost ([::1]:57998 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lw8mh-0000lj-1i for larch@yhetil.org; Wed, 23 Jun 2021 15:43:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33824) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lw8mH-0000lY-4h for emacs-orgmode@gnu.org; Wed, 23 Jun 2021 15:43:13 -0400 Received: from mail-lf1-x12a.google.com ([2a00:1450:4864:20::12a]:41751) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lw8mF-0001a1-4p for emacs-orgmode@gnu.org; Wed, 23 Jun 2021 15:43:12 -0400 Received: by mail-lf1-x12a.google.com with SMTP id j4so6030240lfc.8 for ; Wed, 23 Jun 2021 12:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ndfgULt26UIrP1BDQUwQMReAYiBAmk5DJF/KFxsUExo=; b=qRioGwoxYps0GRidPNUk+B6orJYsc2zHVpPBrwMfgdPuN1DDQwAojp2cujQWsYP5JO UnMqanePCqm7xr21y4T1gv4rfVi8CkFniMx5UoL7zLoJjZ2JlexS6sPqrfQv9RgQfzSm QoR/3WYnMa0WqJfIRrzozK7KqcaPckzK5A5WcEAiGThzEXyt4zq4VFBHJC+z8j3Nyi8F 3cGR4XJDbZnPX+LsTjlJvH9QHiwVuXDK9s/QOGbHm64I3WsAwcWy1xqwgOYqYjAIrunc pl4FOaN1ad99tbo0eFVA+q/1P3rARKRDFCV80oRQUppKxerxqhNh7FU5aPWsNO74ONFe mi9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ndfgULt26UIrP1BDQUwQMReAYiBAmk5DJF/KFxsUExo=; b=XJsS+XV9kpOScevxhV1qO+twYslrJMaW3PLNBADur7em2u2OcChsSjUcqsjTtN+JrC PkBa7FXTgnd0NLMMS2bwNEI1vAHQ6yFHGC2tIQ22zOvsUPMqcdNcxqGzEZMQQVVTGMdF CgEfQtiy0iz34cPxI4scQoLf9oZpheLl74ela6n+QbWakMxEeRT9JtA8EqJtG1u7rOuW 8c0rygMGRnVWE7KtYhrWQ5D0DglVqkyebpOOXVIfVuzNApbVDwSQ7t6HzoHF/YREmDTo iD+mHnt/jXeZ4869Aud9WMOXRSoNFiB3RzWcAiNGm5lYTSv1xdvQI7uSPkl0ArKgWBSC BrOg== X-Gm-Message-State: AOAM531ys2/Z/KkAzcu+HDS85jcC/1tha6okV9EtiRbwazDns0QVhZLk DloTaQOb8AlFxTNDiPj1F0Lij17SJHNXY3g1MNc= X-Google-Smtp-Source: ABdhPJwJ1ciUj0HJI+jyvNQnIqPRjOa7m66506AyuOt+WiMlt4/nTUoDrhp05lSPWHyiMT4AM6eAxzz4YL/OE2l4heQ= X-Received: by 2002:ac2:5dca:: with SMTP id x10mr968923lfq.442.1624477388721; Wed, 23 Jun 2021 12:43:08 -0700 (PDT) MIME-Version: 1.0 References: <87o8by2v1q.fsf@ucl.ac.uk> <8735ta2j2d.fsf@ucl.ac.uk> In-Reply-To: From: Gennady Uraltsev Date: Wed, 23 Jun 2021 15:42:41 -0400 Message-ID: Subject: Re: Large source block causes org-mode to be unusable To: Maxim Nikulin Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::12a; envelope-from=gennady.uraltsev@gmail.com; helo=mail-lf1-x12a.google.com X-Spam_score_int: -6 X-Spam_score: -0.7 X-Spam_bar: / X-Spam_report: (-0.7 / 5.0 requ) BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1624477421; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=ndfgULt26UIrP1BDQUwQMReAYiBAmk5DJF/KFxsUExo=; b=UeJQXE0eEhnbdy1HbU0LT95NiBucaSOUQEUAZUisqBmO7piLcQMjeVfy50cndr49hW29Jc zIQkQyx0Ohh+cVFczNHD5C3qf782K+gKggfJ34X5DuKckyxSnAc9qfD9KacSohjCS4Hzao 4v+SNwuolLY+HJ8/PpNjMIWfpznImiNCAKyMJSW6gsQOOLcOxdj4qi+l+CaZjPoR6Ak66S 3djMXiu9Xk0AjiMARs/F+GXN+dgXr6vRJvQSUpBjWbKlc4TcmiHRVQTwibCBlb8+zo10v5 iWW9HY5hmczESKzw0o+5ZblBN+FePfc0uYWLFo4qXfEqtgkJpsRqs1zUlFrtaA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1624477421; a=rsa-sha256; cv=none; b=W5VD30LFrNefdE5S0MqxOmbr6GJDdH0bXZFd3zrfMm2AkMcJQwFK21jOqEvmQqeubx8blE T/44sQUFU0lVt3pGC8BQCIP8Mn3PpVxADJNNNChKcJ7MG4tZBGpd3p/+9u8B5e0gZcPAgS u/fImIQMkwopGDR911sqgKwhfQXTfmKBQ/4lteV01MkcKDU/HX/rClkRSzmoFM5C5LGsMb 29iPtNHgKAjsVdVx11INkRErh2RxtRoc6uEWO8cYpAgL7bbq9jkJ2lJy/jPWh2at5bKLh+ 6r/P+QaSVgxA/e+sHBLO3oVNkssBBAiK68I5uV7fqrL6LJl9Uhg30nLyx4hOEA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=qRioGwox; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Spam-Score: -3.13 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=qRioGwox; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 5A8CC1B05E X-Spam-Score: -3.13 X-Migadu-Scanner: scn1.migadu.com X-TUID: VFk+SJ1Ox9kH Hello Everyone, I wanted to chime in to say I encountered a very similar problem. I author my math papers in LaTeX but I really wanted to use org to have an interconnected corpus of math notes with definitions, proofs, ideas, attempted computations, etc. Then they could be exported to LaTeX or even better: HTML to make for quite nice interactive notes (with popups backlinking to definitions of mathematical objects, etc...) (I was writing the latter in some JS). Unfortunately, HTML (+mathjax or whatever) is much more flexible than PDFs >I suggest that special block in LateX export (https://orgmode.org/manual/S= pecial-blocks-in-LaTeX-export.html) may be treated differently. Once again,= I'm new to org-mode, but here is my intuition: >- What is happening now. The #+BEGIN_proof / #+END_proof keywords cause my= proof to be seen as a block. Therefore, babel fontification is called to h= ighlight syntax of my proof within my buffer. Timothy already discussed her= e how inefficient the >babel fontification is. >- What could happen. Changing (somewhere) the treatment of #BEGIN_proof & = co the following way: Assign them to a new face "latex_export_sugar" and ig= nore them while editing. Doing this, the fontification of the org proof wil= l be made as usual and >will be fast enough. While exporting, replace #+BEG= IN_proof by \begin{proof} and so on... Exactly! Before HTML export becomes relevant, I if I tried to use #+BEGIN_proof #+END_proof or #+BEGIN_definition #+END_definition insertion in these environments slowed very quickly down to a crawl. If I remember correctly the profiler told me that it was due to fontification. For me, the slowness in fontification INSIDE actual latex math blocks (the only place where I need fontification, and I would prefer to use AucTeX to do that, since it is really good at it) is generally not an issue since I mostly have latex previews and use the edit source command to work on the formulae. It would allow for a greater variety of workflows if one could specify that some blocks lines should be ignored for fontification purposes and the contents be treated as usual org-mode text. If you think it can be useful I can try to dig up my (abandoned) attempts and try to provide test cases to improve performance. > If proof environment is still required, maybe it is possible to > customize export backend to have proofs as a headings with some property > in the source document. Unfortunately this is not really fitting with my workflow (and I think this is not only my issue). In Org Mode, headings cannot "terminate" i.e. only a new section can stop a previous one. So, essentially, one would need to do a very non-elegant trick similar to one used by the "inline TODOs" i.e. having a very deep level of heading (10?) that "starts" a proof and then an artificial one that "ends" it. Also, the point of having "proof" blocks and "example" blocks that often, when reading math, you do not want to go through the proof on the first reading. One issue that many colleagues have agreed when discussing is that it would be so great to have a "collapsible" environment or block. When we write notes or explanations of material, often we are tasked with making a call: do we do computations step by step and risk being verbose, or do we write only the main steps and leave it to the reader to fill in the intermediate ones. Both these approaches have downsides. The former makes seeing the main points of the reasoning difficult to catch and forces a reader to commit significant effort to completely read the paper or notes (even if they just want the gist of it). The other approach may frustrate the reader interested in details because he/she has to work through the material to fill in all the gaps, often spending a lot of time on omitted intermediate steps. I was actually trying to come up with a natural system through org and HTML export to avoid this dilemma and have sections that are hidden by default but can be "expanded" on request. > On the other hand my impression was that \begin{proof} environment is > intended to emphasize a paragraph or two to separate it from regular > text on the same page. My expectation is that 4-page long proof should > be formatted as ordinary sections and subsections. Unfortunately this goes against the standard of mathematical writing (that I at least am familiar with). Proofs are often long and technical and can span multiple pages. If there are self-contained results in the proofs you separate them out in statements (lemmata) with their own (shorter) proofs. Text outside proofs is usually explanations and "glue" that explains the process, the idea, but does so on a more "informal" level. Having "proof" environments is also very useful as a method of having "namespaces", often you need to introduce auxiliary objects, expressions, operations, that are relevant only for the proof of the result but that should not be "polluting" the full paper or writeup. For example, if you introduce something inside a proof and denote it with a symbol (e.g. $\phi$) then as soon as you hit the QED symbol at the end of the proof, that symbol is freed and can be used in other proofs/constructions. It is very bad form, for example, to reference objects inside proofs of theorems outside the proofs themselves. If something is an object of general interest then it should be "defined" (included in a definition) on its own. I apologize for going on a tangent. Thanks again to everyone for the great package that is ORG, that I am progressively trying to incorporate in more and more of my day-to-day work and life. Best! Gena -- Gennady Uraltsev (https://guraltsev.gitlab.io)