Rudolf Adamkovič writes:
> João Pedro de Amorim Paula writes:
>
>> On 01 February 2022 22:00, Rudolf Adamkovič wrote:
>>
>>> Me, I cannot use any of these "pretty" features because, simply put,
>>> they break plain text. For example, they cause misaligned tables and
>>> make the text
João Pedro de Amorim Paula writes:
> On 01 February 2022 22:00, Rudolf Adamkovič wrote:
>
>> Me, I cannot use any of these "pretty" features because, simply put,
>> they break plain text. For example, they cause misaligned tables and
>> make the text overflow the fill column, which I keep at
On 01 February 2022 22:00, Rudolf Adamkovič wrote:
> Me, I cannot use any of these "pretty" features because, simply put,
> they break plain text. For example, they cause misaligned tables and
> make the text overflow the fill column, which I keep at 72 columns.
I know that this is a bit
Ihor Radchenko writes:
> We can theoretically make a change to support "-", but then it will be
> logical to support $i$th as well. […]
I do not know about others, but supporting the dash alone would mean a
world to me. In fact, I never use \(\) for anything else in all my Org
documents. That
manual states:
Text within the usual LaTeX math delimiters. To avoid conflicts with
currency specifications, single ‘$’ characters are only recognized as
math delimiters if the enclosed text contains at most two line breaks,
is directly attached to the ‘$’ characters with no whitespace in
On 28/01/2022 23:37, Timothy wrote:
There is no point to discuss deprecation of $…$ and ... while usage of
such constructs is not discouraged by the org manual
Isn’t the point of discussing depreciation now that we’d change the manual etc.
to discourage it?
It is funny that nobody have
Hi Max,
> There is no point to discuss deprecation of $…$ and ... while usage of
> such constructs is not discouraged by the org manual
Isn’t the point of discussing depreciation now that we’d change the manual etc.
to discourage it?
FWIW, I have an extra 2c to add: I think that there’s a
On 28/01/2022 02:15, Tim Cross wrote:
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
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
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
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
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
[...]
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
> The change is local and minor.
We can't know that. Consider for example someone that has
the following line somewhere in their files.
#+begin_src org
I spent $20 on food and was paid$-10 dollars by friends so
I am down $10.
#+end_src
Yes =paid$-10= is probably a typo that should have a space
in
Hi,
Tom Gillespie writes:
Unfortunately this falls into the realm of changes to syntax. The current
behavior is not a bug and is working as specified because hyphen minus
(U+002D) does not count as punctuation for the purposes of org syntax.
We should specify which chars count as punctuation in
Eric S Fraga writes:
> But is not necessary (and further complicates the issue of support
> $...$ in org as recently discussed on this list) as you can simply
> type \(n\)-th?
What you call "not necessary", I call a game changer. As of now, one
has to mix and match $$ and \(\) based on the
> The attached patch adds support for $…$ latex fragments followed by a
> dash, such as $n$-th.
Unfortunately this falls into the realm of changes to syntax. The current
behavior is not a bug and is working as specified because hyphen minus
(U+002D) does not count as punctuation for the purposes
On a personal note, I would be very happy to see this patch merged. It has
been annoying me for years, see for instance this thread:
https://emacs.stackexchange.com/questions/37207/org-latex-fragment-succeeded-by-a-dash-is-not-showing
Goran
Hi,
Eric S Fraga writes:
But is not necessary (and further complicates the issue of support $...$
in org as recently discussed on this list) as you can simply type
\(n\)-th?
What complication are you referring to, precisely ?
The patch is fairly trivial, and a similar extension was already
On Monday, 24 Jan 2022 at 16:42, Sébastien Miquel wrote:
> The attached patch adds support for $…$ latex fragments followed by a
> dash, such as $n$-th.
But is not necessary (and further complicates the issue of support $...$
in org as recently discussed on this list) as you can simply type
Hi,
The attached patch adds support for $…$ latex fragments followed by a
dash, such as $n$-th.
This pattern is quite common, and the issue was mentionned by Rudolf
Adamkovič, here: https://list.orgmode.org/m2mtjvefrf@me.com/.
This extension of the syntax doesn't conflict with the use of
21 matches
Mail list logo
