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 overflo
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 72
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 diverg
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
betwe
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 ch
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 dang
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 inst
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 us
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 b
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 cont
> 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 o
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
im
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
\(n\)-
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