Stefan Monnier writes:
> That works as well, indeed. There are many ways to skin this cat.
Meow!
> Ah, OK. Not sure why you find it ugly, but there's no accounting
> for taste.
I find it a bit unnatural to load a file containing the autoloads by
hand. But maybe I have to change my
>> I use it with `emacs -Q ...` when I want to try and isolate a problem.
>
> Thanks for the hint. My approach to that for package `foo' until now
> was:
>
> (progn
> (package-initialize t)
> (package-activate 'foo))
That works as well, indeed. There are many ways to skin this cat.
[ In
Stefan Monnier writes:
> I use it with `emacs -Q ...` when I want to try and isolate a problem.
Thanks for the hint. My approach to that for package `foo' until now
was:
(progn
(package-initialize t)
(package-activate 'foo))
> Indeed, usually `package-activate(-all)` performs those
>> Side note: an AUCTeX installed with `package.el` behaves very similarly
>> except the autoloads file is called `auctex-autoloads.el` instead of
>> `loaddefs.el` and that this file takes care of the `add-to-list`, so
>> users just need to
>>
>> (load "~/Repos/el/auctex/auctex-autoloads")
>
>
>>> "AE" == Arash Esbati writes:
> Hi Tassilo,
> Tassilo Horn writes:
> Many thanks for working on this (and to Stefan as well).
>> So basically, we should decide now if we switch to going ELPA-only in
>> which case we'd not use master anymore but develop directly in main.
>> (I'd be in
>>> "TH" == Tassilo Horn writes:
> Yes, it's only "make" now.
> Am Di, 23. Apr 2024, um 20:56, schrieb Arash Esbati:
>> Tassilo Horn writes:
>>
>>> I think we need to adapt our instructions. To run straight from the
>>> clone, this seems to work fine:
>>>
>>> (add-to-list 'load-path
Stefan Monnier writes:
>> I think we need to adapt our instructions. To run straight from the
>> clone, this seems to work fine:
>>
>> (add-to-list 'load-path "~/Repos/el/auctex")
>> (load "~/Repos/el/auctex/loaddefs.el" nil t t)
>
> Side note: an AUCTeX installed with `package.el`
Yes, it's only "make" now.
Am Di, 23. Apr 2024, um 20:56, schrieb Arash Esbati:
> Tassilo Horn writes:
>
>> I think we need to adapt our instructions. To run straight from the
>> clone, this seems to work fine:
>>
>> (add-to-list 'load-path "~/Repos/el/auctex")
>> (load
Tassilo Horn writes:
> I think we need to adapt our instructions. To run straight from the
> clone, this seems to work fine:
>
> (add-to-list 'load-path "~/Repos/el/auctex")
> (load "~/Repos/el/auctex/loaddefs.el" nil t t)
Thanks, this does the job. Yes, we will have to adapt our
> I think we need to adapt our instructions. To run straight from the
> clone, this seems to work fine:
>
> (add-to-list 'load-path "~/Repos/el/auctex")
> (load "~/Repos/el/auctex/loaddefs.el" nil t t)
Side note: an AUCTeX installed with `package.el` behaves very similarly
except the
Arash Esbati writes:
Hi Arash,
> Thanks. I see an issue. I did:
>
> • $ git clone https://git.savannah.gnu.org/git/auctex.git auctex-elpa
> • $ cd auctex-elpa
> • $ git switch main
> • $ make -j8
> • $ emacs -Q
> • eval'ed in scratch:
> (load "~/path/to/auctex-elpa/auctex.el"
Tassilo Horn writes:
> Ok, I've adjusted the elpa recipe and merged from master to main. So
> hopefully there will be some new devel package anytime soon at
>
> https://elpa.gnu.org/devel/auctex.html
>
> If that works fine, we can bump the Version in auctex.el and do a
> regular ELPA release.
Arash Esbati writes:
>> So, those few users installing from GNU-devel ELPA are probably ready
>> and willing (if not eager) to try buggy software (that's what
>> GNU-devel is for). Especially since fixes are also made available
>> more promptly.
>
> Thanks. With this original intent of
Stefan Monnier writes:
>> Stefan, how would I make the switch on elpa? The package recipe I've
>> tested is this
>>
>> (auctex :url "https://git.savannah.gnu.org/git/auctex.git;
>> :branch "main"
>> :news "NEWS.org"
>> :make "elpa"
>> :doc ("doc/auctex.texi"
Stefan Monnier writes:
> FWIW, while we don't have good statistics to confirm it, I believe that
> very few users routinely install packages from GNU-devel: contrary to
> Melpa where the system is setup to encourage the use of Melpa over
> Melpa-stable, the GNU ELPA archive is setup so as to
> I was thinking about this too and my vote is to go with option 2 (i.e.,
> not your favorite ;-). I think it would make sense to have a sort of
> "staging area" where we can install code which might break or have other
> problems. Syncing it directly to ELPA-DEVEL and letting people install
>
Hi Tassilo,
Tassilo Horn writes:
> I've created a "main" branch (split off externals/auctex) and adjusted
> it such that it should be buildable on elpa and the mere act of changing
> the Version number in auctex.el in a commit would trigger a new ELPA
> release. And every other commit would at
> Stefan, how would I make the switch on elpa? The package recipe I've
> tested is this
>
> (auctex :url "https://git.savannah.gnu.org/git/auctex.git;
> :branch "main"
> :news "NEWS.org"
> :make "elpa"
> :doc ("doc/auctex.texi" "doc/preview-latex.texi"))
>
>
Tassilo Horn writes:
> - There's also a completely different alternative: make the
> externals/elpa the new "main" branch and drop master and tarball
> releases altogether. Is there still a justification for having
> them? I mean, we dropped XEmacs support anyway and it should be
>> Duh: it's `:doc`, not `:manual`!
>> Sorry!
> Haha, and then it works just fine. ;-)
Yay!
Stefan
Stefan Monnier writes:
>>> [ This assumes that the `:manual ...` thingy does
>>> successfully build the docs. ]
>>
>> This is where I'm not sure. At least it doesn't seem to have an effect
>> when running "make auctex.tar" locally (as said in my other mail). The
>> tar file only contains
> Yes, it is. But I need the distinction if the current version got
> there just now (in HEAD) or previously.
So just a "yes/no" kind of information? I wonder what you use it for.
>> [ This assumes that the `:manual ...` thingy does
>> successfully build the docs. ]
>
> This is where I'm
Stefan Monnier writes:
>>> Why do you need to look at diffs?
>> In order to extract the version number.
>
> I don't understand: it's right there in the file, you don't need the
> diffs to extract it, no?
Yes, it is. But I need the distinction if the current version got there
just now (in HEAD)
>> Why do you need to look at diffs?
> In order to extract the version number.
I don't understand: it's right there in the file, you don't need
the diffs to extract it, no?
> Does :manual ("doc/auctex.texi" "doc/preview-latex.texi") tell elpa to
> build the docs again although the recipe's :make
Tassilo Horn writes:
>> Our tarball build scripts can take care of building the Info files
>> and the `dir` (and moving them as needed), so maybe you can just add
>>
>> :manual ("doc/auctex.texi" "doc/preview-latex.texi")
>>
>> to the spec and that'll do the trick (with the advantage that
Stefan Monnier writes:
>> Why would I need the date of the last release?
>
> Don't know. I guess I misundersood what you meant by:
>
> Instead of looking at specially formatted lines in ChangeLog, it
> just looks at the git diffs to check when there was a "+;;
> Version: ..."
>> The "%H" above makes it output the commit hash where `Version:` was
>> changed, so you can replace that with an appropriate % thingy to get
>> the date instead.
> Why would I need the date of the last release?
Don't know. I guess I misundersood what you meant by:
Instead of looking at
Stefan Monnier writes:
Hi Stefan,
> FWIW, the `elpa-admin.el` code needs to do something similar and it
> asks Git a bit more directly (i.e. with the generating the diff):
>
>(elpaa--call
> (current-buffer)
> "git" "log" "-n1" "--oneline"
> Alright, I've had some time to do some fiddling. In the auctex
> repository, there's some new main branch (based on externals/auctex)
> where I've changed how AUCTEXVERSION and AUCTEXDATE are determined.
> Instead of looking at specially formatted lines in ChangeLog, it just
> looks at the git
Stefan Monnier writes:
Hi Stefan,
> Well, not for `make auctex.tar` where it's built from whatever is HEAD
> in `packages/auctex`. But in `elpa.gnu.git` HEAD is indeed pointing
> to `externals/`.
Alright, I've had some time to do some fiddling. In the auctex
repository, there's some new main
Hi Tassilo,
Tassilo Horn writes:
> Ah, no. What I mean is renaming the externals/elpa branch to "main"
> (which I currently have set to push to
> git.savannah.gnu.org/srv/git/emacs/elpa.git) in our own git
> (git.sv.gnu.org:/srv/git/auctex.git) and then use that as the same way
> as we're
>> And nowhere in the elpa repository do I find some statement that for
>> auctex the externals/auctex branch in elpa.git is to be used instead
>> of the main or master branch of auctex.git.
> It's always built from `externals/`.
Well, not for `make auctex.tar` where it's built from whatever is
> So I could just replace packages/auctex with some other clone of
> auctex.git?
Yes.
>> So your first and third steps above can happen at some other time.
> Alright. But I currently don't understand how "make packages/auctex"
> knows which commit to check out.
The first `make packages/auctex`
Stefan Monnier writes:
>> So just that I get it right, we'd do:
>>
>> - Make our former externals/elpa branch the new main branch
>> - git checkout -b main externals/elpa && git push
>> - Then clone elpa and setup the infrastructure as you said
>> - Edit elpa-packages locally (but
> So just that I get it right, we'd do:
>
> - Make our former externals/elpa branch the new main branch
> - git checkout -b main externals/elpa && git push
> - Then clone elpa and setup the infrastructure as you said
> - Edit elpa-packages locally (but don't yet commit/push)
> -
Uwe Brauer via Discussion list for AUCTeX developers
writes:
>> - There's also a completely different alternative: make the
>> externals/elpa the new "main" branch and drop master and tarball
>> releases altogether. Is there still a justification for having
>> them? I mean, we
Stefan Monnier writes:
>> --8<---cut here---start->8---
>> 2024-01-17 Mosè Giordano
>>
>> * Version 13.3 released.
>> --8<---cut here---end--->8---
>>
>> on top. So how should that work for ELPA releases?
>
>
Arash Esbati writes:
Hi Arash,
>> - There's also a completely different alternative: make the
>> externals/elpa the new "main" branch and drop master and tarball
>> releases altogether. Is there still a justification for having
>> them?
>
> Reg. dropping master: Do you mean we
>>> "TH" == Tassilo Horn writes:
> Hi all,
> some weeks ago, Philip Kaludercic saw a commit of mine triggering a new
> AUCTeX ELPA release and asked why there were changes to files which
> shouldn't be committed because they are generated from other files,
> e.g., info files.
> - There's
Tassilo Horn writes:
> I think it would be great if we could make it so that everyone of us
> could trigger a new ELPA release directly from the master branch by just
> incrementing the Version header which currently resides in auctex.el
Hi Tassilo,
besides the issues we have to resolve, I
Tassilo Horn [2024-04-09 14:09:53] wrote:
> Hi all,
>
> some weeks ago, Philip Kaludercic saw a commit of mine triggering a new
> AUCTeX ELPA release and asked why there were changes to files which
> shouldn't be committed because they are generated from other files,
> e.g., info files.
>
> The
Hi all,
some weeks ago, Philip Kaludercic saw a commit of mine triggering a new
AUCTeX ELPA release and asked why there were changes to files which
shouldn't be committed because they are generated from other files,
e.g., info files.
The reason is that at the time where we added AUCTeX to ELPA
42 matches
Mail list logo
