From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:1008:1e59::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id kOLUMN52UWbDzAAAA41jLg (envelope-from ) for ; Sat, 25 May 2024 07:27:58 +0200 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id 8E6dKN52UWZIBAAA62LTzQ (envelope-from ) for ; Sat, 25 May 2024 07:27:58 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=KmpeOlX2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1716614878; a=rsa-sha256; cv=none; b=SENkQ2HhtTw6uTknZNwwJG1JDihSj5tt7hssQXfpHcqD6FamUgfDhdad55DgUq7KBBaIi6 fvgnH1PAgcioeJjdzdYK7DxT1qjWC17vurkh6eqES0Pv+goIIWjIPpq+kAaNFlN32LNJwl xAnqG8pe4ZZ+QvP7Khtq6RtVCVDGro2fdE2+UA/4VNJuVT1Hj//s1NfSjBv636t5fh8FTp f0IfG62CgenOnaKJLoP945t7Cp/rzXqQU1IlGXIRBnS4X8Y7kFr6qjoD5aww5wHDVwDIYH FHrYTJN7rJKcGaJsbZwMpbtBzUQci08sqE7xVw6quBJDFUwHlb2c7srX7BVCPg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=KmpeOlX2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1716614878; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=A4UXezaGBsmv9AYU7xfZDSDWHL5UG5BT/JznkqD0LpE=; b=D3NV/swbsKIGtcEmmDYF7wHdJi8hdIdN2hiq3XuTXBCN79cVEHAYfuaUVrviJ1hvvoEofq ZfSn1OOCaA9FEVfX7w+b2HMNmfmQYMBj7xj1hlFIQpFYePcsGs1ut5vguX99W4aXLC9Zqv FnHuq5ktBWa6+0vhUHXfhQAjsoX3O21m1BAHDIn3uBtKoif7Y0EbxnJpT/ImX1NMHlL8hk IaqFq3CizyF6Fm6pnZyrqILtNaJRfHBEQq6U97rGVp5oxd5rJpl8Cs0JVF0YTVVpLmMCmJ P5+W0LT6SfFwP47KbFEdj4vq/XTNOhFlqaxmYmc4E/FcNXoMHLmBOILBwWPypg== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 2E9EF67BEA for ; Sat, 25 May 2024 07:27:58 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sAjvc-0000lA-ST; Sat, 25 May 2024 01:26:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sAjvQ-0000hR-6Y for emacs-orgmode@gnu.org; Sat, 25 May 2024 01:26:36 -0400 Received: from mail-pl1-x642.google.com ([2607:f8b0:4864:20::642]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sAjvJ-0004Sg-HQ for emacs-orgmode@gnu.org; Sat, 25 May 2024 01:26:35 -0400 Received: by mail-pl1-x642.google.com with SMTP id d9443c01a7336-1f34b5f1964so18881895ad.2 for ; Fri, 24 May 2024 22:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716614788; x=1717219588; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:references :message-id:date:in-reply-to:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=A4UXezaGBsmv9AYU7xfZDSDWHL5UG5BT/JznkqD0LpE=; b=KmpeOlX2Hc+srGqcVc7WUO08VgsbFFQ5x/xYdvkhl5cMt7EFIQHYIigbRUxCVNeOwp qajnvpHlbSxW1txeV0hqDHIFLqgLSm3c2sP2R21Wh4SJFB9uvsMH7ojJmTyHRhxsAFe6 Nq6UA9YHMGCv7dQxwL75G+Wf4asD1yog5kxrM0OtF4CXBbtsuQoddDm1AXBOfD7U2dtG DvbobahvUGb+REt/hYIX8a6An+K8KJLsfz6JazZnnphtnOup9mG/P2tq7G69AfLRNLwb se3kI/wOrWFf3Wf6j7PsughBCdxSDyGBB2CeV9i8CX07xPleyl46MajQjml9cUc4DoQA eLlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716614788; x=1717219588; h=content-transfer-encoding:mime-version:user-agent:references :message-id:date:in-reply-to:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=A4UXezaGBsmv9AYU7xfZDSDWHL5UG5BT/JznkqD0LpE=; b=xSPJUYxlpTccN9XeDVgGTBZ1XkYlXJ9e5aua1Cwsl4vrFmS02bK9GqIs4GH/h+MUua z7Onndm38zJqnRrLSxJ9zS/X4ff6MASSIaEq7eKydoZePY7nAqv/NXgHO7x6waM7h1OX a9EihpEzgW5aHFXBBhB9uJZy9SsvZu7TZ1ykJVGSjkQdRF/HYTVcipbI9tooao1jqht1 Wd7H7M2MH8EYmejhjGw9jcgPdOh3CP9RMgh0up02ptcDnF075TeTvBooD1x5nex4WaXa yo2a0IxQcGn0kWVYxF3SMJEZHexG53DEiKmuIQQ8JyXw538AcSDxw44XeOr0beJwxwVP NErw== X-Gm-Message-State: AOJu0YyOW1H5IfLCZ0nxUnvP5dqEHYYBPN+PGM+H9pkgB0oCoJYLhXMe zFBKw1BjK4sWr8IBRZCeilhXU4YMj60tMmXzzSno0Fn8KGQP7uKoKZR5dyWekIs= X-Google-Smtp-Source: AGHT+IEtIGxR7g8+fPpadhkvSnX39N7SJ/p+/nTn1kdtEKDhvoVrYRo2RNcGwLwituBPV6EAcHUy9g== X-Received: by 2002:a17:903:11ce:b0:1f3:25b:ae2f with SMTP id d9443c01a7336-1f44902a656mr46761305ad.45.1716614787714; Fri, 24 May 2024 22:26:27 -0700 (PDT) Received: from localhost ([2401:4900:60fb:a68:e96:e6ff:fe21:79ad]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1f44c9ccb23sm22633475ad.282.2024.05.24.22.26.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 May 2024 22:26:27 -0700 (PDT) From: Visuwesh To: Ihor Radchenko Cc: emacs-orgmode@gnu.org Subject: 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/)] In-Reply-To: <871q5rv1qy.fsf@localhost> (Ihor Radchenko's message of "Fri, 24 May 2024 12:21:57 +0000") Date: Fri, 24 May 2024 22:49:55 +0530 Message-ID: <8734q7jfes.fsf@gmail.com> References: <87cypbjw50.fsf@gmail.com> <871q5rv1qy.fsf@localhost> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::642; envelope-from=visuweshm@gmail.com; helo=mail-pl1-x642.google.com X-Spam_score_int: -6 X-Spam_score: -0.7 X-Spam_bar: / X-Spam_report: (-0.7 / 5.0 requ) BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Queue-Id: 2E9EF67BEA X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -9.68 X-Spam-Score: -9.68 X-TUID: JQEx8uC/MBFF [=E0=AE=B5=E0=AF=86=E0=AE=B3=E0=AF=8D=E0=AE=B3=E0=AE=BF =E0=AE=AE=E0=AF=87 = 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 leaving the rest of the settings unaffected. > 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.