emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ELPA] some tex-related packages


From: Philip Kaludercic
Subject: Re: [ELPA] some tex-related packages
Date: Sat, 19 Oct 2024 14:54:59 +0000

Paul Nelson <ultrono@gmail.com> writes:

> Hi Philip,
>
>> > (and (fboundp 'avy-jump)
>> >     (require 'avy nil t)
>> >     (fboundp 'avy-jump))
>>
>> I should have explained that, my idea was to check if avy-jump was
>> actually made available by the `require' or not.  But I wouldn't
>> describe it as an idiom, or an elegant solution.  All I wanted to avoid
>> was that loading avy by hand is required after installing it as well.
>
> I agree that we should not assume avy has been loaded by hand or
> otherwise, but would have thought that the following would achieve the
> same:
>
> (and (require 'avy nil t)
>      (fboundp 'avy-jump))

Yeah, that should be good enough.

>> You were using both cl- and seq- functions.  I was suggesting to make
>> that explicit by `require'ing them as well.  IIRC the code using seq-
>> and the code cl- functions could have also respectively been written in
>> the other style, so I thought it wouldn't be bad to stick to one of the
>> two inside a single package.
>
> OK, gotcha (and indeed, I tweaked my code to just use seq).
>
>> Other than that, we can add the packages to ELPA, right?
>
> They're already on ELPA, which achieves my main goal of enabling
> colleagues to set them up and use them with a simple config.

Ah yes, I remember.  They were accidentally added in 8e73eaf44e0, which
is why I probably didn't recall adding them explicitly.

> There was the question raised in
> https://lists.gnu.org/archive/html/emacs-devel/2024-06/msg00959.html
> of whether tex-parens could be included in Emacs alongside tex-mode,
> so as to be more available and simpler to document.  The answer is
> certainly "yes", although I don't know who decides whether that should
> be done.

Just like with any change proposed to core Emacs, it is mostly a matter
of preparing a patch for emacs.git.  Unless you insist on preserving the
revision history, it doesn't really matter that the new feature was
developed as a package.

> There's also the question, discussed earlier in this thread, of
> whether some would fit better in AUCTeX, but I imagine I'll sort that
> out with Arash and co. on the AUCTeX list at some point.

My feel is that it would be a better fit for AUCTeX, but this doesn't
have to be a permanent decision either.  We can move it from AUCTeX to
the core, if it seems like the right thing to do.

> Thanks again and best,
>
> Paul

-- 
        Philip Kaludercic on siskin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]