Re: About 'inline special blocks'
On Tuesday, 24 May 2022 at 10:51, Timothy wrote: > To me, this is another reason for comment and #+attr_X lines not to > break paragraphs [...]. And, in fact, if this were true (which I would like), I personally would see no reason for having inline special blocks. Just my 2¢. -- : Eric S Fraga, with org release_9.5.3-511-g8e69ad in Emacs 29.0.50
Re: About 'inline special blocks'
Hi Tim,
Tim Cross writes:
>> But that is an abuse of direct formatting, which I think should always be
>> avoided, especially in a format-agnostic environment like Org, which is
>> more of a logician than a typesetter :-)
>
> I think this is a really important point. Whenever we add formatting
> specific directives, we always end up in a somewhat uncertain situation
> with respect to the other back ends. I also feel that in-line blocks
> which support large and complex formatting configuration really defeat
> the purpose of an in=line block (which I feel should be kept relatively
> simple). I also find complex constructs of this form really degrades the
> readability of source documents.
To me, this is another reason for comment and #+attr_X lines not to break
paragraphs, as then we can just re-use #+attr_X lines.
E.g.
┌
│ Hi there look at
│ #+attr_X: :prop val
│ inline_mark{some content}
│ and now continuing the paragraph...
└
As mentioned previously, this would also be rather nice for comments in
paragraphs and also applying attributes to a link in a paragraph, i.e.
┌
│ I'm a big fan of the
│ #+attr_html: :title Visit the Org homepage
│ [[https://orgmode.org/][Org]]
│ project.
└
All the best,
Timothy
Re: About 'inline special blocks'
Tim Cross writes:
>> I think a major issue would also be how to properly compact <[options]>
>> so as not to result in too overloaded syntax. Maybe something like:
>>
>> [latex(list of attributes) html(list of attributes)...]
>>
>> ?
>>
>> But that is an abuse of direct formatting, which I think should always be
>> avoided, especially in a format-agnostic environment like Org, which is
>> more of a logician than a typesetter :-)
>
> I think this is a really important point. Whenever we add formatting
> specific directives, we always end up in a somewhat uncertain situation
> with respect to the other back ends. I also feel that in-line blocks
> which support large and complex formatting configuration really defeat
> the purpose of an in=line block (which I feel should be kept relatively
> simple). I also find complex constructs of this form really degrades the
> readability of source documents.
I think that we might simply allow to define complex configuration
before the containing paragraph. Something like:
#+attr_latex[name]:
Vestibulum convallis, lorem blockname_[<>]{text} a tempus semper, dui
dui euismod elit, vitae placerat urna tortor vitae lacus.
"<>" will be treated as "" during
export/parsing.
I am purposely reusing #+keyword[secondary] and <> syntax to keep
things similar to other existing elements.
Best,
Ihor
Re: problem with unwanted strikeout in src blocks
Uwe Brauer writes:
> However when I wrap a solutionorbox around it (which I need when
> exporting to latex) all text between the «+»
> gets a strikeout.
>
>
> #+begin_solutionorbox
> #+begin_src matlab :exports results :eval never-export :results output latex
> disp('P(\text{Covid19}|\text{+})&=\frac{P(\text{+}|\text{Covid19})P(\text{Covid19})}{P(\text{+}|\text{Covid19})P(\text{Covid19})+P(\text{+}|\text{No-Covid19})P(\text{No-Covid19})}\\')
> #+end_src
> #+end_solutionorbox
>
> And idea what to do?
This is a known bug in Org fontification. The fix is not trivial. WIP.
See https://orgmode.org/list/87ee7c9quk.fsf@localhost
Current development version of the fix is in
https://github.com/yantar92/org/tree/feature/org-font-lock-element, but
it is not yet complete and will require a lot more work.
Note that other than the visual appearance, your code block is not
affected. That is, export will work just fine. No strike-through will
be present.
Best,
Ihor
Re: About 'inline special blocks'
I've not got a lot to add here. I'm not against the idea, but Juan makes
some points below which I think are particularly important and wanted to
add weight to them!
Juan Manuel Macías writes:
> Hi, Kaushal, thanks for all your interesting comments,
>
> Kaushal Modi writes:
>
>> The challenging part will be deciding the syntax so that there are no
>> false matches.
>>
>> May be reserve "inline_" for inline blocks?
>>
>> e.g. inline_[options]{text} ?
>
> It seems to me the most consistent option, if we continue in some way
> the syntax of the inline code blocks, which would be the close relatives
> of the inline special blocks. Perhaps (to shorten the syntax a bit)
> 'inline' could be replaced by some reserved symbol. Something like:
>
> &_[options]{text}
>
I agree. Selection of the 'symbol' might be tricky, but the idea is
sound.
> I think a major issue would also be how to properly compact <[options]>
> so as not to result in too overloaded syntax. Maybe something like:
>
> [latex(list of attributes) html(list of attributes)...]
>
> ?
>
> But that is an abuse of direct formatting, which I think should always be
> avoided, especially in a format-agnostic environment like Org, which is
> more of a logician than a typesetter :-)
I think this is a really important point. Whenever we add formatting
specific directives, we always end up in a somewhat uncertain situation
with respect to the other back ends. I also feel that in-line blocks
which support large and complex formatting configuration really defeat
the purpose of an in=line block (which I feel should be kept relatively
simple). I also find complex constructs of this form really degrades the
readability of source documents.
>
> And, in any case, it is to be expected that the user will not need to
> overload that part, since these hypothetical inline blocks would be
> intended for short segments of text within the paragraph. I think the
> most typical use case would be something like your 'mark' example.
>
Yes, that was my thinking as well.
Re: About 'inline special blocks'
Hi, Kaushal, thanks for all your interesting comments,
Kaushal Modi writes:
> The challenging part will be deciding the syntax so that there are no
> false matches.
>
> May be reserve "inline_" for inline blocks?
>
> e.g. inline_[options]{text} ?
It seems to me the most consistent option, if we continue in some way
the syntax of the inline code blocks, which would be the close relatives
of the inline special blocks. Perhaps (to shorten the syntax a bit)
'inline' could be replaced by some reserved symbol. Something like:
&_[options]{text}
I think a major issue would also be how to properly compact <[options]>
so as not to result in too overloaded syntax. Maybe something like:
[latex(list of attributes) html(list of attributes)...]
?
But that is an abuse of direct formatting, which I think should always be
avoided, especially in a format-agnostic environment like Org, which is
more of a logician than a typesetter :-)
And, in any case, it is to be expected that the user will not need to
overload that part, since these hypothetical inline blocks would be
intended for short segments of text within the paragraph. I think the
most typical use case would be something like your 'mark' example.
Best regards,
Juan Manuel
Re: problem with unwanted strikeout in src blocks
Hello Uwe
> On Monday, 23 May 2022 at 19:24, Uwe Brauer wrote:
Sorry I don't have matlab and I have never used the solutionorbox
environment, but I believe you can generate latex directly. For example
with R I can to the following.
#+begin_src R :exports results :eval yes :results output latex
cat("\\begin{align*}")
cat("P(\\text{Covid19}|\\text{ + })&=\\frac{P(\\text{ +
}|\\text{Covid19})P(\\text{Covid19})}{P(\\text{ + } |
\\text{Covid19})P(\\text{Covid19}) + P(text{ +
}|\\text{No-Covid19})P(\\text{No-Covid19})}")
cat("\\end{align*}")
#+end_src
With the :post keyword so that you can wrap pretty much anything.
(info "(org) Results of Evaluation")
Consider
#+NAME: box
#+BEGIN_SRC emacs-lisp :var equation=""
(format "begin{solutionorbox}
%s
end{solutionorbox}" equation )
#+end_src
#+begin_src R :exports results :eval yes :results output latex :post
box(*this*)
cat("\\frac{3}{4}")
#+end_src
#+RESULTS:
#+begin_export latex
\\begin{solutionorbox}
\frac{3}{4}
\\end{solutionorbox}
#+end_export
HTH,
Jeremie
Re: Help with my first elisp
On Mon, May 23, 2022 at 09:46:09AM -0700, Greg Minshall wrote: > Ypo, > > > (defun salto () > > (interactive) > > (if posicion 1 You are comparing the value of posicion to 1? Then it should probably be "(if (= posicion 1) ...)" or "(if (equal posicion 1) ...)" or something like that. Cheers -- t signature.asc Description: PGP signature
problem with unwanted strikeout in src blocks
Hi
The following code block is nicely displayed
#+begin_src matlab :exports results :eval never-export :results output latex
disp('P(\text{Covid19}|\text{+})&=\frac{P(\text{+}|\text{Covid19})P(\text{Covid19})}{P(\text{+}|\text{Covid19})P(\text{Covid19})+P(\text{+}|\text{No-Covid19})P(\text{No-Covid19})}\\')
#+end_src
However when I wrap a solutionorbox around it (which I need when
exporting to latex) all text between the «+»
gets a strikeout.
#+begin_solutionorbox
#+begin_src matlab :exports results :eval never-export :results output latex
disp('P(\text{Covid19}|\text{+})&=\frac{P(\text{+}|\text{Covid19})P(\text{Covid19})}{P(\text{+}|\text{Covid19})P(\text{Covid19})+P(\text{+}|\text{No-Covid19})P(\text{No-Covid19})}\\')
#+end_src
#+end_solutionorbox
And idea what to do?
Thanks
Uwe Brauer
--
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine.
Re: Help with my first elisp
Ypo, > (defun salto () > (interactive) > (if posicion 1 > (posicion2) > (if posicion 2 > (posicion3) > (if posicion 3 > (posicion1) your function =salto= may be using =if= incorrectly. try marking that =defun= and hitting TAB to justify it. my guess is, that's not what you want. > ;; (define-key global-map (kbd "SPC") #'salto) > (local-set-key "j" 'posicion1) > (local-set-key "k" 'posicion2) > (local-set-key "l" 'posicion3) > )) maybe use something like >> (define-key mh-letter-mode-map >> (kbd "C-c s") >> 'ggm-mh-sentaddrs-completion) but, using whatever the name of the logos-focus mode map, pointing at your functions? cheers, Greg
Re: Bug in 9.5.3 org--file-default-apps
Craig, discussing the issue with Ihor, I sent some messages to the mail list only without your address in Cc. You may check complete thread at https://list.orgmode.org On 23/05/2022 19:40, Craig STCR wrote: OK, I did a first-try on this and was unsuccessful, but I'm sure it's user error. I need to refresh my knowledge on how to customize user-local mime database, and that will write-out a new ~/.mailcap, etc, I think? I've done it before, but it was awhile ago, and I wasn't paying attention to ~/.mailcap when I did it. I know for Gnome I can create a .desktop file. But I know there's a way to customize user-local mime database without Gnome desktop. I'll take a closer look when I have a little more time. Debian package scripts (that work on Ubuntu as well) extract MIME info from *system* .desktop files to add them to mailcap database. There were some mailcap related changes and bugs around Emacs-27 release, e.g. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36771 application/x-shellscript; emacs27 %s; test=test -n "$DISPLAY" Notice that such entry will be ignored when DISPLAY is not set due to specified "test" property. You need to pass X socket and pass or set DISPLAY environment to you "headless" container. update-mime likely assumes that you created ~/.mailcap.order to generate ~/.mailcap from it. Emacs may just read ~/.mailcap, so if you created this file, nothing more is required. Actually I do not think you wish to launch another emacs session in response to following a link in an .org file. I suppose, you experienced https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40247 otherwise (mailcap-mime-info nil) (or "text/plain") would return view-mode and your scripts would be opened in another emacs window. It should work without mailcap entries.
Re: About 'inline special blocks'
On Mon, May 23, 2022 at 10:33 AM Juan Manuel Macías
wrote:
> I think this idea was suggested by Ihor in a thread from a few months
> ago (I don't remember which one), but since other topics were discussed,
> the idea remained a bit in limbo. I still find the idea very
> interesting, and I think it would be very productive for Org to have a
> multipurpose inline container, so it occurred to me to open this thread
> to invite a possible discussion on the subject.
Thanks for doing this. I missed that thread. I would welcome this
feature addition too.
If I understand correctly, this will mean adding a new element type
that all the Org exporters can then support. Right?
> The question is: Does Org Mode need inline special blocks?
Yes.
> On the one hand, it seems that we can live without them.
Not quite. I developed few hacks in ox-hugo to make regular special
blocks act like special inline blocks :D
Example:
=
More than the visual inaccuracy of seeing curved quoted where straight
quotes should be,
#+begin_mark
if someone copies that code to try it out, it will
not work
#+end_mark
!
=
Another example:
=
By the way, I submitted a patch for fixing the escaping of straight
quotes in ~shortdoc-add-function~ documentation string
#+begin_sidenote
I planned to fix just this straight quote escaping issue, but then I
also ended up slightly improving the documentation of the ~(FUNC :eval
EVAL)~ and other forms used for adding a function's documentation to
~shortdoc~.
#+end_sidenote
in ..
=
ox-hugo does the job of deleting the newlines and white-space (leaving
just 1) before and after few "special" special Org blocks.
> Therefore, I think that inline special blocks would fill an important
> gap. They could be translated into HTML as a container;
+1
> Perhaps the syntax could be a continuation of that of inline code
> blocks. Something like:
>
> _[options]{text}
The challenging part will be deciding the syntax so that there are no
false matches.
May be reserve "inline_" for inline blocks?
e.g. inline_[options]{text} ?
Using my example above, if I want the elements in HTML, I would do
abc inline_mark{some text} def
and that would export to below for an HTML based exporter:
abc some text def
Re: Bug in 9.5.3 org--file-default-apps
On 5/23/22 10:14 AM, Craig STCR wrote: >$ run-mailcap myscript it invokes emacs. Yay! It works! Double DOH! Forget what I said. It invokes vim, lol. That *is* what I would expect. Sorry for the noise. I need to think a little more before I hit .
About 'inline special blocks'
Hi all,
I think this idea was suggested by Ihor in a thread from a few months
ago (I don't remember which one), but since other topics were discussed,
the idea remained a bit in limbo. I still find the idea very
interesting, and I think it would be very productive for Org to have a
multipurpose inline container, so it occurred to me to open this thread
to invite a possible discussion on the subject.
I suppose it would have been more practical to start the thread directly
proposing a patch, but since it is about adding a new element to Org,
which is not trivial, I thought that maybe it would be more convenient
to have a previous discussion and poll the users' and developers opinion.
The question is: Does Org Mode need inline special blocks? On the one
hand, it seems that we can live without them. Macros and links can work
competently for this purpose. But macros have the drawback of the comma
as an escape character; and links also have its drawbacks, although the
org-link-set-parameters function is very versatile. And even a huge fan
of links like me can recognize these limitations :-). For example, we
cannot put a footnote inside a link.
Therefore, I think that inline special blocks would fill an important
gap. They could be translated into HTML as a container; to
odt as character styles or to LaTeX as commands with arguments. And they
would open the doors to a real solution for multilingual support in Org.
Perhaps the syntax could be a continuation of that of inline code
blocks. Something like:
_[options]{text}
And in options include some 'jibarized' version of attr_latex,
attr_html, etc.
Well, I don't know if I have managed to sell the product well or if I
have been too abstract :-)
Best regards,
Juan Manuel
Re: Bug in 9.5.3 org--file-default-apps
Everything I mentioned so far has been my Bionic desktop. Which, incidentally was an upgrade from Xenial, not a clean install. But... in my Focal headless container, if I run: >$ run-mailcap myscript it invokes emacs. Yay! It works! DISPLAY, EDITOR, and VISUAL are all unset or empty. There's nothing in /etc/mailcap for emacs, and what *IS* in /etc/mailcap is (amongst others of course): application/x-shellscript; vim %s; needsterminal So I really need to spend some time reading man pages about mailcap, mime, etc because that's not what I would expect, and I'm really confused. On 5/23/22 8:59 AM, Craig STCR wrote: I guess maybe I should have given a little better description of what I tried that did NOT work? But it's a little off-topic for this mailing list. Nevertheless, here it is... I created a ~/.mailcap file and put this in it, which I cut and pasted from /etc/mailcap: application/x-shellscript; emacs27 %s; test=test -n "$DISPLAY" But obviously that's not going to change anything, since it's already in the system mailcap file, /etc/mailcap. DOH! And sure enough, running '>$ run-mailcap myscript' invokes 'less'. But what I wasn't expecting is that running '>$ update-mime -- local' gives me: "Error: '/home/user/.mailcap' is not in required format -- not updated". Not sure why I'm getting that when I cut-and-pasted from /etc/mailcap. No worries. I'll look in more depth later. On 5/23/22 8:40 AM, Craig STCR wrote: Thanks all for your help! On 5/20/22 9:44 PM, Ihor Radchenko wrote: Dear Craig, ... or provide plain/text handler in ~/.mailcap. OK, I did a first-try on this and was unsuccessful, but I'm sure it's user error. I need to refresh my knowledge on how to customize user-local mime database, and that will write-out a new ~/.mailcap, etc, I think? I've done it before, but it was awhile ago, and I wasn't paying attention to ~/.mailcap when I did it. I know for Gnome I can create a .desktop file. But I know there's a way to customize user-local mime database without Gnome desktop. I'll take a closer look when I have a little more time. On 5/20/22 9:44 PM, Ihor Radchenko wrote: However, I am not sure what to do on Windows/Mac. Maybe try a quick-and-dirty, cross-platform solution that checks non-binary files for a first-line shebang? Could use existing Emacs hooks that determine major-mode when opening files. Again, thanks all for your help! Best, -Craig
Re: Bug in 9.5.3 org--file-default-apps
I guess maybe I should have given a little better description of what I tried that did NOT work? But it's a little off-topic for this mailing list. Nevertheless, here it is... I created a ~/.mailcap file and put this in it, which I cut and pasted from /etc/mailcap: application/x-shellscript; emacs27 %s; test=test -n "$DISPLAY" But obviously that's not going to change anything, since it's already in the system mailcap file, /etc/mailcap. DOH! And sure enough, running '>$ run-mailcap myscript' invokes 'less'. But what I wasn't expecting is that running '>$ update-mime -- local' gives me: "Error: '/home/user/.mailcap' is not in required format -- not updated". Not sure why I'm getting that when I cut-and-pasted from /etc/mailcap. No worries. I'll look in more depth later. On 5/23/22 8:40 AM, Craig STCR wrote: Thanks all for your help! On 5/20/22 9:44 PM, Ihor Radchenko wrote: Dear Craig, ... or provide plain/text handler in ~/.mailcap. OK, I did a first-try on this and was unsuccessful, but I'm sure it's user error. I need to refresh my knowledge on how to customize user-local mime database, and that will write-out a new ~/.mailcap, etc, I think? I've done it before, but it was awhile ago, and I wasn't paying attention to ~/.mailcap when I did it. I know for Gnome I can create a .desktop file. But I know there's a way to customize user-local mime database without Gnome desktop. I'll take a closer look when I have a little more time. On 5/20/22 9:44 PM, Ihor Radchenko wrote: However, I am not sure what to do on Windows/Mac. Maybe try a quick-and-dirty, cross-platform solution that checks non-binary files for a first-line shebang? Could use existing Emacs hooks that determine major-mode when opening files. Again, thanks all for your help! Best, -Craig
Re: Bug in 9.5.3 org--file-default-apps
Thanks all for your help! On 5/20/22 9:44 PM, Ihor Radchenko wrote: Dear Craig, ... or provide plain/text handler in ~/.mailcap. OK, I did a first-try on this and was unsuccessful, but I'm sure it's user error. I need to refresh my knowledge on how to customize user-local mime database, and that will write-out a new ~/.mailcap, etc, I think? I've done it before, but it was awhile ago, and I wasn't paying attention to ~/.mailcap when I did it. I know for Gnome I can create a .desktop file. But I know there's a way to customize user-local mime database without Gnome desktop. I'll take a closer look when I have a little more time. On 5/20/22 9:44 PM, Ihor Radchenko wrote: However, I am not sure what to do on Windows/Mac. Maybe try a quick-and-dirty, cross-platform solution that checks non-binary files for a first-line shebang? Could use existing Emacs hooks that determine major-mode when opening files. Again, thanks all for your help! Best, -Craig
Re: [PATCH] Re: No mathematics in Texinfo exports
Rudolf Adamkovič writes: > FYI, I did receive a reply after the follow-up mail. I signed the papers and > sent them back to FSF just now. I will revive the thread once FSF does its > part. Hopefully, I will not wait for yet another (third) month. :) Do not wait one month. Just 5 working days. Then, do not hesitate to follow up. Best, Ihor
Re: [PATCH] Re: No mathematics in Texinfo exports
Rudolf Adamkovič writes: > Ihor Radchenko writes: > >> Sorry for this delay. Then, can you send them a followup email reminder? >> If they do not reply within another week, we will contact FSF directly. > > Thank you. I sent a followup email just now, FYI. FYI, I did receive a reply after the follow-up mail. I signed the papers and sent them back to FSF just now. I will revive the thread once FSF does its part. Hopefully, I will not wait for yet another (third) month. :) Rudy -- "Programming reliably -- must be an activity of an undeniably mathematical nature […] You see, mathematics is about thinking, and doing mathematics is always trying to think as well as possible." -- Edsger W. Dijkstra, 1981 Rudolf Adamkovič [he/him] Studenohorská 25 84103 Bratislava Slovakia
Re: Default attributes for images in beamer export
Hi Eric, > But given that you also want to keep the aspect ratio, I am curious as > to why you would need/want to specify both? Just on this, the `keepaspectratio' option of `graphicx' could be relevant here. All the best, Timothy
bug#45915: 28.0.90; deletechar distorts org-table
Tak Kunihiro writes: > I still see the problem with GNU Emacs 29.0.50 (build 8, > x86_64-apple-darwin21.5.0, NS appkit-2113.50 Version 12.4 (Build 21F79)) > of 2022-05-23 with org-version 9.5.3. > > I create org-tables and revise these everyday. On duplication of a > cell, I hit S- often. The problem occurs, with my use case, once > in 5 minutes. IOW point moves unexpectedly once in 5 minutes. To clarify, I haven't applied the patch onto Org upstream. Before the patch, the table is distorted because of an omission in Org. After the patch, the table is distorted only using your reproducer specifically, and the issue appears to be on Emacs side. Best, Ihor
Re: Default attributes for images in beamer export
On Friday, 20 May 2022 at 20:18, ed...@openmail.cc wrote: > Is this the expected behaviour? Thanks again :) . Well, looking at the code, if any of the :height or :width attributes have been specified explicitly, the defaults for height and width are ignored. If you want to specify both, you will need to do so explicitly. But given that you also want to keep the aspect ratio, I am curious as to why you would need/want to specify both? -- : Eric S Fraga, with org release_9.5.3-508-ge268e4 in Emacs 29.0.50
Re: Question Regarding Easier Issues To Help With
"Samuel Banya" writes: > Hey there, > So I took a look at the following link recently as I finally have had time > again over the past couple of months since I've been dealing with a lot of > personal family stuff, and got some time back again. Thanks for your interest in contributing! > Can anyone lead me in the right direction for some beginner tier issues to > take a look at, as well as hand holding for any workflow on how to actually > work on the related issue / source code accordingly: > https://updates.orgmode.org/#help Here is a list that might be helpful. Not all the issues are easy there. Mostly, something I quickly judged as easy/important or unanswered. Also, there are not only bug reports, but also patches that someone needs to test with various edge cases. https://orgmode.org/list/UT6T2iOXtO0dMWc5QA4ZPbG0yh-4wOprgsHAe91c_wf7DwDKdLoJilTWK50rJuz8cNxtwrlTc_CpQIGBpQixTjDPnCJfq-WQKhk4oFLed_I=@protonmail.com https://orgmode.org/list/ty2pr0101mb3693187b93665e208637f6c8da...@ty2pr0101mb3693.apcprd01.prod.exchangelabs.com https://orgmode.org/list/ca+3amhehg_tgcmz1mmy0hpsaw3hqokpnfcjboaozzaxnjcz...@mail.gmail.com https://orgmode.org/list/87imnypcvk@iki.fi https://orgmode.org/list/87mu3djf4u@gmail.com https://orgmode.org/list/87woky8sam@norang.ca https://orgmode.org/list/cajcao8t_sfascks4fovnbt5rrsivfr1z15jemh2rgonz_ha...@mail.gmail.com https://orgmode.org/list/lotcjav--...@keemail.me https://orgmode.org/list/87sfxiw2jp@posteo.net https://orgmode.org/list/dd0ae51d-7d56-0ff6-5eb1-3786464ad...@arfer.net https://orgmode.org/list/5a1cb629-8437-41f5-fd75-674c949ea...@gmx.at https://orgmode.org/list/CAOn=hbefyj7edw6gsobqgkofm65bx1cdc_inxaisdpv74kw...@mail.gmail.com https://orgmode.org/list/87v91vle4u@gmail.com https://orgmode.org/list/87wnl53cq4.fsf@localhost https://orgmode.org/list/so2fh1$10kj$1...@ciao.gmane.io https://orgmode.org/list/041ca43d-2efb-db1e-76ab-7c15af088...@posteo.eu https://orgmode.org/list/CAJr1M6d=0qtynpwabwbnciq2fm4mcybrxoer_hr-va4tj1k...@mail.gmail.com https://orgmode.org/list/20171014123248.51568eec@Tourifreet https://orgmode.org/list/paxpr06mb7760da356c7c27045beb64f6c6...@paxpr06mb7760.eurprd06.prod.outlook.com https://orgmode.org/list/87a6gdaa9i.fsf@tsdye.online https://orgmode.org/list/cab14nk88cyihdgkdqzxhnjyekp_bzz_1j73p-y2fgsk_7jt...@mail.gmail.com https://orgmode.org/list/cafyqvy3mxi4drts+w-ax7bfelvujqh4dodeypy3hygrrume...@mail.gmail.com https://orgmode.org/list/87mthrtb5u@alphaville.usersys.redhat.com > I ask because I'm a bit of an Elisp newbie. I'm assuming the first step is to > try to reproduce the bug given the user's info, and then attempt to look at > the codebase to see what might be causing it? Without elisp, you can 1. Try to reproduce bugs and give detailed instructions for maintainers to fix (it is much easier to fix bugs with detailed steps how to reproduce them) 2. Try submitted patches and see if they work on your customized Org. Then, report any issues 3. Monitor websites like stackexchange and reddit and transfer bug reports from there to the mailing list. Also, I recorded a video explaining how to reproduce Org mode bugs in https://open.tube/videos/watch/4d819114-43bf-42df-af94-f94fc53dd0d9 Best, Ihor
bug#45915: 28.0.90; deletechar distorts org-table
Dear Ihor, > However, this (delete-char 1) somehow deletes 2!! chars instead of > 1. This should be some tricky Emacs issue (bug?). In any case, I am > not ready to dig into what is going on in Emacs. I do not think that > such problem is going to appear during normal Emacs usage. At least, I > was unable to reproduce it by other means than your reproducer > function. > > To illustrate the issue, one can use the following version of the > reproducer. Feel free to report this to Emacs upstream. (defun emacs-bug-reproduce-45915 () "Reproduce bug#45915." ;; (gnus-read-ephemeral-emacs-bug-group 45915) (interactive) (with-current-buffer (get-buffer-create "*temp buffer*") (erase-buffer) (require 'org) (orgtbl-mode 1) (insert (format "emacs-version: %s, org-version: %s\n" emacs-version org-version)) (insert "| | rownames | | / | | |---+--| | | a|")) (switch-to-buffer-other-window "*temp buffer*") (execute-kbd-macro (kbd "M-< C-n C-n C-n C-n C-f C-f")) (message "I will hit S-.") (sit-for 2) (execute-kbd-macro (kbd "S-")) (message "I will hit .") (sit-for 2) ;; (execute-kbd-macro (kbd "")) (delete-char 1) (message "I will call previous-line.") (sit-for 2) (call-interactively 'previous-line)) I still see the problem with GNU Emacs 29.0.50 (build 8, x86_64-apple-darwin21.5.0, NS appkit-2113.50 Version 12.4 (Build 21F79)) of 2022-05-23 with org-version 9.5.3. I create org-tables and revise these everyday. On duplication of a cell, I hit S- often. The problem occurs, with my use case, once in 5 minutes. IOW point moves unexpectedly once in 5 minutes. I think that there is an issue in `org-table-copy-down'. However, I cannot tell what specifically is not good. Is this issue of Emacs instead of Org?
Re: [SOLVED, but ]
On Sunday, 22 May 2022 at 08:57, Uwe Brauer wrote: > 1. org-table-recalculate-buffer-tables > 2. org-table-iterate-buffer-tables > Can anybody please enlighten me? My understanding is: the first will be suitable if there is a simple one-way transfer of data and the tables are in an order that means that tables with the source of data for another table have been recalculated before this other table. The second function will be necessary if the order of the tables is not suitable or if there are circular dependencies. -- : Eric S Fraga, with org release_9.5.3-508-ge268e4 in Emacs 29.0.50
Re: [PATCH] Avoid ignoring LaTeX export output errors when org-latex-pdf-process is a list
This is very useful, especially being able to see the output of BiBTeX, say. Thank you. -- : Eric S Fraga, with org release_9.5.3-508-ge268e4 in Emacs 29.0.50
