Re: [PATCH] Add support for $…$ latex fragments followed by a dash
Ihor Radchenko writes: > Rudolf Adamkovič writes: > >> Let $r_i$ denote the \(i\)-th rotation of $t$ with a suffix of $\ell|t|$ >> characters deleted, for […] >> >> Me, if I could, I would pay money for this feature, for it would allow >> me to use $$ consistently, focusing on mathematics instead of markup >> idiosyncrasies of "rotation $i$" versus "\(i\)-th rotation". > > Would it improve things for you if we change how \(...\) _looks_ in Org > buffers? > > The problem with parsing is more than just supporting $i$-th and > similar. For example, AMS style guide explicitly advises against using > $i$-th in favour of $i$th [1]: > > Do not hyphenate “th” expressions: xth, not x-th or xth . > > We can theoretically make a change to support "-", but then it will be > logical to support $i$th as well. (If we don't some users will still be > confused after trying to write $i$th and then not getting the expected > results). In this question, it would make sense to implement > all-or-everything approach. Otherwise, confusion (like raised in this > thread) will be inevitable. > > However, from point of view of Org mode parser, supporting $i$th is a > nightmare. Remember that Org mode is _not_ LaTeX and we have to support > a lot more frivolous syntax (even in LaTeX, runaway $ is often a source > of cryptic compilation errors). Currently, we _must_ rely on heuristics > to determine $$-style latex fragments. I do not know any way to support > $$ syntax without creating deviations from LaTeX. Extending the > heuristics will not resolve the underlying ambiguity of $$ syntax, just > hide it within even more obscure cases. > > Given the raised concerns, may we solve the issue with too verbose > \(...\) unambiguous syntax using the following approach: > 1. Fontify \(...\) replacing the brackets with a single character. For >example: > > \(...\) -> ⁅...⁆ > > 2. Provide convenient way to input \(\) brackets through >electric-pair-mode or trough org-cdlatex-mode. > > Best, > Ihor > > [1] https://www.ams.org/publications/authors/AMS-StyleGuide-online.pdf +1. Just my $0.02 worth - I think this is the right approach. Retaining support for $..$ doesn't seem feasible given all the complexities it brings with it. The main objections to the alternative appear to centre around readability and inconvenience of having to type additional characters or dealing with muscle memory use to $...$. These are essentially interface issues and I think we can largely address them using existing Emacs facilities. This will reduce the change impact to that sub-set of org users accustomed to $...$ while bringing the benefit of a cleaner and potentially more efficient parser to all org users. If we do deprecate support for $...$, it might also be a good idea to see if we can add a utility function which would make it easier for people to migrate existing documents to the new/alternative syntax. For the same reason it is hard to reliably parse $...$ syntax, we probably can't automate that transition, but we should be able to reduce the effort required to update existing documents.
Re: [PATCH] Add support for $…$ latex fragments followed by a dash
Hi, Ihor Radchenko writes: We can theoretically make a change to support "-", but then it will be logical to support $i$th as well. (If we don't some users will still be confused after trying to write $i$th and then not getting the expected results). I disagree. 1. The $…$- pattern is also used for other common constructions, such as $n$-dimensional, $K$-lipschitz, etc. As for $n$−th vs $n$th, both are commonly used. In french, $n$− is the correct one. 2. It does not logically follow that we should support $i$th as well, since, as you point out, it'd be impossible. One argument for the patch is that is it very simple. 3. The $n$th construction failing is not as confusing. One understands quickly what the limitation is, and several workarounds are available, whereas there's no good reason for the $n$− limitation, and it's harder to think of a workaround. I should mention that the zero-width space character can be used to work around both limitations. Given the raised concerns, may we solve the issue with too verbose \(...\) unambiguous syntax using the following approach: 1. Fontify \(...\) replacing the brackets with a single character. For example: \(...\) -> ⁅...⁆ 2. Provide convenient way to input \(\) brackets through electric-pair-mode or trough org-cdlatex-mode. If the $…$ syntax were to be deprecated, this would be a nice addition, indeed. As a user, I find it quite satisfactory (with some added utility to easily switch between the \(…\) and \[…\] syntax). Some possible drawbacks : - are the display hacks scalable in a large document, with many LaTeX snippets ? - this feature may still be hard to discover, turn on and use by users more concerned with mathematical content and less familiar with emacs features such as fontification, automatic insertion of complex delimiters and whatnot. - hiding the syntax feels a bit weird, although it is already done with emphasis markers. With respect to the possible deprecation of the $…$ syntax, the drawbacks and complexity of this alternative should be weighted against those of the current $…$ syntax, but no one has really spelled out what the latter are. We're trading complexity here for complexity there, fixing the false positives (but how common are they ?) and the false negatives (which can be an annoyance while writing a snippet). Thank you for bringing this up, Regards, -- Sébastien Miquel
Re: [PATCH] Add support for $…$ latex fragments followed by a dash
Rudolf wrote: > Further, \(\) brings 100% more characters than $$, resulting in more noise in > the sentence. Now where did I put my APL keyboard... Cheers Rasmus
Re: [PATCH] Add support for $…$ latex fragments followed by a dash
Hi, Tom Gillespie writes: The change is local and minor. We can't know that. I meant that the change to the syntax would be minor and local, with respect to the linked syntax document. #+begin_src org I spent $20 on food and was paid$-10 dollars by friends so I am down $10. #+end_src [...] #+begin_src org Text a $A_BASH_VAR Text b some-$-lisp-var #+end_src The proposed change would break any file with a pattern like this. As you say, your first example is a typo. As for the second example, it's a very uncommon pattern, and if such variable names occur in a document, they should either be inside src blocks, or inside verbatim or code markers. In both case, there's no breakage with respect to parsing, export and tangling. The fontification may fail though. It wont fail if your src blocks are fontified natively, and the fontification of $…$ can be globally disabled. We have no way of seeing every org file that users have written so we don't know the extent of the impact, and thus have to assume that there would be some impact. Making such a change with an unknown blast radius in the midst of considering removing support for that syntax altogether is inviting disaster. We can make an educated guess. It is quite likely that this change will fix more documents than it breaks. Hardly a disaster. Regards, -- Sébastien Miquel
Re: [BUG] org-protocol-store-link does not account for argument type
> See the last paragraph of the docstring: > >> FNAME should be a property list. If not, an old-style link of the > ^^ >> form URL/TITLE can also be used." > > You pass a string for *new* URI style. I see, it seems I have misunderstood the documentation then. My apologies for the inconvenience.
Re: [BUG] org-protocol-store-link does not account for argument type
On 27/01/2022 22:13, Thuna wrote: Could you, please, describe your actual problem? Currently, org-protocol-store-link, as a function, fails to work for new-style links. Doing the following: 1. M-: (org-protocol-store-link "url=U&title=T") 2. M-x org-insert-link and accepting the suggestions for the link and the description inserts "[[url=U&title=T]]" instead of "[[U][T]]", which should be the expected behavior according to the documentation of the function, unless I am misunderstanding it. See the last paragraph of the docstring: FNAME should be a property list. If not, an old-style link of the ^^ form URL/TITLE can also be used." You pass a string for *new* URI style. Maybe there is another description of the interface that should be implemented by functions handling subprotocols. You may look at the tests if you are going to use org-protocol in some special way.
Re: [BUG] org-protocol-store-link does not account for argument type
> Could you, please, describe your actual problem? Currently, org-protocol-store-link, as a function, fails to work for new-style links. Doing the following: 1. M-: (org-protocol-store-link "url=U&title=T") 2. M-x org-insert-link and accepting the suggestions for the link and the description inserts "[[url=U&title=T]]" instead of "[[U][T]]", which should be the expected behavior according to the documentation of the function, unless I am misunderstanding it.
Re: [BUG] org-protocol-store-link does not account for argument type
On 27/01/2022 06:02, Thuna wrote: Currently org-protocol-store-link assumes FNAME to be in the old-style. Changing the nil in line 467 of org-protocol.el to (listp fname) fixes the issue. Could you, please, describe your actual problem? I have tried emacsclient 'org-protocol://store-link?url=http://o.rg/&title=Tt1' emacsclient 'org-protocol://store-link:/https:%2F%2Fo2.rg/Tt2' and both links have been stored successfully. There are even some tests for handling of new and old style URIs by store-link subprotocol though they are not run by default.
[BUG] org-protocol-store-link does not account for argument type
Currently org-protocol-store-link assumes FNAME to be in the old-style. Changing the nil in line 467 of org-protocol.el to (listp fname) fixes the issue.
Re: Missing the second '}'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
> John Kitchin writes:
> depending on the file, you may be able to use M-x check-parens. I say
> depending on the file because it matters how the open/close
> marker syntax is defined in the file.
I was able to use M-x check-parens on 3 passes to finally get the
document working properly again. Thanks very much for it.
Thanks
Sharon.
> Or go to the beginning, and run M-x forward-sexp repeatedly until you get an
> error?
>
> John
>
> ---
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
> On Mon, Jan 24, 2022 at 11:02 AM Sharon Kimble
> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi folks.
>
> In a document that I'm compiling I seem to have failed to close the '{'
> and '}', and the second one isn't in the document. If I write '\label{}'
> then it succeeds, but at a couple of places in the document this show
> '\label{'.
>
> How can I find where I've failed to close the brackets please, so that I
> can then achieve normality please?
>
> Thanks
> Sharon.
> - --
- --
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk
Debian 11, fluxbox 1.3.7, emacs 29.0.50, org 9.5.2
-BEGIN PGP SIGNATURE-
iQJRBAEBCgA7FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmHyl6MdHGJvdWRpY2Nh
c0Bza2ltYmxlMDkucGx1cy5jb20ACgkQNoGAGQr4g1tzHQ//fxGDBMWFHO7VTjr6
V6MoU4viVZgoM+cYIKmEmrPqsmIRyisjTkthvgSdme7fE34fnVstIsiXzEvnrc5C
Si+OcbrX/MjSytOfpRcYD1yBZY50MnNy6MyUtWridnGFiU3NfRlwVrkMV3IUPIvr
6fGD/gNkttvThxJzY578mTYNk2VylbyJJmZh2ys7ZwP9/F1E8RSrerO4cFg8/Fw/
KbjqxjazMxkBwIBCottIAyBVucUlbleyNReMzYHzI/OGLn/b0AEgEuDmrH08P8At
IJ2ofIgYz1AdACxL3M3+VZ1vUqNQ+mRIdoxUJ6wS30VMhwL7J8eT8CwW5M6EetAv
pyHxfb9n+wH7KAWKP7lzs+B09eZytETB7W4w6SeN3iU09DWgm6w6Dcu/9bVeqb/m
ie8lS1nO69Cwqgvky9Q1jPv6//J3bJ7khwN4y6Ct9loAEc24Ua6H92cPGWwMAzsa
rEy22KKjkJ1KgRxwtR21xU+IQ3O0Z3OkM+lWESzq5K1I3U40L9iMi5hcU1EQM4cS
gz/HVDemQC7/lWlAS0bIw5WQ4mzrXEiVwkCGpvOJbEr1R7ynmwnivu67Q5dFYKaF
3O1XcDlJLYuZykl0RovhafusLkBT/UUKV3CqkM7gayOeOzpU48IRKdpztDGlU9E0
NE67AP6KkkFiJlZebitmHEBV0hQ=
=Af6r
-END PGP SIGNATURE-
Re: [PATCH] Add support for $…$ latex fragments followed by a dash
Rudolf Adamkovič writes: > Let $r_i$ denote the \(i\)-th rotation of $t$ with a suffix of $\ell|t|$ > characters deleted, for […] > > Me, if I could, I would pay money for this feature, for it would allow > me to use $$ consistently, focusing on mathematics instead of markup > idiosyncrasies of "rotation $i$" versus "\(i\)-th rotation". Would it improve things for you if we change how \(...\) _looks_ in Org buffers? The problem with parsing is more than just supporting $i$-th and similar. For example, AMS style guide explicitly advises against using $i$-th in favour of $i$th [1]: Do not hyphenate “th” expressions: xth, not x-th or xth . We can theoretically make a change to support "-", but then it will be logical to support $i$th as well. (If we don't some users will still be confused after trying to write $i$th and then not getting the expected results). In this question, it would make sense to implement all-or-everything approach. Otherwise, confusion (like raised in this thread) will be inevitable. However, from point of view of Org mode parser, supporting $i$th is a nightmare. Remember that Org mode is _not_ LaTeX and we have to support a lot more frivolous syntax (even in LaTeX, runaway $ is often a source of cryptic compilation errors). Currently, we _must_ rely on heuristics to determine $$-style latex fragments. I do not know any way to support $$ syntax without creating deviations from LaTeX. Extending the heuristics will not resolve the underlying ambiguity of $$ syntax, just hide it within even more obscure cases. Given the raised concerns, may we solve the issue with too verbose \(...\) unambiguous syntax using the following approach: 1. Fontify \(...\) replacing the brackets with a single character. For example: \(...\) -> ⁅...⁆ 2. Provide convenient way to input \(\) brackets through electric-pair-mode or trough org-cdlatex-mode. Best, Ihor [1] https://www.ams.org/publications/authors/AMS-StyleGuide-online.pdf
