I have just ported info applicaiton from the latest master back to
previous versions, concluding with Emacs 25. I have used your library to
save me some typing, mainly for defvar-keymap; but I have no idea if
some other functions come into play too, probably they do.
However, I was missing some:
* net/browse-url (version 27):
browse-url-button-open-url (missing function)
Those below are interactive (but used as library functions in info.el):
* isearch (version 29):
isearch-fold-quotes-mode--state (missing defvar)
isearch-fold-quotes-mode (missing minor mode)
* simple.el (version 28):
goto-line (adds new optional argument)
goto-line-relatve (missing function)
From your manual I understand you don't want to port interactive
functions, and I have no idea if those would be useful as library
calls to other applications, they are however used so in info.el, so see
this as informative.
I was able to just copy those over from the latest master to a file and
load it, and they work all back to version 25 (I didn't tested with 24.4).
best regards
Hi Arthur,
thanks for the report! I'll answer below regarding the requested functions.
> I have just ported info applicaiton from the latest master back to> previous versions, concluding with Emacs 25. I have used your library to> save me some typing, mainly for defvar-keymap; but I have no idea if> some other functions come into play too, probably they do.
Do you plan to publish info as a package, even possibly as a :core package?
> However, I was missing some:> > * net/browse-url (version 27):> browse-url-button-open-url (missing function)
This function seems like a candidate for Compat, however one could also
consider to make browse-url an ELPA :core package. My general feeling is
that Compat is the ideal place for preloaded core functions (subr etc),
but not so much for other libraries, which could be packaged up
separately. Currently we don't provide browse-url functionality, so this
sets the bar a little bit higher and we should check if inclusion in
Compat really makes sense.
> Those below are interactive (but used as library functions in info.el):> > * isearch (version 29):> isearch-fold-quotes-mode--state (missing defvar)> isearch-fold-quotes-mode (missing minor mode)
Back porting Isearch functionality is out of scope of Compat. The reason
is that Isearch is quite convoluted and belongs firmly to the
user-level/interactive side of things. The library functions exposed by
Isearch are used for integration purposes with Isearch and not as
library functions with their own purpose, e.g., compare to subr
functions like `string-width`.
> * simple.el (version 28):> goto-line (adds new optional argument)> goto-line-relatve (missing function)
Both functions are out of scope of Compat, since they are declared as
`interactive-only'. We could port the non-interactive part back via
Compat, but then we would actively violate the design and contract of
these functions, since they are meant only for interactive use.
> From your manual I understand you don't want to port interactive> functions, and I have no idea if those would be useful as library> calls to other applications, they are however used so in info.el, so see> this as informative.> > I was able to just copy those over from the latest master to a file and> load it, and they work all back to version 25 (I didn't tested with 24.4).
Yes, porting back commands would probably work, but it is important that
we restrict the scope of Compat. The purpose of Compat is to provide
functions for package authors to ease back porting and not to provide
user-level functionality. The goal is not to magically turn Emacs 2x
into 29 by providing commands.
Note that it makes a difference if we look from the side of builtins or
from the side of external packages. External packages are usually
developed with low API requirements. They often target Emacs 25, 26 or
27. Such packages can easily and gradually take advantage of new
functionality via Compat.
The situation is different for builtin packages, which are not :core
packages at the same time and which are not developed with backward
compatibility in mind. Such packages quickly make use of newly
introduced APIs, new commands and even implementation details. This
makes it harder to turn those packages into :core packages and some
discipline is required in the process.
If the plan is to create a :core package out of a builtin we should
certainly make sure that we provide as much as possible via Compat, but
at the same time one still has to exercise some care in the :core
package itself, trying to restrict the amount of APIs used to the ones
which can be reasonably ported back.
For example Philip started to turn package.el into a :core package. We
considered to port `loaddefs-generate'. This function is a mostly
internal relevant for the installation process (autoload generation),
but which isn't useful for most packages. Therefore a potential
package.el :core package would make use of `loaddefs-generate' on new
Emacsen if available and fall back to older methods otherwise. See also
https://github.com/emacs-compat/compat/issues/23.
Daniel
Daniel Mendler <mail@daniel-mendler.de> writes:
> Hi Arthur,>> thanks for the report! I'll answer below regarding the requested functions.
Hi Daniel, thanks for very fast and informative answer!
>> I have just ported info applicaiton from the latest master back to>> previous versions, concluding with Emacs 25. I have used your library to>> save me some typing, mainly for defvar-keymap; but I have no idea if>> some other functions come into play too, probably they do.>> Do you plan to publish info as a package, even possibly as a :core package?
No, definitely not. I have reworked the commands in info.el and
help-mode.el to be callabel from any buffer, so I don't have to switch
to help and info all the time just to browse around; but they didn't
want the patch into Emacs. They will instead build a wrapper based on my
ideas so it works for all commands. Depending if they need to change
Emacs internals, they could make that wrapper a :core package so
hopefully it could be callable even from older Emacses.
By the way, I have no idea what :core package is :). I assume it is an
internal application/package evictoed to Elpa? In that case I don't
think they will do so with info.el; it is quite integral part to Emacs I
believe, that it probably wouldn't make sense to take it out of the core
either. They also build the standalone info viewer on top of Emacs and
info.el.
>> However, I was missing some:>> >> * net/browse-url (version 27):>> browse-url-button-open-url (missing function)>> This function seems like a candidate for Compat, however one could also> consider to make browse-url an ELPA :core package. My general feeling is> that Compat is the ideal place for preloaded core functions (subr etc),> but not so much for other libraries, which could be packaged up> separately. Currently we don't provide browse-url functionality, so this> sets the bar a little bit higher and we should check if inclusion in> Compat really makes sense.
TBH, I don't even know what that library/application does. I just bumped
into it now when older Emacsens complained about the missing function. I
personally would not mind to see as much as possible out of the core and
in Elpa. Perhaps if more packages were standalone and external, they
would be less sensitive to "versioning", ie. more or contemporary work,
fixes and features could possibly work with older versions, but that is
just theorycrafting now :).
>> Those below are interactive (but used as library functions in info.el):>> >> * isearch (version 29):>> isearch-fold-quotes-mode--state (missing defvar)>> isearch-fold-quotes-mode (missing minor mode)>> Back porting Isearch functionality is out of scope of Compat. The reason> is that Isearch is quite convoluted and belongs firmly to the> user-level/interactive side of things. The library functions exposed by> Isearch are used for integration purposes with Isearch and not as> library functions with their own purpose, e.g., compare to subr> functions like `string-width`.
Yes indeed, I understand, I saw in the manual, I am just a bit question
mark since some interactive functions are sometimes used as library
functions too, as the case was here.
>> * simple.el (version 28):>> goto-line (adds new optional argument)>> goto-line-relatve (missing function)>> Both functions are out of scope of Compat, since they are declared as> `interactive-only'. We could port the non-interactive part back via> Compat, but then we would actively violate the design and contract of> these functions, since they are meant only for interactive use.
Sometimes I don't understand the design issues in Emacs. This was one
such case. They are marked as such, and will produce the warning, yet
they have used them for example in info.el, with disabled warning :).
>> From your manual I understand you don't want to port interactive>> functions, and I have no idea if those would be useful as library>> calls to other applications, they are however used so in info.el, so see>> this as informative.>> >> I was able to just copy those over from the latest master to a file and>> load it, and they work all back to version 25 (I didn't tested with 24.4).>> Yes, porting back commands would probably work, but it is important that> we restrict the scope of Compat. The purpose of Compat is to provide> functions for package authors to ease back porting and not to provide> user-level functionality. The goal is not to magically turn Emacs 2x> into 29 by providing commands.
Yes, I undersand that, unfortunately due to Emacs being statically
compiled it is not possible either.
> Note that it makes a difference if we look from the side of builtins or> from the side of external packages. External packages are usually> developed with low API requirements. They often target Emacs 25, 26 or> 27. Such packages can easily and gradually take advantage of new> functionality via Compat.>> The situation is different for builtin packages, which are not :core> packages at the same time and which are not developed with backward> compatibility in mind. Such packages quickly make use of newly> introduced APIs, new commands and even implementation details. This> makes it harder to turn those packages into :core packages and some> discipline is required in the process.
Indeed. If it is even possible. Now, it just happends that info.el and
help are relatively stable parts of Emacs, so porting back info was not
a big deal. Compat + those three functions and two minor hacks was all
needed, but there is one big ugly problem: interactive form has been
reworked in Emacs 28. So Emacs 25, 26 and 27 report a malformed
interactive form, while 28 and recent master produce no
warning. However, everything seems to work, probably because info.el
does not use any of the new features.
> If the plan is to create a :core package out of a builtin we should> certainly make sure that we provide as much as possible via Compat, but> at the same time one still has to exercise some care in the :core> package itself, trying to restrict the amount of APIs used to the ones> which can be reasonably ported back.>> For example Philip started to turn package.el into a :core package. We> considered to port `loaddefs-generate'. This function is a mostly> internal relevant for the installation process (autoload generation),> but which isn't useful for most packages. Therefore a potential> package.el :core package would make use of `loaddefs-generate' on new> Emacsen if available and fall back to older methods otherwise. See also> https://github.com/emacs-compat/compat/issues/23.
I am not subscried to any of Emacs mailing lists longer; it used to take
me more time to sort out and remove mails than time I spent reading what
I was interested to read, so I am not much aware of recent developments.
Package.el is definitely a good candidate to be an external package,
since so many people are (for no good reasons) avoiding to use it
anyway. I personally do use package.el to fetch and install stuff,
though I generate autoloads myself as part of generating my init file,
which gives me basically same thing as package-quickstart but baked into
my init file.
I have peeked at the link, but I am not so familiar with compat at all,
so I don't think I have much to contribute in any regard. I can just
say, that I wouldn't hasitate to take the opportunity to rework
package.el where needed to provide better functionality even to older
Emacsen if possible. With other words, I would probably include
loaddefs-generate, and/or whatever is needed in package.el package, as
long as it is completely backwards API compatible with existing and
older package.el. That is orthogonal to the goals and purpose of the
compat library, but a reworked package.el shouldn't have something
against better experience even on older Emacsen I believe :).
> Daniel
On 7/3/23 14:39, Arthur Miller wrote:
> Hi Daniel, thanks for very fast and informative answer!
You're welcome!
>>> I have just ported info applicaiton from the latest master back to>>> previous versions, concluding with Emacs 25. I have used your library to>>> save me some typing, mainly for defvar-keymap; but I have no idea if>>> some other functions come into play too, probably they do.>>>> Do you plan to publish info as a package, even possibly as a :core package?> > No, definitely not. I have reworked the commands in info.el and> help-mode.el to be callabel from any buffer, so I don't have to switch> to help and info all the time just to browse around; but they didn't> want the patch into Emacs. They will instead build a wrapper based on my> ideas so it works for all commands. Depending if they need to change> Emacs internals, they could make that wrapper a :core package so> hopefully it could be callable even from older Emacses.
Okay, so it sounds as if we will end up with an acceptable solution in
Emacs itself? But if you have further (maybe controversial) extensions
for info.el you may consider creating an extra package and publish it
via one of the ELPAs. There are a few of this kind around, e.g., Drew
has many "+" packages. Such packages could act as a staging ground to
demonstrate the usefulness of new ideas.
> By the way, I have no idea what :core package is :). I assume it is an> internal application/package evictoed to Elpa? In that case I don't> think they will do so with info.el; it is quite integral part to Emacs I> believe, that it probably wouldn't make sense to take it out of the core> either. They also build the standalone info viewer on top of Emacs and> info.el.
:core packages are part of Emacs but at the same time available on ELPA
for older Emacs versions. Examples include project.el and xref.el.
> TBH, I don't even know what that library/application does. I just bumped> into it now when older Emacsens complained about the missing function. I> personally would not mind to see as much as possible out of the core and> in Elpa. Perhaps if more packages were standalone and external, they> would be less sensitive to "versioning", ie. more or contemporary work,> fixes and features could possibly work with older versions, but that is> just theorycrafting now :).
Yes, it would be nice to make more applications available via ELPA or
maybe even only via ELPA after removal from core. Compat can be helpful
for maintainers, since it bridges the API gaps somewhat for ELPA
packages which have to support multiple Emacs versions.
> Yes indeed, I understand, I saw in the manual, I am just a bit question> mark since some interactive functions are sometimes used as library> functions too, as the case was here.
Yes of course. The functions still below to the user level application
Isearch. The situation would be the same for other library functions,
e.g., belonging to Dired or Gnus. They would not fit well into Compat.
>> Both functions are out of scope of Compat, since they are declared as>> `interactive-only'. We could port the non-interactive part back via>> Compat, but then we would actively violate the design and contract of>> these functions, since they are meant only for interactive use.> > Sometimes I don't understand the design issues in Emacs. This was one> such case. They are marked as such, and will produce the warning, yet> they have used them for example in info.el, with disabled warning :).
Yes, sometimes `interactive-only' functions are used in wrapper
commands. I think I've also done this at least once in one of my
packages. However one could as well directly use `forward-line' to
implement the functionality directly.
> Package.el is definitely a good candidate to be an external package,> since so many people are (for no good reasons) avoiding to use it> anyway. I personally do use package.el to fetch and install stuff,> though I generate autoloads myself as part of generating my init file,> which gives me basically same thing as package-quickstart but baked into> my init file.
Yes, package.el could be a good candidate if more new package management
functionality ends up there. So far there is package-vc, which probably
deserves to be its own :core package. Given the plethora of external
package managers I would welcome improvements to package.el.
I personally use package.el since it is completely sufficient for my
purposes. I tend to only install highly robust packages anyway. So my
experience is mostly good except for some miscompilation problems. For
me from the package author perspective, the other package managers
create much larger problems since they circumvent my releases and often
lead to breakage for unexperienced users.
> I have peeked at the link, but I am not so familiar with compat at all,> so I don't think I have much to contribute in any regard. I can just> say, that I wouldn't hasitate to take the opportunity to rework> package.el where needed to provide better functionality even to older> Emacsen if possible. With other words, I would probably include> loaddefs-generate, and/or whatever is needed in package.el package, as> long as it is completely backwards API compatible with existing and> older package.el. That is orthogonal to the goals and purpose of the> compat library, but a reworked package.el shouldn't have something> against better experience even on older Emacsen I believe :).
I understand your sentiment, but I disagree about including arbitrary
functionality like `loaddefs-generate' even if it may seem like a cheap
solution to help porting package.el. We have to draw a line somewhere to
keep Compat maintainable. It is more valuable to include widely used
functionality, in particular where the value/weight ratio is more
reasonable. As alternative for this particular case one could publish
loaddefs-gens.el as :core package itself together with package.el. This
will be way more manageable than maintaining a separate implementation
as part of Compat.
To give you more background and to illustrate scope of Compat - a goal
of Compat is to reduce the dependency on libraries like dash.el and
s.el, which are popular since they give access to advanced list and
string manipulation even on old Emacs versions. For example imagine
someone proposing a new function `string-repeat' to subr.el as
replacement for `s-repeat' we have the opportunity to port it back via
Compat and make it available almost immediately for packages that way.
This way extensions to the standard library become available earlier for
package authors. This could potentially increase the motivation to
contribute standard library functions upstream.
Daniel
Daniel Mendler <mail@daniel-mendler.de> writes:
> On 7/3/23 14:39, Arthur Miller wrote:>> Hi Daniel, thanks for very fast and informative answer!>> You're welcome!>>>>> I have just ported info applicaiton from the latest master back to>>>> previous versions, concluding with Emacs 25. I have used your library to>>>> save me some typing, mainly for defvar-keymap; but I have no idea if>>>> some other functions come into play too, probably they do.>>>>>> Do you plan to publish info as a package, even possibly as a :core package?>> >> No, definitely not. I have reworked the commands in info.el and>> help-mode.el to be callabel from any buffer, so I don't have to switch>> to help and info all the time just to browse around; but they didn't>> want the patch into Emacs. They will instead build a wrapper based on my>> ideas so it works for all commands. Depending if they need to change>> Emacs internals, they could make that wrapper a :core package so>> hopefully it could be callable even from older Emacses. >> Okay, so it sounds as if we will end up with an acceptable solution in> Emacs itself?
Yes, I think they can pull it off. But hopefully it can be a :core
extension, since really, there is nothing speciall they need to make
that happen. Only things I have used were with-selected-window,
with-selected-frame and with-current-buffer to take care where input and
effects take place, when rewriting info and help commands, that is about
it.
> Emacs itself? But if you have further (maybe controversial) extensions> for info.el you may consider creating an extra package and publish it> via one of the ELPAs. There are a few of this kind around, e.g., Drew> has many "+" packages. Such packages could act as a staging ground to> demonstrate the usefulness of new ideas.
I know. Emacs-reloaded? A package where "reloaded" libraries take place?
:) No, let's skip that. I can put what I have on github, for the
curious bravehearts, let me just disable those warnings about
interactive form and type in some text about what it is, but I don't
think it is suitable for a package.
>> By the way, I have no idea what :core package is :). I assume it is an>> internal application/package evictoed to Elpa? In that case I don't>> think they will do so with info.el; it is quite integral part to Emacs I>> believe, that it probably wouldn't make sense to take it out of the core>> either. They also build the standalone info viewer on top of Emacs and>> info.el.>> :core packages are part of Emacs but at the same time available on ELPA> for older Emacs versions. Examples include project.el and xref.el.
Ok, I understand now. Thanks.
>> TBH, I don't even know what that library/application does. I just bumped>> into it now when older Emacsens complained about the missing function. I>> personally would not mind to see as much as possible out of the core and>> in Elpa. Perhaps if more packages were standalone and external, they>> would be less sensitive to "versioning", ie. more or contemporary work,>> fixes and features could possibly work with older versions, but that is>> just theorycrafting now :).>> Yes, it would be nice to make more applications available via ELPA or> maybe even only via ELPA after removal from core. Compat can be helpful> for maintainers, since it bridges the API gaps somewhat for ELPA> packages which have to support multiple Emacs versions.>>> Yes indeed, I understand, I saw in the manual, I am just a bit question>> mark since some interactive functions are sometimes used as library>> functions too, as the case was here.>> Yes of course. The functions still below to the user level application> Isearch. The situation would be the same for other library functions,> e.g., belonging to Dired or Gnus. They would not fit well into Compat.>>>> Both functions are out of scope of Compat, since they are declared as>>> `interactive-only'. We could port the non-interactive part back via>>> Compat, but then we would actively violate the design and contract of>>> these functions, since they are meant only for interactive use.>> >> Sometimes I don't understand the design issues in Emacs. This was one>> such case. They are marked as such, and will produce the warning, yet>> they have used them for example in info.el, with disabled warning :).>> Yes, sometimes `interactive-only' functions are used in wrapper> commands. I think I've also done this at least once in one of my> packages. However one could as well directly use `forward-line' to> implement the functionality directly.>>> Package.el is definitely a good candidate to be an external package,>> since so many people are (for no good reasons) avoiding to use it>> anyway. I personally do use package.el to fetch and install stuff,>> though I generate autoloads myself as part of generating my init file,>> which gives me basically same thing as package-quickstart but baked into>> my init file.>> Yes, package.el could be a good candidate if more new package management> functionality ends up there. So far there is package-vc, which probably> deserves to be its own :core package. Given the plethora of external> package managers I would welcome improvements to package.el.>> I personally use package.el since it is completely sufficient for my> purposes. I tend to only install highly robust packages anyway. So my> experience is mostly good except for some miscompilation problems. For> me from the package author perspective, the other package managers> create much larger problems since they circumvent my releases and often> lead to breakage for unexperienced users.
What miscompilation problems? I have seen people complain about byte
compilation order and warnings. There is no order, or rather to say
order is whatever directory-files returns, which is what OS returns, but
that could be easily patched.
Say a keyword like ;; compile-order: foo bar ...
Then package.el could byte compile files first in that list, in the
specified order, and then everything else. I don't think it would be
very difficult to implement, but there is always alternative to use load
explicitly instead of require when writing a package, so this isn't much
of a problem I guess.
>> I have peeked at the link, but I am not so familiar with compat at all,>> so I don't think I have much to contribute in any regard. I can just>> say, that I wouldn't hasitate to take the opportunity to rework>> package.el where needed to provide better functionality even to older>> Emacsen if possible. With other words, I would probably include>> loaddefs-generate, and/or whatever is needed in package.el package, as>> long as it is completely backwards API compatible with existing and>> older package.el. That is orthogonal to the goals and purpose of the>> compat library, but a reworked package.el shouldn't have something>> against better experience even on older Emacsen I believe :).>> I understand your sentiment, but I disagree about including arbitrary> functionality like `loaddefs-generate' even if it may seem like a cheap> solution to help porting package.el. We have to draw a line somewhere to> keep Compat maintainable. It is more valuable to include widely used> functionality, in particular where the value/weight ratio is more> reasonable. As alternative for this particular case one could publish> loaddefs-gens.el as :core package itself together with package.el. This> will be way more manageable than maintaining a separate implementation> as part of Compat.
Ah no no; I meant in package.el, not in compat. I understood you, about
compat and its goals :). Its own package is probably as welcome.
> To give you more background and to illustrate scope of Compat - a goal> of Compat is to reduce the dependency on libraries like dash.el and> s.el, which are popular since they give access to advanced list and> string manipulation even on old Emacs versions. For example imagine> someone proposing a new function `string-repeat' to subr.el as> replacement for `s-repeat' we have the opportunity to port it back via> Compat and make it available almost immediately for packages that way.> This way extensions to the standard library become available earlier for> package authors. This could potentially increase the motivation to> contribute standard library functions upstream.
Tottally understand that part.
Sure, people probably chose s.el, dash.el and f.el for extra
functionality, but I believe it is not eh only reason though. One of the
reasons might be the way hte API is formulated too. I personally find
Emacs API in many cases eunnecessary arcane, like just recently with
defvar-keymap that does not understand "remap", and Eli seems to be on a
war path with me about that one now :). Real reasons are probably
individual to each and every author.
> Daniel
On 7/3/23 15:51, Arthur Miller wrote:>> I personally use package.el
since it is completely sufficient for my
>> purposes. I tend to only install highly robust packages anyway. So my>> experience is mostly good except for some miscompilation problems. For>> me from the package author perspective, the other package managers>> create much larger problems since they circumvent my releases and often>> lead to breakage for unexperienced users.> > What miscompilation problems? I have seen people complain about byte> compilation order and warnings. There is no order, or rather to say> order is whatever directory-files returns, which is what OS returns, but> that could be easily patched.
The problem is that package.el doesn't seem to always reload packages,
which can then lead to compilation failures if two packages A and B are
installed, where B depends on A and A defines some problematic macros.
> Say a keyword like ;; compile-order: foo bar ...> > Then package.el could byte compile files first in that list, in the> specified order, and then everything else. I don't think it would be> very difficult to implement, but there is always alternative to use load> explicitly instead of require when writing a package, so this isn't much> of a problem I guess.
Yes, explicit load is a possible work around, but it still is not an
elegant solution. Some of the other package managers also suffer from
similar problems.
> Sure, people probably chose s.el, dash.el and f.el for extra> functionality, but I believe it is not eh only reason though. One of the> reasons might be the way hte API is formulated too.
Yes, some of the APIs may not be that well designed. But I still
consider using builtin APIs more idiomatic and easier to read than
throwing s or dash into the mix. To me it feels like an unnecessary
fight to attempt to write Clojure in Elisp.
> I personally find> Emacs API in many cases eunnecessary arcane, like just recently with> defvar-keymap that does not understand "remap", and Eli seems to be on a> war path with me about that one now :). Real reasons are probably> individual to each and every author.
Of course it does. Excerpt from corfu.el:
(defvar-keymap corfu-map
...
"<remap> <next-line>" #'corfu-next
...)
Daniel
Daniel Mendler <mail@daniel-mendler.de> writes:
> On 7/3/23 15:51, Arthur Miller wrote:>> I personally use package.el> since it is completely sufficient for my>>> purposes. I tend to only install highly robust packages anyway. So my>>> experience is mostly good except for some miscompilation problems. For>>> me from the package author perspective, the other package managers>>> create much larger problems since they circumvent my releases and often>>> lead to breakage for unexperienced users.>> >> What miscompilation problems? I have seen people complain about byte>> compilation order and warnings. There is no order, or rather to say>> order is whatever directory-files returns, which is what OS returns, but>> that could be easily patched.>> The problem is that package.el doesn't seem to always reload packages,> which can then lead to compilation failures if two packages A and B are> installed, where B depends on A and A defines some problematic macros.
Ah, ok. I am not so advanced, so I didn't experienced that one. I am mainy just
hacking and misusing Emacs proper :), but I understand what you mean there.
>> Say a keyword like ;; compile-order: foo bar ...>> >> Then package.el could byte compile files first in that list, in the>> specified order, and then everything else. I don't think it would be>> very difficult to implement, but there is always alternative to use load>> explicitly instead of require when writing a package, so this isn't much>> of a problem I guess.>> Yes, explicit load is a possible work around, but it still is not an> elegant solution. Some of the other package managers also suffer from> similar problems.
That is definitely not elegant. If its of interest, I can produce a hack
to compile files in specified order, some time in the future, but I am
not sure they would want it in package.el.
>> Sure, people probably chose s.el, dash.el and f.el for extra>> functionality, but I believe it is not eh only reason though. One of the>> reasons might be the way hte API is formulated too. >> Yes, some of the APIs may not be that well designed. But I still> consider using builtin APIs more idiomatic and easier to read than> throwing s or dash into the mix. To me it feels like an unnecessary> fight to attempt to write Clojure in Elisp.
Same here. I have personally never used s.el & co, even in cases where I
find Emacs API unnecessary convoluted; I always want the minimal amount
of deps. I am just trying to understand why people prefer those.
>> I personally find>> Emacs API in many cases eunnecessary arcane, like just recently with>> defvar-keymap that does not understand "remap", and Eli seems to be on a>> war path with me about that one now :). Real reasons are probably>> individual to each and every author.>> Of course it does. Excerpt from corfu.el:>> (defvar-keymap corfu-map> ...> "<remap> <next-line>" #'corfu-next> ...)
Ah, sorry, I had a brain freeze; <remap> works just fine, it was about
<tool-bar> :).
> Daniel
On 7/3/23 17:54, Arthur Miller wrote:
> Ah, sorry, I had a brain freeze; <remap> works just fine, it was about> <tool-bar> :).
Hmm, I think binding tool-bar or menu-bar events should work too. If it
doesn't it is a bug in Emacs.
Daniel