Ikumi Keita writes:
>> Anyway, I went ahead and applied Stefan's patch. I'll make an ELPA
>> release later this week if nobody sees a reason not to do it now.
>
> Thank you for preparing the ELPA release.
I've now had the time to release GNU AUCTeX 13.1.2 on ELPA. It should
appear anytime soon
Ikumi Keita writes:
>> No, I've just missed them when porting over the changes to generated
>> el files to el.in. If you have the time, feel free to manually apply
>> them.
>
> Done.
You are indispensable. Thank you!
Bye,
Tassilo
Hi Tassilo,
> Tassilo Horn writes:
> No, I've just missed them when porting over the changes to generated el
> files to el.in. If you have the time, feel free to manually apply them.
Done.
Bye,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine
Ikumi Keita writes:
>> Tassilo Horn writes:
>
>> Anyway, I went ahead and applied Stefan's patch. I'll make an ELPA
>> release later this week if nobody sees a reason not to do it now.
>
> Thank you for preparing the ELPA release.
>
> It seems that some parts of Stefan's patch are missing f
Hi Tassilo,
> Tassilo Horn writes:
> Anyway, I went ahead and applied Stefan's patch. I'll make an ELPA
> release later this week if nobody sees a reason not to do it now.
Thank you for preparing the ELPA release.
It seems that some parts of Stefan's patch are missing from the current
mas
Arash Esbati writes:
>> Yes, why not. But how about applying Stefan's "cosmetic patch"
>> (deleting the old advices and requiring nadvice instead)? That won't
>> make a difference for ELPA users but only for the tarball which will
>> require Emacs 25.1 then.
>
> I'm for stepping the required Em
Tassilo Horn writes:
> Yes, why not. But how about applying Stefan's "cosmetic patch"
> (deleting the old advices and requiring nadvice instead)? That won't
> make a difference for ELPA users but only for the tarball which will
> require Emacs 25.1 then.
I'm for stepping the required Emacs ver
Tassilo Horn writes:
>> Thanks for working on this. Should we now enter the public beta
>> phase (😉) and make a new ELPA release?
>
> Yes, why not. But how about applying Stefan's "cosmetic patch"
> (deleting the old advices and requiring nadvice instead)? That won't
> make a difference for EL
Arash Esbati writes:
>>> Looks good, go ahead. :-)
>>
>> Thanks, done.
>
> Thanks for working on this. Should we now enter the public beta phase
> (😉) and make a new ELPA release?
Yes, why not. But how about applying Stefan's "cosmetic patch"
(deleting the old advices and requiring nadvice ins
Ikumi Keita writes:
>> Tassilo Horn writes:
>> Looks good, go ahead. :-)
>
> Thanks, done.
Thanks for working on this. Should we now enter the public beta phase
(😉) and make a new ELPA release?
Best, Arash
> Tassilo Horn writes:
> Looks good, go ahead. :-)
Thanks, done.
Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine
Ikumi Keita writes:
Hi Keita,
>> I guess you could use `bound-and-true-p' for `LaTeX-using-Biber' here.
>
> Thanks, I incorporated your suggestion. I also added a slight
> modification to tests/command-expanstion.el to make regression tests
> pass for this particular revision. (I added the due c
Hi Tassilo,
> Tassilo Horn writes:
>> [2. patch 1 --- application/gzip;
>> 0001-Make-tex-buf.el-compile-without-require-latex.patch.gz]...
> I guess you could use `bound-and-true-p' for `LaTeX-using-Biber' here.
Thanks, I incorporated your suggestion. I also added a slight
modification to
Ikumi Keita writes:
Hi Keita,
> I expect the series of the attached patches would make their way to
> merge tex-buf.el into tex.el.
>
> Any comments or suggestions are welcome.
>
> [2. patch 1 --- application/gzip;
> 0001-Make-tex-buf.el-compile-without-require-latex.patch.gz]...
I guess you c
Hi Tassilo and all,
> Ikumi Keita writes:
> Since tex-buf.el requires latex.el also, it would introduce another
> circular dependency if all contents of tex-buf.el is moved into tex.el
> as-is. However, I hope that we can sort out that.
I expect the series of the attached patches would make
Uwe Brauer writes:
>> Maybe that could be fixed for the vc-annotate case because the
>> previous revision is most probably already in the "git blame" output
>> which lead to the current annotate buffer. But that's of course an
>> edge case which doesn't really fit in the general vc architecture.
> Uwe Brauer writes:
> Indeed, that's because vc tries to get the previous revision by issuing
> git rev-list -2 HEAD -- testnew.org
> but testnew.org has no previous revision. :-(
> Maybe that could be fixed for the vc-annotate case because the previous
> revision is most probably alrea
Uwe Brauer writes:
>> In Git it should work
>
> Well this does not work
>
> git init
> echo "First" > test.org
> git add -A test.org
> git commit -a -m "First"
> echo "Second" >> test.org
> git commit -a -m "Second"
> echo "Third" >> test.org
> git commit -a -m "Third"
> echo "Forth" >> test.or
> Uwe Brauer writes:
> In Git it should work
Well this does not work
git init
echo "First" > test.org
git add -A test.org
git commit -a -m "First"
echo "Second" >> test.org
git commit -a -m "Second"
echo "Third" >> test.org
git commit -a -m "Third"
echo "Forth" >> test.org
git commit -a -m
Uwe Brauer writes:
>> Uwe Brauer writes:
>
>> Almost all of them in this regard because they _track_ the operations
>> (like renaming a file) done while Git only records directory snapshots
>> and the commit graph. But that also means that you need to be careful
>> how you rearrange things in o
> Uwe Brauer writes:
> Almost all of them in this regard because they _track_ the operations
> (like renaming a file) done while Git only records directory snapshots
> and the commit graph. But that also means that you need to be careful
> how you rearrange things in other version control syste
Uwe Brauer writes:
>> Ikumi Keita writes:
>
>> As a historic note, the awful performance of 'git blame' particularly on
>> files like src/xdisp.c was a strong argument against moving Emacs
>> development to Git.
>
> Out of curiosity, what VC system has a better performance? Mercurial
> for sure
> Ikumi Keita writes:
> As a historic note, the awful performance of 'git blame' particularly on
> files like src/xdisp.c was a strong argument against moving Emacs
> development to Git.
Out of curiosity, what VC system has a better performance? Mercurial
for sure not. Bazaar?
Uwe Brauer
sm
Ikumi Keita writes:
> Hi David and Tassilo,
>
>> David Kastrup writes:
>> As a note aside: we are using Git as version control system these days.
>> Git doesn't maintain change histories in the first place but computes
>> them on the fly when calling "git blame" or similar. It has various
>
Hi David and Tassilo,
> David Kastrup writes:
> As a note aside: we are using Git as version control system these days.
> Git doesn't maintain change histories in the first place but computes
> them on the fly when calling "git blame" or similar. It has various
> options on how thoroughly it
Hi Keita,
> However, I think that we should first discuss what to do with this
> policy spelled out in tex.el:
> ;; The following dependencies are not done with autoload cookies since
> ;; they are only useful when tex.el is loaded, anyway. tex-buf.el
> ;; should remain unloaded as long as one is
Ikumi Keita writes:
> If AUCTeX is to keep it,
> (D) We should remove "(require 'tex-buf)" from at least plain-tex.el,
> context.el, tex-bar.el and tex-jp.el, adding some defvar's and
> declare-function's (or autoload's if necessary).
> (E; optional?) It's reasonable that preview.el has "
> Ikumi Keita writes:
> If AUCTeX is to keep it,
Of course we should do (A) or (B) in this case.
> What do you think about it?
Bye,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine
Hi all,
There is a small inconsistency with respect to the dependency on
tex-buf.el in current AUCTeX.
[How to confirm]
0. Disable preview-latex and tool bar mode in init.el and start a new
emacs session.
1. Open a LaTeX document, say, circ.tex.
2. Before invoking any external process, open a
29 matches
Mail list logo
