Re: [ANN] lisp/ob-tangle-sync.el
Em domingo, 05/05/2024 às 18:47 (+02), Mehmet Tekman
escreveu:
> Hello João and org!
Hi Mehmet!
> This will be a long email summarizing what's been done so far, where the
> pitfalls were, where we are now, and what needs to be done:
Thank you for the summary. Albeit long, it was quite important to
understand all of the discussions and decisions so far. I tried keeping
track of every thing on this long, long thread, but couldn't follow up
with everything, so it was incredibly helpful of you to give such a
complete summary.
> So, my code is hosted at =https://gitlab.com/mtekman/org-mode= and with
> the exception of the =header-reform= branch, is about 1 year behind
> upstream.
So, if I understand correctly, =header-reform= is where we're at right
now and after we're done with this overhauling of the parsing of
(mutually exclusive) header params, we'll get back to the actual syncing
logic, which should be mostly done.
> * Where we are now
>
> The branch I have most recently worked on (I rebased it earlier this
> week) is called =header-reform=. It splits a :tangle header such as
>
> this =:tangle filename with space.txt export=
> into =:tangle-params ("filename with space.txt" "export")=
>
> such that it does not interfere with the rest of org headers.
>
> This is where I would greatly need you help, João.
>
> The work still to be done from my perspective:
>
> 1. Implement tests <<- we are here
>
>We need to know what the desired behaviour of :tangle and
>:tangle-params will be in different contexts.
>
>I have written 12 test cases as a start, but some contexts are
>still unclear to me and I cannot do this alone.
>
>Please see the second and third patches attached to this email.
Ok I'll start here as I think writing tests could give me some more
insights on the core problems that still need solution.
> 2. Unified merge function
I do have a couple of questions regarding this:
>Something that handles tangle-params and result-params,
1. So the idea is to continue parsing multi-option header arguments into
their separate components, but have a common place to, after parsing
it into their components, handle them all in a single place? I mean,
what does "handle" mean in this context?
>as well
>something that can handle mutually exclusive groups such as tangle
>and results, especially when the :any keyword is involved.
2. Isn't that the same as the previous point? If we can handle any
*-params doesn't that solve the problem of handling mutually
exclusive groups? We can just define a pattern of parsing them into
individual *-params and handling that in a unified manner.
> I've attached the two working patches from the =header-reform= branch to
> this mail, and one floating WIP inline patch which should get things
> started.
Are these patches also on the branch (apart from the WIP one)?
> Apologies for the length, I just wanted to summarize the efforts and
> show where you could come in.
As I said in the beginning, I'm actually quite grateful for the
summarizing!
Best regards,
--
João Pedro de A. Paula
IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)
[Q/Bug?] Comment for noweb reference comments content
Hi, Ok so I don't know whether this is a bug or intended behaviour (though if its the latter I propose we reconsider), but if I have the following #+begin_src emacs-lisp :noweb yes :comments noweb :tangle /tmp/foo.el (progn <>) #+end_src #+name: foo #+begin_src emacs-lisp (message "foo") #+end_src the resulting foo.el will have a syntax error, since the closing ) for `progn' will have been commented like so ;; [[file:...][No heading:1]] (progn ;; [[file:...][foo]] (message "foo") ;; foo ends here) ^ ;; No heading:1 ends here It seems like some macro let-bound in `org-babel-expand-noweb-refereces' is doing this, but I couldn't pinpoint exactly what or where. What I could achieve though, is to add a newline after the second call to `c-wrap' inside `expand-body''s definition, which at least solve the problem of throwing syntax errors, but I don't think that would be the best solution. Best regards, -- João Pedro de A. Paula IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)
Re: Possible to set block switches "globally"?
Em sexta, 03/05/2024 às 10:12 (-07), Tom Gillespie escreveu: > Hi, >Thanks for getting things going on this again João. No problem! I've been meaning to get my feet wet on some Org-mode hacking for a while now. > Based on what is in org-element-example-block-parser > and org-element-src-block-parser I think > > :number-lines (yes|no|continue) as João proposes > :indent (preserve|align|???) not sure about naming > :labels (link|keep|remove|remove-whitespace) > :label-format regexp-string Yeah, as Ihor pointed out I did forget about -i, though I'm not really sure what that does. > Defaults would be :number-lines no, :indent align, > :labels remove-whitespace and :label-format would > inherit from the default. > > The remove-whitespace option would remove the label > itself along with any whitespace leading up to it, this > avoids the user needing to specify the leading whitespace > in :label-format. The remove option by itself is retained > in the event that someone has aligned their labels and > wants to retain the whitespace. This may be too complex > though and remove-whitespace is not needed because > :label-format can be modified as needed. > > Header arguments need to have a single value, so I think > we should split :labels and :label-format, that way users > can also specify :label-format without having to specify > :labels first (otherwise there is ambiguity about what a single > argument :labels means. Sure, makes sense to separate it. I tried searching for where switches are parsed in the code, but couldn't find much. Could you provide me with some pointers and files I should be looking at? Cheers, -- João Pedro de A. Paula IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)
Re: Possible to set block switches "globally"?
Em segunda, 29/04/2024 às 17:34 (GMT), Ihor Radchenko
escreveu:
> Yes. This is the plan.
>
> Citing earlier syntax discussion in
> https://list.orgmode.org/orgmode/877d08bkze.fsf@localhost/
>
> > Can we drop switch support? This seems like a fairly good idea. The
> functionality can simply be shifted to
> > ARGUMENTS with the well-established :key val forms.
> > “For the love of all that is sane” — Tom G
All right so if I understand correctly, we'd like to deprecate switches
from the parser and introduce :key val pairs for each switch, but no one
has gotten to it yet?
If that's the case, I'd propose something like
- (-|+)n => :number-lines (yes|*no*|continue)
^ +n
- -r => :labels (link|keep|*remove*) ("label string")?
^ -k ^ -l "label string"
and could give it a try. What do you think?
--
João Pedro de A. Paula
IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)
Re: [ANN] lisp/ob-tangle-sync.el
Em segunda, 29/04/2024 às 09:43 (+02), Mehmet Tekman escreveu: > The development is happening chaotically on my own repo > (gitlab.com/mtekman/org-mode) across several incomplete branches. > > I've actually been working on it on and off for the last two weeks, but > I've been facing some rebasing issues that I need to tackle first before > I actually push anything to a branch that anyone can work on. > > Can you wait until Sunday for me to resolve this, and then we can > discuss? Yeah, of course! Cheers, -- João Pedro de A. Paula IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)
Re: [ANN] lisp/ob-tangle-sync.el
Hey Mehmet and Org! I'd like to ask if I could contribute to this. I have followed the discussion to a point, but would be more than happy to try and contribute to this so it gets merged for the next Org major version, as I've been waiting for this for quite a while now. It solves the major gripe I had with your original org-tangle-sync.el package, which is the ability to sync blocks that aren't whole files. So, what still needs to be done and where is development happening (I assumed it was on the main Org-mode git repository, but I see no branch there)? Cheers, -- João Pedro de A. Paula IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)
Possible to set block switches "globally"?
Hi Org-mode! Is there a way to set =src= and =example= switches (as documented in "(org) Literal Examples"[0]) file- or heading-wide? I tried using #+property: header-args:emacs-lisp -n -r but they aren't really header arguments and that doesn't get picked up as it should (it does, but as if `-n' is a key and `-r' is a value for a header argument). Ideally, I would be able to set those as a file properties like that, or per heading under the =:PROPERTIES:= drawer. [0] https://orgmode.org/manual/Literal-Examples.html Thanks in advance, -- João Pedro de A. Paula IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)
Possible to set block switches "globally"?
Hi Org-mode! Is there a way to set =src= and =example= switches (as documented in "(org) Literal Examples"[0]) file- or heading-wide? I tried using #+property: header-args:emacs-lisp -n -r but they aren't really header arguments and that doesn't get picked up as it should (it does, but as if `-n' is a key and `-r' is a value for a header argument). Ideally, I would be able to set those as a file properties like that, or per heading under the =:PROPERTIES:= drawer. Thanks in advance, [0] https://orgmode.org/manual/Literal-Examples.html -- João Pedro de A. Paula IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)
Re: [DOC] Mismatch on doc regarding position of src block switches
Em segunda, 22/04/2024 às 18:12 (GMT), Ihor Radchenko escreveu: > Thanks for reporting! > Fixed, on bugfix. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a9275d5fd Wonderful, thanks for the quick fix as well! > We deliberately limit the number of details in the syntax spec. > For now, we just say that lesser blocks can have arbitrary DATA at the > begin line. Ah ok, I was wondering whether that was intentional or not! Cheers, -- João Pedro de A. Paula IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)
[DOC] Mismatch on doc regarding position of src block switches
Hi Org folks, I've noticed that in (org)Literal Examples[0], when documenting the switches for example and source blocks, it is mentioned that they should be placed at the *end* of the #+BEGIN line, while both in (org)Structure of Code Blocks[1] and the Org Syntax document[2] the switches are documented to be placed right after the language (when appropriate), which is the correct placement for it. I've also noticed that the Org Syntax for blocks (greater or lesser) don't mention example blocks having optional switches. [0] https://orgmode.org/manual/Literal-Examples.html [1] https://orgmode.org/manual/Structure-of-Code-Blocks.html [2] https://orgmode.org/worg/org-syntax.html#Blocks Cheers, -- João Pedro de A. Paula IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)
Re: [RFC] If you use Org 9.6, please share the output of M-x org-element-cache-hash-show-statistics
On Thu, February 09 2023 11:51, Ihor Radchenko wrote: > Hi, Hello Ihor! > If you are ok with sharing the statistics, and you are running Emacs > session for at least few hours (using Org mode, obviously), please reply > sharing the output of Definitely OK with it! Here it goes > M-x org-element-cache-hash-show-statistics 22.63% of cache searches hashed, 1.71% non-hashable. > M-x emacs-uptime 2 days, 3 hours, 19 minutes, 31 seconds Best regards, -- João Pedro de A. Paula IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)
Re: [PATCH] LSP support in org-src buffers
On Mon, December 12 2022 13:16, Ihor Radchenko wrote: > If an src block has :tangle option, it is probably reasonable to display > it together with other tangled blocks. > If an src blocks does not have a :tangle option, :context might be used > as the means to group blocks together. But then, the value should be > some kind of string - blocks with the same :context name will be grouped > together. That makes much more sense. Though I still think the user should be able to, even with a :tangle option, be able to choose whether they want to edit that particular source block with the whole context or not, cause it might be slow for some huge tangled files, for example. > And, of course, the whole thing may be behind a defcustom switch. Or > file option. Yup! I prefer to have both options, a file option and a defcustom. This allows me to have a global configuration, but change it to a particular file without having to deal with the local variables block in Org files. > We are not in hurry. Any progress will be appreciated as long as there > is some. All right. I'll keep you posted on it. -- João Pedro de A. Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: [PATCH] LSP support in org-src buffers
On Tue, November 22 2022 02:23, Ihor Radchenko wrote:
> It looks like you have done something very close to what we are
> discussing. Would you be interested to create a patch against Org core
> instead of relying on advises?
That would be wonderful! That code has some ugly hacks, some of which
gave me a little bit of headache when I was using it, but I think that
it could become something polished and well-behaved, specially taking
inspiration on Karthik's approach to it as well (I can, from a quick
glance, see some improvements that could be made. And who knows maybe we
make it work even with noweb...). Were you thinking of having a
=:context {yes|no}= option on src blocks?
Also, I will have more free time to work on it starting on the second
week of December. Before that I'll be incredibly busy, unfortunately.
Best regards,
--
João Pedro de A. Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: [PATCH] LSP support in org-src buffers
Hey there, Karthik! I've had a similar idea, though not tied to LSP or anything. I created a =org-contextual-src-mode= [1] ir order to have completion working on Ledger and LaTeX source buffers. It also handles tangling! I have made a Gist explaining, in a literate style, my process of building such a mode. I think the contextual src block could be split from the LSP functionality, since it could be used in other contexts other than dealing with language servers. My iteration is not tied to anything in particular and simply creates a source buffer with the whole context for that tangled file. Hope this can help you in some way! [1] https://gist.github.com/bigodel/15599f3c1da23d1008b7d7d4ff8bff77 Cheers, -- João Pedro de A. Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: Org and Hyperbole
Hey Robert. Thanks for coming here to offer to clarify any doubts people have regarding Hyperbole. I haven't been interacting with the thread, but I've been lurking about and I've tried Hyperbole in the past, but couldn't precisely figure out its use case in my particular workflow, so I gave up on it. Now, according to your description, the main feature of Hyperbole looks a lot like what Embark [1] does sort of the same thing, albeit in different contexts, complexity (not a bad thing) and workflow. Would you be able to compare them? I think it would help me understand where exactly Hyperbole fits, and what is the problem it tries to solve. [1] https://github.com/oantolin/embark Best regards, -- João Pedro de A. Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: About opening issues vs email [Was: About 'inline special blocks']
Hey Kaushal! Thanks for your insight. On Thu, May 26 2022 17:22, Kaushal Modi wrote: > - Issues section is there for a reason. If the repo owner did not like > people opening Issues, they would disable that section. I agree with Ihor's response for this point. > - Conversations and discussions are better formatted and readable in > the issue threads. I disagree with this one, I find mailing lists much more well-formatted, readable and conversation/discussion friendly than PRs on GitHub (it mostly has to do it the web UI, TBH [1]). > - If the feature is implemented, I like to link that commit or PR to > that issue so that the entire history and reasoning behind a feature > addition (esp. if it's a breaking one) can be followed through > hyperlinks from the commit log to the issue thread. But it isn't this particular case. I only emailed asking if he would have interest on merging his work on Org-mode core, which isn't really a feature or a modification on the codebase. Nonetheless, one of the first things I said was that I could open an issue on the public repo if he'd rather have it documented there as well. I just felt more inclined to send him an e-mail because 1. he made it public, and 2. I feel more comfortable using e-mails for communicating such things. [1] https://asylum.madhouse-project.org/blog/2018/07/24/on-git-github-and-email/ Regards, -- João Pedro de Amorim Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: About 'inline special blocks'
On Thu, May 26 2022 20:20, Ihor Radchenko wrote: > I think that you can simply open an issue in his Github repo. I reached out to him on e-mail, if he doesn't reply there I'll create the issue. Thanks! -- João Pedro de Amorim Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: About 'inline special blocks'
On Thu, May 26 2022 12:56, Ihor Radchenko wrote: > I agree. But it is a known problem on defining new specific command vs. > running a new generic command with arguments. You can indeed define a > new command (block in our case), but if you just need to adjust some > parameter once in the whole document, there is no point creating a whole > new block type just for that purpose. Think about defun vs. lambda. Oh, got it. Well, as I said, I'd be more than happy using the #+attr_X solution though! > I am not sure if I mentioned this earlier, but org-special-block-extras > could be a good addition to Org core. Has anyone tried reaching out to the author? I think it would be a great addition! It is a seemingly simple idea that opens up some many possibilities in Org-mode. Best, -- João Pedro de Amorim Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: About 'inline special blocks'
On Tue, May 24 2022 11:56, Ihor Radchenko wrote:
> I think that we might simply allow to define complex configuration
> before the containing paragraph. Something like:
On that note, I think that allowing for inline special blocks would make
that more readable. It would work wonderfully with
org-special-block-extras [1], where the user could define complex blocks
with formatting configuration and what-not, and just use that as an
inline block.
> #+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.
Although I do agree that this sort of solves the same problem as the
other approach, but I, personally, find that defining new special blocks
is not only easier to reuse, but more readable as well. But I'm thinking
in terms of org-special-block-extras here, so take my 2 cents with a
grain of salt.
[1] https://github.com/alhassy/org-special-block-extras
Best,
--
João Pedro de Amorim Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: Custom TODO states for one item
Greetings, Bastien! On 28 March 2022 14:39, Bastien wrote: >> I have a file with custom TODO states: >> >> #+TODO: FOO(f@/@) | BAR(b@/@) >> >> I have one item (heading) within that file that I'd like to have >> different TODO states. Is this possible? > > No, and I don't think it's a good idea to support this. Could you elaborate on why not? I have been in situations where having the ability to define a heading-wise TODO keyword would be useful, but I managed to get around using different ways of achieving the same end-goal. Best regards, -- João Pedro de Amorim Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: [RFC] DOCT: Declarative Org Capture Templates (easier template syntax)
On 20 March 2022 18:19, Ihor Radchenko wrote: > Also, if anyone agrees with my arguments below, do not stay silent and > drop a "+1" email below. Otherwise, this whole thing will be stalled. > There is no point discussing technical aspects, if there is no interest. It isn't really something that bothers me, or causes my any sort of problems, given that I have the same set of capture templates for close to 3 years now, and have never felt the need to change it. That being said, getting to those capture templates was a pain indeed, having to, as you alluded to in another e-mail, constantly revisit the docstring for the precise position of each element, and more often than not getting them wrong. So I'm all up for it! Cheers, -- João Pedro de A. Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: Move or rename a file in a link
On 19 March 2022 11:25, Juan Manuel Macías wrote: > #+begin_src emacs-lisp > (defun my-org-rename-link-file-at-point () > (interactive) > (let* ((curr-dir (if (equal (org-element-property :type > (org-element-context)) "attachment") >(concat (abbreviate-file-name (org-attach-dir)) "/") > (abbreviate-file-name default-directory))) > (current-path (if (equal (org-element-property :type > (org-element-context)) "attachment") >(concat curr-dir (org-element-property :path > (org-element-context))) > (org-element-property :path (org-element-context > (new-path (read-file-name "Rename file at point to: " current-path))) > (rename-file current-path new-path) > (message (concat "moved to: " new-path)) > (if (directory-name-p new-path) > (setq new-path (concat new-path (file-name-nondirectory > current-path))) > (setq new-path new-path)) > (if (equal (org-element-property :type (org-element-context)) > "attachment") > (my-org-replace-link-file (file-name-nondirectory current-path) > (replace-regexp-in-string >curr-dir "" new-path)) > (my-org-replace-link-file current-path > (replace-regexp-in-string > curr-dir "" new-path) > > (defun my-org-replace-link-file (from to) > (save-excursion > (goto-char (point-min)) > (while (re-search-forward org-bracket-link-regexp nil t) > (cond ((string-match-p (concat "attachment:" from) (match-string 1)) > (replace-match (concat "[[attachment:" to "]]"))) > ((string-match-p from (match-string 1)) > (replace-match (concat "[[file:" to "]]"))) > #+end_src Just a couple of fixes and it seems to be working fine. diff -u a/org-rename-link.el b/org-rename-link.el --- a/org-rename-link.el 2022-03-22 12:08:45.790727092 -0300 +++ b/org-rename-link.el 2022-03-22 12:25:31.500218923 -0300 @@ -23,8 +23,11 @@ (defun my-org-replace-link-file (from to) (save-excursion (goto-char (point-min)) -(while (re-search-forward org-bracket-link-regexp nil t) - (cond ((string-match-p (concat "attachment:" from) (match-string 1)) - (replace-match (concat "[[attachment:" to "]]"))) -((string-match-p from (match-string 1)) - (replace-match (concat "[[file:" to "]]"))) +(while (re-search-forward org-link-bracket-re nil t) + (replace-match + (cond +((string-match-p (format "^attachment:%s\\'" from) (match-string 1)) + (format "attachment:%s" (file-name-nondirectory to))) +((string-match-p (format "^file.*:%s\\'" from) (match-string 1)) + (format "file:%s" to))) + nil nil nil 1 Diff finished. Tue Mar 22 12:26:56 2022 All this patch does is to remove the directory name from the =attachment:file.ext= -- given that the path is calculated by org-attach --, and use the group 1 of the match string (as well as updating the use of an obsolete variable), which corresponds to the actual link portion, leaving the description unchanged. Cordially, -- João Pedro de A. Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: Move or rename a file in a link
On 10 March 2022 14:58, Juan Manuel Macías wrote: > Hi João, Thanks for your comment. Hello, Juan! I apologize for the delay on responding, I had some issues with my e-mail account lately. > Regarding attachments, do you mean org attachments or email attachments? > Could you give an example of a use case? I mean org attachments. I use org-attach extensively to store documents with notes. So I'd have a heading like so * Documents :PROPERTIES: :DIR: data/docs/ :END: - [[Registration][attachment:registration.pdf]] :: My registration. And say I'd like to rename the file. I would need to rename it inside data/docs and I would also need to edit the link, so I would like to have a way to do it automatically. I just got a computer back so I will be trying to adapt what you did to work with org-attach, but if you figure out a way to do it as well, please, let me know. Regards, -- João Pedro de Amorim Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: Move or rename a file in a link
On 05 March 2022 19:58, Juan Manuel Macías wrote: Hello Juan! > Hi all, > > I have written this simple function to move or rename a destination file > in an external link at point. I share it here in case it is useful to > someone. > > Best regards, > > Juan Manuel > > #+begin_src emacs-lisp > (defun my-org-replace-link-file (from to) > (save-excursion > (goto-char (point-min)) > (while (re-search-forward org-bracket-link-regexp nil t) > (when (string-match-p from (match-string 1)) > (replace-match (concat "[[file:" to "]]")) > > (defun my-org-rename-link-file-at-point () > "Rename or move a file in an external link at point and > update the link path" > (interactive) > (let* ((curr-dir (abbreviate-file-name default-directory)) >(current-path (org-element-property :path (org-element-context))) >(new-path (read-file-name "Rename file at point to: " current-path))) > (rename-file current-path new-path) > (message (concat "moved to: " new-path)) > (if (directory-name-p new-path) > (setq new-path (concat new-path (file-name-nondirectory current-path))) > (setq new-path new-path)) > (my-org-replace-link-file current-path > (replace-regexp-in-string curr-dir "" new-path > > #+end_src > Thanks for sharing! It'd be great if it worked for attachments as well, but that is a whole can of worms. Cheers, -- João Pedro de Amorim Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: Unable to get current or via use-package
On 18 February 2022 18:32, João Pedro de Amorim Paula wrote: > I ended up not posting the link[1] I referred to in the first e-mail, Welp, seems like I did it again... But no harm done this time, all the necessary code was attached anyway :P Forgetfully, -- João Pedro de Amorim Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: Unable to get current or via use-package
On 17 February 2022 16:00, "Loris Bennett" wrote: > What exactly would you like me to test? I ended up not posting the link[1] I referred to in the first e-mail, but since then I got back home and tested the functions provided there seem to be doing what I expected. With it, I can force Emacs to download a built-in package from ELPA and use it, instead of the built-in version. I was afraid that I was only downloading it, but Emacs wasn't actually loading it, but I couldn't test it because I have Emacs 28.0.91, which contains the latest versions of all the built-in packages that are also in ELPA. Given that, I have compiled Emacs 27 and ran it with the attached init.el, and running M-x org-version tells me Org mode version 9.5.2 (9.5.2-gfbff08 @ .../.emacs.d/elpa/org-9.5.2/) It seems that calling my (require-package 'pkg 'force) is getting the latest ELPA version available for built-in packages and using that programatically, without having to use the Package List interface. Regards, -- João Pedro de Amorim Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN) init.el Description: application/emacs-lisp
Re: Unable to get current or via use-package
On 10 February 2022 17:57, João Pedro de Amorim Paula wrote: > I had a similar issue in the recent past and was able to come up with a > solution using the built-in package.el. Not sure how to make it work > with use-package, but that at least seems to solve the issue of it not > installing the ELPA version. Forgot to add the link to my previous email, oops! https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00062.html -- João Pedro de Amorim Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: Unable to get current or via use-package
On 09 February 2022 16:51, "Loris Bennett" wrote: > Thanks, that did the trick. I was hoping that when I use the same > init.el on a different machine I wouldn't have to remember anything and > use-package would automatically install the latest version. Seemingly > not :-/ I had a similar issue in the recent past and was able to come up with a solution using the built-in package.el. Not sure how to make it work with use-package, but that at least seems to solve the issue of it not installing the ELPA version. Not really sure if the version installed is the one that Emacs actually uses, though, I am on Emacs 28.0.91 and all of the built-in packages I have are the same version as their ELPA counterpart, so Emacs seems to be prioritizing the built-in version. It could be that this is only the case because they're both the same version; and seem as I'm traveling ATM I couldn't test it against Emacs 27, so it would be great if you could check it. Cheers, -- João Pedro de Amorim Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: Suggestion: convert dispatchers to use transient
On 05 February 2022 18:49, Samuel Wales wrote: > jus want to state the obvious here in case it is useful [but everybody > probbly lready knows] --- not everybody uses packages or maybe trusts > them has internet etc. Indeed! What I posted assumes using packages, but they also work with any package-desc object. So, if you download it locally and build the package-desc for it it should also work, just have to put it in place of the assq: >> (let ((pkg-desc (assq 'org package-archive-contents))) >> (package-install pkg-desc)) Although Tim was referring to packages on ELPA that are also built-in. -- João Pedro de A. Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: Suggestion: convert dispatchers to use transient
On 04 February 2022 08:30, Tim Cross wrote: > I'm assuming it is, but I have to admit I'm still not 100% clear on > how Emacs handles the situation where you use a library that is both > built-in and available in ELPA. Does Emacs use the latest version > available or does it use the built-in version until you explicitly > select the ELPA versions? Welp, I happened to ponder the same question after trying to implement a function to install packages that are not installed already (I'm not using any helper configuration such as use-package, which would already handle this). From what I gathered empirically, it appears that if something is built-in, Emacs' package.el won't try to install -- it checks with package-installed-p on any call to package-install, which checks if the package is built-in with package-built-in-p as a fallback on cond --, but you can force installation from the archives by passing a package description object (defined as package-desc on package.el) instead of a symbol (let ((pkg-desc (assq 'org package-archive-contents))) (package-install pkg-desc)) and Emacs seems to be loading the newest version when it is a dependency of something else. Though I'm not really sure, as most of the packages I have from ELPA have the same version as the ones built-in on Emacs 28.0.91. I'll try and install Emacs 27 to check this out. In the mean time, I guess this would be a good opportunity to share a couple of functions I have with the purpose of installing packages. (defun pkg-description (package) "Return the description for PACKAGE. If PACKAGE is installed, the will be present on `package-alist', otherwise look for it in `package-archive-contents'." (or (cadr (assoc package package-alist)) (cadr (assoc package package-archive-contents (defun pkg-ensure-archive (package) "Install PACKAGE from the archives, if not already installed." (when-let ((pkg-desc (pkg-description package))) (unless (package-installed-p pkg-desc) (package-install-from-archive pkg-desc (defun require-package (package force) "Ensure that PACKAGE is installed. If FORCE is non-nil, force installation regardless if PACKAGE is built-in or not. First, use `package-installed-p' to check if PACKAGE was installed via the Emacs package manager, otherwise, try to `require' PACKAGE; this ensures that we don't require PACKAGE if it was installed using the package manager. If both of those fail, run `package-refresh-contents' and install PACKAGE." (unless (and (not force) (or (package-installed-p package) (require package nil 'no-error))) (unless (assoc package package-archive-contents) (package-refresh-contents)) (if force (pkg-ensure-archive package) (package-install package On the last one, the main function that I use, if FORCE is non-nil it will download and install the package from the archives even if it is built-in. Best regards, -- João Pedro de Amorim Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: [PATCH] Add support for $…$ latex fragments followed by a dash
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 divergent from the original subject -- and also keep in mind that this shouldn't be considered a solution to the problem, given that it should be considered for all users with different fonts --, but there are fonts that enforce Unicode (all characters, from what I understand, Unicode included) characters to be exactly 1 unit width, i.e. Unicode characters are the same widths as other characters. At least I can guarantee that any of the Term (all characters are the same length, but has ligatures) or Fixed (same as Term but no ligatures) for Iosekva [1] have this given property. [1] https://typeof.net/Iosevka/ Best regards, -- João Pedro de Amorim Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
