Hello,
TEC writes:
> Ok, I think this is everything except for except putting (length
> contents) in a let binding. I don't mind if you edit a let binding
> into the patch, I'm just struggling to overcome a feeling that it's
> a bit silly adding a binding for a short, simple function called
>
Timothy writes:
> Nicolas Goaziou writes:
>
>> Thank you. It looks fine, I will only be nitpicking.
>
> Nitpick away :D
>
>>> +(defun org-edit-latex-fragment ()
>>> + "Edit LaTeX fragment at point."
>>> + (interactive)
>>> + (let* ((context (org-element-context))
>>> +(_ (unless (and
Ok, I think this is everything except for except putting (length
contents) in a let binding. I don't mind if you edit a let binding
into the patch, I'm just struggling to overcome a feeling that
it's a bit silly adding a binding for a short, simple function
called twice.
Let me know if
Nicolas Goaziou writes:
Without hesitation, the first form is nicer. The second one is
just abusing let-binding. I die a little just by looking at it.
I'll make an attempt to avoid killing you then :P
See `rx' macro. S-exp regexps are usually easier to read (after
an initial struggle),
Timothy writes:
> I had a look at that, to me this was cleaner than using multiple let
> bindings, like so
>
> (let ((context ...))
> (unless ... user error)
> (let* ((contents ...)
> (delim-length ...))
>...
>
> vs.
>
> (let* ((context ...)
>(_ (unless ... user error))
Nicolas Goaziou writes:
> Thank you. It looks fine, I will only be nitpicking.
Nitpick away :D
>> +(defun org-edit-latex-fragment ()
>> + "Edit LaTeX fragment at point."
>> + (interactive)
>> + (let* ((context (org-element-context))
>> + (_ (unless (and (eq (org-element-type context)
Hello,
TEC writes:
> ---
> lisp/org-src.el | 45 +
> lisp/org.el | 1 +
> 2 files changed, 46 insertions(+)
Thank you. It looks fine, I will only be nitpicking.
> +(defun org-edit-latex-fragment ()
> + "Edit LaTeX fragment at point."
> +
Nicolas Goaziou writes:
I don't understand what would be the best of HTML email in that
case. You're neither inlining any image, nor using any fancy
presentation. Yet, your email is twice as big as it could be.
HTML is often prettier :P it's also nice to get code blocks with
syntax
Timothy writes:
> I have only a basic working understanding, but my impression was that
> in functioned as a 'best of both worlds' type thing.
I don't understand what would be the best of HTML email in that case.
You're neither inlining any image, nor using any fancy presentation.
Yet, your
>From fc91322e9f8e47484767b66fb9f438d3326ccc08 Mon Sep 17 00:00:00 2001
From: TEC
Date: Sun, 24 May 2020 23:35:33 +0800
Subject: [PATCH] Extend org-edit-special to editing LaTeX-fragments Defines a
new function, `org-edit-latex-fragment' which is hooked into
`org-edit-special', modifying
Nicolas writes:
>> <#multipart type=alternative><#part type=text/plain>
>
> Please don't send HTML.
Appologies, I'm trying to use org-msg for emails, which should be off
for replying to plaintext, but I seem to have odd things happen now and
then ... as you have noticed.
So, I'm trying to
TEC writes:
> <#multipart type=alternative><#part type=text/plain>
Please don't send HTML.
> Inline LaTeX, and Environments are indeed different. I failed to consider that
> there may be additional complications if switching an inline environment to an
> environment. Quite frankly I’m not too
Nicolas Goaziou writes:
That would be undesirable. LaTeX fragments (inline type) and
LaTeX environments (block type) are different beasts. This is
clearly outside the scope of `org-edit-special' to move from one
type to the other.
Inline LaTeX, and Environments are indeed different. I
Nicolas Goaziou writes:
This is the following part, in `org-edit-footnote-reference':
Thanks. Sorry I'm having you repeat yourself.
Replacing "\n" with "", as above, is too strong BTW. It would be
better to replace it with " ". I'll fix the footnote-reference
part.
Sounds sensible.
TEC writes:
> This is what I thought. Might you have any suggestions on how
> I incorporate this logic? Something like `org-in-table-p' would be
> ideal :D
This is the following part, in `org-edit-footnote-reference':
--8<---cut here---start->8---
;; If
Nicolas Goaziou writes:
Just saying 'no' to new lines seems like a possible solution,
but long equations can often be deperate for newlines when it
comes to readability.
Saying no to new lines is only necessary in tables. Outside, we
only need to say no to blank lines.
This is what I
TEC writes:
> Just saying 'no' to new lines seems like a possible solution, but long
> equations can often be deperate for newlines when it comes to
> readability.
Saying no to new lines is only necessary in tables. Outside, we only
need to say no to blank lines.
Note that you cannot preserve
TEC writes:
> Thinking about this a bit more, I think this may not actually be desirable
> behaviour.
>
> Why? I considered the case where I’ve been writing a growing inline equation
> \( \),
> realised it should be displayed as an equation instead with \[ \] and edited
> the
> LaTeX marks
Nicolas Goaziou writes:
It seems you're mixing inline source blocks and LaTeX fragment.
You
modified the former, but not the latter.
Ooops, I'll fix that.
+ (lambda () ; trim content
+ (goto-char (point-min))
This is not needed. The function is always called at
`point-min'.
TEC writes:
> - (end (progn (goto-char (org-element-property :end datum))
> - (search-backward "}" (line-beginning-position) t
> + (end (org-with-point-at (org-element-property :end datum)
> + (skip-chars-backward " \t")
> +
Nicolas Goaziou writes:
I don’t think we need to worry about newlines,
We need to.
| some | table| | LaTeX | $1 + 1$ |
Oh dear, I haden't considered that. This is beginning to sound
complicated :sweat_smile:
Just saying 'no' to new lines seems like a possible solution, but
TEC writes:
> Nicolas Goaziou writes:
>> LaTeX fragments should not break paragraphs, or tables. So you need to
>> prevent inserting blank lines, or even newlines characters in the case
>> of tables.
>
> I don’t think we need to worry about newlines,
We need to.
| some | table|
|
I've had another thought :)
Nicolas Goaziou writes:
The equivalent code will prevent a user from changing, deleting
the LaTeX markers, or writing past them : this is not the
purpose of the functionality.
That's most helpful, thanks :)
I'l have a look at that now, in the mean time here's
One other quick comment
Nicolas Goaziou writes:
LaTeX fragments should not break paragraphs, or tables. So you
need to
prevent inserting blank lines, or even newlines characters in
the case
of tables.
I don't think we need to worry about newlines, particularly as
this only applies
to
>From 748c20d65df9cd0ae9f9f80c2bb5ee87aea101e4 Mon Sep 17 00:00:00 2001
From: TEC
Date: Sun, 24 May 2020 23:35:33 +0800
Subject: [PATCH] Extend org-edit-special to editing LaTeX-fragments Defines a
new function, `org-edit-latex-fragment' which is hooked into
`org-edit-special', modifying
TEC writes:
> I’m trying to work out what it is that should be happening with this. Looking
> at
> `org-edit-footnote-reference’, as you pointed me to, and
> `org-edit-inline-src’:
>From `org-edit-footnote-reference':
--8<---cut here---start->8---
Nicolas Goaziou writes:
You also need to put read-only property on fragment markers, and
remove any blank line as the final step. See
`org-edit-footnote-reference'.
I'm trying to work out what it is that should be happening with
this. Looking at `org-edit-footnote-reference', as you
Hello,
TEC writes:
> I thought that too initially. The think is you actually want them in the LaTeX
> buffer so they get treated as mathematics instead of text.
Indeed!
Still, END is not correct, because it includes white space after the
object. So, you probably need something like:
(end
Nicolas Goaziou writes:
Hello,
Timothy writes:
Well that didn't quite work as intended. Here's a take two.
This doesn't look bad. Thank you.
In the commit message, you need to list functions being
modified. See other commits messages for some examples.
I'll patch my patch :P
+
Hello,
Timothy writes:
> Well that didn't quite work as intended. Here's a take two.
This doesn't look bad. Thank you.
> From 379e23545d7e55766e48b50514bd797bdf691a40 Mon Sep 17 00:00:00 2001
> From: TEC
> Date: Sun, 24 May 2020 23:35:33 +0800
> Subject: [PATCH] Extend org-edit-special to
> <#part type=“text/x-patch”
> filename=“home/tec.emacs.d/.local/straight/repos/org-mode/0001-Extend-org-edit-special-to-editing-LaTeX-fragments.patch”
> disposition=attachment>
> <#/part>
Well that didn't quite work as intended. Here's a take two.
>From 379e23545d7e55766e48b50514bd797bdf691a40 Mon Sep 17 00:00:00 2001
From: TEC
Date: Sun, 24 May 2020 23:35:33 +0800
Subject: [PATCH] Extend org-edit-special to editing LaTeX-fragments
---
lisp/org-src.el | 19 +++
lisp/org.el | 1 +
2 files changed, 20 insertions(+)
Bastien writes:
I hope you will have time to move forward with sending patches
so that we can discuss the feature proposals against something
we can actually test.
Well, I'm currently having a look at patching this, so this looks
hopeful :)
I think I've got a mostly-functional
tecos...@gmail.com writes:
> Don't worry, I haven't faded out of exitance!
Well, I was not worried :)
> I've also now completed the FSF copyright assignment. Let me know if
> you need any details on that front.
If you confirm that the FSF confirmed that you're all set, then no.
> I'm yet to
Bastien writes:
I hope you will have time to move forward with sending patches
so that
we can discuss the feature proposals against something we can
actually
test.
Thanks again,
Don't worry, I haven't faded out of exitance! I've merely become
(as usual)
distracted. In this case I've
Hi Timothy,
thanks for the various feature requests! It's always interesting to
discuss use cases and possible features.
Timothy writes:
> I'm also a uni student a few weeks off from exams so I am not able to
> really need to resist the urge to jump in and work on implementing
> these ideas.
Nicolas Goaziou writes:
> I already did, didn't I?
> ...
> That's all for the changes required in `org-edit-special'.
Oh ':) I thought that was just you saying 'it would be something along
the lines of...'
Thanks! I'll let you know when I have something.
> Timothy writes:
>
>> In your
Timothy writes:
> In your original email you wrote
> The new function can then be installed in `org-edit-special' from
> "org.el"
>
> I can't quite see how I would insert this. Since it sounds relatively
> simple, if you would be willing to cook up the necessary modification
> for me
Nicolas Goaziou writes:
>> I see. Might you be willing to do & show me the modifications needed to
>> use the `latex-fragment case?
> I don't understand your question.
In your original email you wrote
The new function can then be installed in `org-edit-special' from
"org.el"
I can't
Timothy writes:
> I see. Might you be willing to do & show me the modifications needed to
> use the `latex-fragment case?
I don't understand your question.
Nicolas Goaziou writes:
> LaTeX fragments are at a lower level than plain "elements", so
> `org-element-at-point' does not see them.
I see. Might you be willing to do & show me the modifications needed to
use the `latex-fragment case?
>> Can I really get away without modifying anything more
Timothy writes:
>> It sounds like you took the opposite route. I suggested to first write a
>> function, `org-edit-latex-fragment'.
> I wanted to see how it would fit in first ¯\_(ツ)_/¯
Sure. That's a good way to learn stuff. In this case, it's not the
easiest one, though.
>> Once done, you
Hello All!
I love the first-class LaTeX support in Org-mode, and discovering that
org-edit-special worked inside LaTeX environments was a joyous moment for me.
Shortly after that though, I was disappoint to discover that this didn't work
with inline LaTeX equations \( … \) or LaTeX display
Nicolas,
> It sounds like you took the opposite route. I suggested to first write a
> function, `org-edit-latex-fragment'.
I wanted to see how it would fit in first ¯\_(ツ)_/¯
> Once done, you can insert it in `org-edit-special', but it boils down to
> adding a line there, right below
Timothy writes:
> With your comments in mind I started by looking at org-edit-special,
> and managed to get as far as org-element--current-element: but at this
> point I'm stumped.
It sounds like you took the opposite route. I suggested to first write
a function, `org-edit-latex-fragment'.
Hi Nicolas,
Thanks for the pointers. Taking your hint :P I took a look to see what I might
be in for.
With your comments in mind I started by looking at org-edit-special, and
managed to get as far as org-element--current-element: but at this point I'm
stumped.
I'll look into getting FSF
Hello,
Timothy writes:
> I love the first-class LaTeX support in Org-mode, and discovering that
> org-edit-special worked inside LaTeX environments was a joyous moment for me.
> Shortly after that though, I was disappoint to discover that this
> didn't work with inline LaTeX equations \( … \)
Hello All!
I love the first-class LaTeX support in Org-mode, and discovering that
org-edit-special worked inside LaTeX environments was a joyous moment for me.
Shortly after that though, I was disappoint to discover that this didn't work
with inline LaTeX equations \( … \) or LaTeX display
48 matches
Mail list logo
