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
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
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:
> 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
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
16 matches
Mail list logo
