Re: [BUG] org-plot: Unable to use text xtics with type:2d (+ more) [9.7-pre (N/A @ /home/viz/lib/emacs/straight/build/org/)]
Ping. Can you answer my questions, Ihor, so that I may prepare a patch accordingly? [வெள்ளி மே 24, 2024] Visuwesh wrote: > [வெள்ளி மே 24, 2024] Ihor Radchenko wrote: > >> Visuwesh writes: >> >>> Unless I misunderstood the code, the line >>> >>> ;; Check type of ind column (timestamp? text?) >>> (when (plist-get params :check-ind-type) >>> >>> should be >>> >>> ;; Check type of ind column (timestamp? text?) >>> (when (plist-get (cdr type) :check-ind-type) >>> >>> because (1) org-plot/collect-options only adds a select number of >>> keywords to the plist and :check-ind-type is not a part of the select >>> members, and (2) org-plot/gnuplot is never called with a non-nil value >>> for the optional argument PARAMS in tree. >> >> I do not think that it is right. >> AFAIU, the idea is that `org-plot/preset-plot-types' provides some >> default options, but the user can overwrite these defaults in the #+PLOT >> line. What you propose will disregard the values of >> >> :set :line :map :title :file :ind :timeind :timefmt :textind >> :deps :labels :xlabels :ylabels :xmin :xmax :ymin :ymax :ticks >> >> if they are customized by user in `org-plot/preset-plot-types'. > > I don't follow your conclusion since this change will only affect the > value of :check-ind-type so how would it affect the rest of the > settings? > >> I believe that the right way to address the problem will be >> `org-combine-plists' on the (1) org-plot/preset-plot-types; (2) >> org-plot/gnuplot-default-options; (3) #+PLOT lines in the buffer. > > Looking at the definition of org-plot/add-options-to-plist and the Info > manual, I am not sure if :check-ind-type is supposed to be customised by > the PLOT line. It seems to be more of an internal setting. If you > agree to this, I can change the check to > > (when (or (plist-get type :check-ind-type) (plist-get params > :check-ind-type)) > > to heed the value of :check-ind-type in org-plot/gnuplot-default-options > (since PARAMS has the default values included earlier in the defun). > >>> [...] >>> The other code smell I see is that the function checks for the PLOT line >>> twice. Once near the beginning of the function, and once just after the >>> cleaning up of hline. Is this simply an oversight? >> >> It is kinda intentional, but broken. >> >> Historically, users can put #+PLOT lines _after_ the table. >> However, after refactoring org-table.el, this is no longer working. >> See https://list.orgmode.org/orgmode/87o7a0p9ba.fsf@localhost/ > > OK, I will leave the check in then. > >>> Coming to the grid example, the doc-string of org-plot/preset-plot-types >>> options says: >>> >>> - :data-dump - Function to dump the table to a datafile for ease of >>> use. >>> >>> Accepts lambda function. Default lambda body: >>> (org-plot/gnuplot-to-data table data-file params) >>> >>> but in fact, org-plot/gnuplot passes one more argument to the :data-dump >>> function: >>> >>> ;; Dump table to datafile >>> (let ((dump-func (plist-get type :data-dump))) >>> (if dump-func >>> (funcall dump-func table data-file num-cols params) >>> (org-plot/gnuplot-to-data table data-file params))) >>> >>> but here's the catch: the :data-dump function in the grid option expects >>> the order >>> >>> (lambda (table data-file params _num-cols) >>> >>> which breaks things down the line. What should be the actual order >>> here? I looked at the history of those lines briefly using C-x v h but >>> I don't have the time to look into it properly to decide on the actual >>> argument order. >> >> The best order is de-facto calling convention in the code: >> >> (funcall dump-func table data-file num-cols params) >> >> The docstring and the default value should be fixed accordingly. > > OK, will do this in a future patch.
[[SOLVED?]] (was: remote calls to tables and (empty entry, NAN))
>>> "UB" == Uwe Brauer writes:
> Hi again
>> Uwe Brauer writes:
>> This works for me:
>> #+TBLFM: $2=if(typeof(remote(table2, @@#$7)) == 12, string(""),
>> remote(table2, @@#$7)); E
> As you can see in the table2 the row Miller-and-Smith have been
> interchanged and so the final table ends up with incorrect values
> However, (as somebody else suggested some time ago) the following
> solution avoids that problem.
> #+begin_src
> #+NAME: table3
> | Name | Ex1 | Ex2 | Ex2 | Ex4 | Ex5 | ResSh1 |
> |+-+-+-+-+-+|
> | Smith | 2 | 3 | 4 | 6 | 7 | 22 |
> | Miller | 2 | 10 | 1 | 1 | 5 | 19 |
> | Wick | 1 | 2 | 3 | 10 | 2 | 18 |
> #+TBLFM: $7=vsum($2..$6);f2
> #+NAME: table4
> | Name | Ex1 | Ex2 | Ex2 | Ex4 | Ex5 | ResSh2 |
> |+-+-+-+-+-+|
> | Miller | 2 | 1 | 6 | 9 | 3 | 21 |
> | Smith | 8 | 3 | 5 | 8 | 9 | 33 |
> | Wick | 1 | 5 | 9 | 1 | 2 | 18 |
> #+TBLFM: $7=vsum($2..$6);f2
> #+Name: final
> | Name | ResSh1 | ResSh2 | Total |
> |+++---|
> | Smith | 22 | 33 | |
> | Miller | 19 | 21 | |
> | Wick | 18 | 18 | |
> #+TBLFM: $2='(org-lookup-first $1 '(remote(table3, @1$1..@4$1))
> '(remote(table3, @1$7..@4$7)))::$3='(org-lookup-first $1 '(remote(table4,
> @1$1..@4$1)) '(remote(table4, @1$7..@4$7)))
> #+end_src
It seems that just adding ; E at the end of the line solves the problem
#+TBLFM: $2='(org-lookup-first $1 '(remote(sheet1, @I$1..@II$1))
'(remote(sheet1, @I$2..@II$2))); E
--
I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military.
I support the EU and NATO membership of Ukraine.
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH] Run latex more than once for LaTeX src block evaluation
Ihor Radchenko writes: Michael writes: Sorry-- got sidetracked by something else. I see what you mean. OK, so the proposal is: change the ".png" branch in `org-babel-execute:latex' to override `org-preview-process-alist' with something that will: - actually produce a PNG formatted file - by default, run latex more than once, tho this could of - course be customized May you prepare a patch? My apologies, Ihor... completely missed this. Yes, give me a day or two. FYI, the patch implementing the suggestions is already in place. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c426f4936 My bad, Thank you. -- Michael
Re: [DISCUSSION] Add "Recent News" to orgmode.org
Ihor Radchenko writes: > Attaching tentative patch that makes Org mode throw an error when a > prompt is requested for an external URI. LGTM! Thanks. -- Bastien Guerry
[BUG] orgtbl hangs emacs [9.8-pre (release_9.7.2-13-gc426f4 @ ..../org-mode/lisp/)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
1. Make a python file as below
2. Start orgtbl
3. Try C-c C-c inside the table
Emacs hangs -- that is I get a turning wheel until I give a C-g
Note: The #+ORGTBL line
NEEDS TO BE THE VERY FIRST LINE!
NickD on the emacs-SE guesses it is a hanging in the function
org-tbl-gather-send-defs in org-tbl.el
because of (forward-line -1) in the function which has no effect when on
line 1
See my question: https://emacs.stackexchange.com/q/81455/5223
His chat https://chat.stackexchange.com/transcript/message/65777321#65777321
Note I ran this with: make vanilla from the git-repo of org
So I am not enclosing the variables
python file
#+ORGTBL: SEND marks orgtbl-to-generic :lfmt " \"%s\": [%s,%s]" :llfmt
" \"%s\": [%s,%s]"
| abe | 1 | 2 |
| beth | 9 | 1 |
"""
stud_db = {
# BEGIN RECEIVE ORGTBL marks
"abe": [1,2]
"beth": [9,1]
# END RECEIVE ORGTBL marks
}
-end file -
Emacs : GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.17.8)
of 2023-09-02, modified by Debian
Package: Org mode version 9.8-pre (release_9.7.2-13-gc426f4 @
/home/rusi/pdsw/org-mode/lisp/)
