Stefan Monnier writes:
> While I'm here, I think with the new setup we can get rid of
> `Makefile.in` and `auctex.el.in`.
True, I've deleted them on main.
Bye,
Tassilo
Hi all,
> Stefan Monnier writes:
>> And I like the way the manual is formatted. Compare this:
>> https://www.gnu.org/software/auctex/manual/auctex.html
>> with this:
>> https://elpa.gnu.org/devel/doc/auctex.html
> Hmm... nice. FWIW, the elpa rendering is the same as that of
> https://
> And I like the way the manual is formatted. Compare this:
> https://www.gnu.org/software/auctex/manual/auctex.html
> with this:
> https://elpa.gnu.org/devel/doc/auctex.html
Hmm... nice. FWIW, the elpa rendering is the same as that of
https://www.gnu.org/software/emacs/manual/html_
>>> "AE" == Arash Esbati writes:
> Tassilo Horn writes:
>> And there it is! So it seems to work now; you can stop knocking. ;-)
> And I like the way the manual is formatted. Compare this:
> https://www.gnu.org/software/auctex/manual/auctex.html
> with this:
> https://elpa.gnu.org/d
Tassilo Horn writes:
> And there it is! So it seems to work now; you can stop knocking. ;-)
And I like the way the manual is formatted. Compare this:
https://www.gnu.org/software/auctex/manual/auctex.html
with this:
https://elpa.gnu.org/devel/doc/auctex.html
Thanks!
Best, Arash
Tassilo Horn writes:
> Ah, ok, and you do that probably over multiple emacs sessions so that
> the buffer isn't there anymore.
Yes, my workflow is to write the ChangeLog entry directly after the
change and not before the actual commit, hence I need a file.
> You might as well customize change-l
> And there it is! So it seems to work now; you can stop knocking. ;-)
Yay! That wood should is happy,
Stefan
Arash Esbati writes:
>> It depends on how clean the clean target should make. I went for
>> very clean but wouldn't mind if the ChangeLog was kept. For what
>> purpose?
>
> I maintain a ChangeLog: I use 'C-x 4 a' to make a ChangeLog entry and
> depending on how I make a commit, I plonk that ent
Tassilo Horn writes:
> We are lucky. Good that we have him.
đ
> It depends on how clean the clean target should make. I went for very
> clean but wouldn't mind if the ChangeLog was kept. For what purpose?
I maintain a ChangeLog: I use 'C-x 4 a' to make a ChangeLog entry and
depending on how
Arash Esbati writes:
>> I totally don't mind when you fix my errors and oversights. That's
>> exactly why I've hired you. ;-)
>
> And I rely on Keita looknig after me ;-)
We are lucky. Good that we have him.
> I have another question about this rule:
>
> clean:
> rm -f $(ALL_G
Tassilo Horn writes:
> I totally don't mind when you fix my errors and oversights. That's
> exactly why I've hired you. ;-)
And I rely on Keita looknig after me ;-)
I have another question about this rule:
clean:
rm -f $(ALL_GENERATED_FILES) \
$(wildcard *.
Arash Esbati writes:
> Thanks. Do you mind if I add this change to it:
I totally don't mind when you fix my errors and oversights. That's
exactly why I've hired you. ;-)
>> Strange enough, it doesn't catch the cl-member warning above and also
>> not the ones Uwe mentioned
>
> I see what Uwe r
Tassilo Horn writes:
> Done.
Thanks. Do you mind if I add this change to it:
--8<---cut here---start->8---
diff --git a/GNUmakefile b/GNUmakefile
index 892d1c3c..999861cb 100644
--- a/GNUmakefile
+++ b/GNUmakefile
@@ -83,7 +83,8 @@ clean:
rm -f $(ALL
Tassilo Horn writes:
>>> The original problem was that elpa.gnu.org did not have TeX
>>> installed. After fixing it there was another problem of access
>>> rights when running TeX. I believe it is now fixed and it should get
>>> built within the next 6 hours. Knocking on wood. đ
>>
>> Sadly,
Arash Esbati writes:
>> If you have more than those, yes:
>>
>> In bib-find-next:
>> bib-cite.el:944:8: Warning: âfind-tagâ is an obsolete function (as of
>> 25.1); use âxref-find-definitionsâ instead.
>>
>> In end of data:
>> tex-info.el: Warning: the function âcl-memberâ might not be defined at
Tassilo Horn writes:
>> The original problem was that elpa.gnu.org did not have TeX
>> installed. After fixing it there was another problem of access
>> rights when running TeX. I believe it is now fixed and it should get
>> built within the next 6 hours. Knocking on wood. đ
>
> Sadly, the la
Tassilo Horn writes:
> If you have more than those, yes:
>
> In bib-find-next:
> bib-cite.el:944:8: Warning: âfind-tagâ is an obsolete function (as of
> 25.1); use âxref-find-definitionsâ instead.
>
> In end of data:
> tex-info.el: Warning: the function âcl-memberâ might not be defined at
> runt
Uwe Brauer writes:
>> No, certainly not. Getting rid of all that complicated stuff no one
>> of the current auctex maintainers understands and which is basically
>> not needed anymore, is exactly the purpose of the exercise.
>
> đ
>
> So I have to use the developer version in place, and testing
Uwe Brauer writes:
> First of all thanks Arash, that might have been a bit complicated. I
> appreciate it.
You're welcome. Actually not, I took most of it from our old
Makefile.in.
> I was late yesterday night, so since Tassilo already applied the patch,
>
> * From my git clone
>
> I pulled
>
> Uwe Brauer writes:
> If you have more than those, yes:
> In bib-find-next:
> bib-cite.el:944:8: Warning: âfind-tagâ is an obsolete function (as of 25.1);
> use âxref-find-definitionsâ instead.
> In end of data:
> tex-info.el: Warning: the function âcl-memberâ might not be defined at
> runt
Tassilo Horn writes:
> Thanks, applied with the minor change that I use $(wildcard *.el)
> instead of listing all lisp files and binding them to AUCSRC.
Thanks. Yes, $(wildcard *.el) is easier. I removed also some code
remainder.
Best, Arash
Uwe Brauer writes:
>> That has the benefit of showing warnings for missing
>> requires (undefined variables/functions).
>
> As I said, there was a bunch of warnings about undefined functions, for
> my emacs version. Do you want me to send them?
If you have more than those, yes:
In bib-find-nex
>>> "TH" == Tassilo Horn writes:
> Uwe Brauer writes:
>> 2. It was in my opinion *considerably* slower then the compilation
>> of the master branch: result time make -j8:
>> 69.088u 25.540s 1:20.66 365.2% 0+0k 1040+8448io 0pf+0w
> That's true because I chose to compile each lisp file one by one
Uwe Brauer writes:
> 2. It was in my opinion *considerably* slower then the compilation
>of the master branch: result time make -j8:
>69.088u 25.540s 1:20.66 365.2% 0+0k 1040+8448io 0pf+0w
That's true because I chose to compile each lisp file one by one instead
all in one cal
>>> "AE" == Arash Esbati writes:
> Stefan Monnier writes:
>>> AFAIU, using `update-file-autoloads' again means keeping track of all
>>> AUCTeX files in the new GNUmakefile, or is there a better solution?
>>
>> You should be able to use `update-directory-autoloads`.
>> It's a bit more cumbersome
Stefan Monnier writes:
>> But before investing time on Uwe's scenario: Stefan, do you know why
>> no new devel release has been built so far?
>
> You've presumably received copies (via auctex-devel) of the build
> error notification.
Oh, indeed. :-)
> The original problem was that elpa.gnu.org
Stefan Monnier writes:
> Which points out that maybe instead of changing `gitlog-to-auctexlog`
> it'd be easier to change the `make` rule so it doesn't build
> `ChangeLog` (and have another rule that does build `ChangeLog` for
> those cases where it's important).
That's what I've done now. Ther
Arash Esbati writes:
> I think `make-directory-autoloads' would be even easier, but it was
> introduced with 28.1, and we currently support 27.1, sigh! I think I
> can solve it with the patch below.
Thanks, applied with the minor change that I use $(wildcard *.el)
instead of listing all lisp fi
Stefan Monnier writes:
> The GNUmakefile tries to find the date of the commit you're building,
> and that's only available from the VCS metadata. The patch below
> should make it fallback to using the current date.
Thanks a lot! Applied.
Tassilo
Stefan Monnier writes:
>> AFAIU, using `update-file-autoloads' again means keeping track of all
>> AUCTeX files in the new GNUmakefile, or is there a better solution?
>
> You should be able to use `update-directory-autoloads`.
> It's a bit more cumbersome to use than `loaddefs-generate` but other
> AFAIU, using `update-file-autoloads' again means keeping track of all
> AUCTeX files in the new GNUmakefile, or is there a better solution?
You should be able to use `update-directory-autoloads`.
It's a bit more cumbersome to use than `loaddefs-generate` but other
than that it should be OK.
> gitlog-to-auctexlog is based on gitlog-to-emacslog. Should the issue be
> reported there as well? gitlog-to-emacslog isn't different in this
> regard:
> https://git.savannah.gnu.org/cgit/emacs.git/tree/build-aux/gitlog-to-emacslog#n62
`gitlog-to-emacslog` is used only to build the release tarb
Tassilo Horn writes:
> I just wanted to say that I'll have a look about making the build
> succeed in the absence of git or when running it not in a normal git
> clone when I find some spare time.
Thanks Tassilo. One other issue Uwe brought up was that
`loaddefs-generate' isn't available for Em
Stefan Monnier writes:
>> +# If this is not a Git repository, just generate an empty ChangeLog.
>> +test -d .git || {
>> + >"$output"
>> + exit
>> +}
>> +
>> # Get the new value for gen_origin from the latest version in the
>> repository.
>> new_origin=`git log --pretty=format:%H 'HEAD^!'` |
> But before investing time on Uwe's scenario: Stefan, do you know why
> no new devel release has been built so far?
You've presumably received copies (via auctex-devel) of the build
error notification. The original problem was that elpa.gnu.org did not
have TeX installed. After fixing it there
>>> "TH" == Tassilo Horn writes:
> Hi all,
> I just wanted to say that I'll have a look about making the build
> succeed in the absence of git or when running it not in a normal git
> clone when I find some spare time.
Thanks, I appreciate that.
> It also occurred to me that the ChangeLog is and
Hi all,
I just wanted to say that I'll have a look about making the build
succeed in the absence of git or when running it not in a normal git
clone when I find some spare time.
It also occurred to me that the ChangeLog is and has always be "wrong"
for ELPA releases. Basically, we generate it by
> +# If this is not a Git repository, just generate an empty ChangeLog.
> +test -d .git || {
> + >"$output"
> + exit
> +}
> +
> # Get the new value for gen_origin from the latest version in the repository.
> new_origin=`git log --pretty=format:%H 'HEAD^!'` || exit
I suspect it would be better
> Uwe Brauer writes:
> So I am confused now, shall I try out to make a symbolic link or not?
You can try either way. Try one of the symblic link or this patch:
diff --git a/build-aux/gitlog-to-auctexlog b/build-aux/gitlog-to-auctexlog
index 808597d5..944d90ff 100755
--- a/build-aux/gitlog-to
> I'm sorry, I was wrong about it. Uwe uses hg-git and the local repository
> doesn't contain .git directory. I don't remember well what hg-git does,
> but isn't there the "real" .git direcotry in the .hg directory? In other
> words, I suspect the directory structure is
> repo-dir -+- .hg
>>> "IK" == Ikumi Keita writes:
> Hi all,
> Hmm, build-aux/gitlog-to-auctexlog is not a perl script, actually is a
> Bourne shell script. I was looking at gitlog-to-changelog đ”
>> Arash Esbati writes:
>> Hmm, build-aux/gitlog-to-auctexlog contains[1]:
>> # If this is not a Git repository, j
> Stefan Monnier writes:
> Hmm, build-aux/gitlog-to-auctexlog contains[1]:
> # If this is not a Git repository, just generate an empty ChangeLog.
> test -d .git || {
> exit
> }
> Maybe Uwe has a .git directory in his setup, but it isn't a real .git
> directory as Git would expect?
There is
>>> "IK" == Ikumi Keita writes:
>> Uwe Brauer writes:
> "SM" == Stefan Monnier writes:
>>> Hence either
>>> 1) Uwe installs git
>>> He does have Git installed. He's just working in a directory that's not
>>> under Git's control.
>> That is correct. I prefer to clone the auctex devel
Hi all,
Hmm, build-aux/gitlog-to-auctexlog is not a perl script, actually is a
Bourne shell script. I was looking at gitlog-to-changelog đ”
> Arash Esbati writes:
> Hmm, build-aux/gitlog-to-auctexlog contains[1]:
> # If this is not a Git repository, just generate an empty ChangeLog.
> test -d
Stefan Monnier writes:
> IMO `build-aux/gitlog-to-auctexlog` should gracefully fail
> (e.g. generate an empty file, or put the Git error into that
> file).
Hmm, build-aux/gitlog-to-auctexlog contains[1]:
--8<---cut here---start->8---
# If this is not a Git re
> Uwe Brauer writes:
"SM" == Stefan Monnier writes:
>>> Hence either
>>> 1) Uwe installs git
>> He does have Git installed. He's just working in a directory that's not
>> under Git's control.
> That is correct. I prefer to clone the auctex devel repo with mercurial,
> since I am much
>>> "SM" == Stefan Monnier writes:
>> Hence either
>> 1) Uwe installs git
> He does have Git installed. He's just working in a directory that's not
> under Git's control.
That is correct. I prefer to clone the auctex devel repo with mercurial,
since I am much more acquainted with mercurial, an
> Hence either
> 1) Uwe installs git
He does have Git installed. He's just working in a directory that's not
under Git's control.
> 2) AUCTeX implements fallback in build-aux/gitlog-to-auctexlog
> is necessary to have Changelog.
IMO `build-aux/gitlog-to-auctexlog` should gracefully fail
(e.g. g
Hi Uwe,
> Uwe Brauer writes:
> Thanks I applied the patch and run make EMACSBIN=/opt/emacs29/bin/emacs
> Result:
> fatal: not a git repository (or any of the parent directories): .git
> sed -e 's|@lisppackagelispdir@|(file-name-directory load-file-name)|'\
> -e 's|@lisppackagedatadir@|(f
>>> "SM" == Stefan Monnier writes:
>> fatal: not a git repository (or any of the parent directories): .git
>> fatal: not a git repository (or any of the parent directories): .git
>> fatal: not a git repository (or any of the parent directories): .git
>> fatal: not a git repository (or any of the
> fatal: not a git repository (or any of the parent directories): .git
> fatal: not a git repository (or any of the parent directories): .git
> fatal: not a git repository (or any of the parent directories): .git
> fatal: not a git repository (or any of the parent directories): .git
> (cd doc; make
>>> "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 "~/Repos/
52 matches
Mail list logo
