GNU bug report logs -
#18687
mw 0.1: modular MediaWiki interface for Emacs
Previous Next
Reported by: Ivan Shmakov <ivan <at> siamics.net>
Date: Sat, 11 Oct 2014 10:57:02 UTC
Severity: wishlist
Done: Stefan Kangas <stefan <at> marxist.se>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18687 in the body.
You can then email your comments to 18687 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
mediawiki-el <at> lists.everybody.org, tim <at> tim-landscheidt.de, mah <at> everybody.org, bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Sat, 11 Oct 2014 10:57:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ivan Shmakov <ivan <at> siamics.net>:
New bug report received and forwarded. Copy sent to
mediawiki-el <at> lists.everybody.org, tim <at> tim-landscheidt.de, mah <at> everybody.org, bug-gnu-emacs <at> gnu.org.
(Sat, 11 Oct 2014 10:57:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Package: emacs
Severity: wishlist
X-Debbugs-Cc: mediawiki-el <at> lists.everybody.org, tim <at> tim-landscheidt.de, mah <at> everybody.org
[This is a follow-up to a recent discussion at the mediawiki-el@
mailing list. Cc: to the list and, just in case it fails, both
to the original poster and to the mediawiki.el maintainer.]
I hereby request that my MW modular MediaWiki interface for
Emacs [1] be reviewed for inclusion into Emacs.
The interface is inspired by the mediawiki.el [2] module by Mark
A. Hershberger et al, but /should not/ contain any actual code
from there, and is not intended to be compatible. Still, I’ve
worked with mediawiki.el for quite some time, and at the least
vc-mw-buffer-checkin looks a bit similar to mediawiki-save-page.
Thus, it makes sense to check the rest of the code for any
(non-trivial) code that might accidently got written close
enough to that of mediawiki.el to require a rewrite for
copyright reasons.
[1] http://am-1.org/~ivan/packages-el/mw-0.1.tar
http://am-1.org/~ivan/packages-el/mw-0.1.tar.sig
[2] https://launchpad.net/mediawiki-el
Features
The package already allows for the use of the usual vc.el
C-x v v (IOW, “checkin”), C-x v l (vc-print-log), and
M-x vc-ediff (which could then be used to check a revision out)
commands on buffers (files) associated with MediaWiki pages.
Contrary to mediawiki.el, however, this package provides /no/
markup-specific “mode” of any kind.
The buffer (file) to page associations will be preserved in the
.emacs.desktop file (if one is used.)
The M-x mw-auth-log-in command uses auth-source-search.
(Although that code should be reviewed for correctness, as I’m
not familiar with auth-source.el at all.)
Assuming some effort on the part of the user, M-x mw-eww-preview
will show a “preview” of the current buffer’s markup
(as rendered via the MediaWiki API ‘parse’ call) using EWW.
Composition
The interface is comprised of the following individual modules
(in the dependency order):
• mw-api – basic API functions, including mw-api-call,
mw-api-adjoin, (as of yet undocumented) mw-api-get, and
mw-api-token;
• mw-buffer.el
– the mw-buffer-endpoint-uri, mw-buffer-page-id,
mw-buffer-page-revision, and mw-buffer-page-title
buffer-local variables, associating the buffer with a
MediaWiki instance, and possibly a specific page there;
– mw-buffer-associate-endpoint, mw-buffer-associate-page
commands to establish such a relation;
– the mw-buffer-page-query function to prepare an API query
parameter to select that page (or to adjoin one to the set
given);
• mw-info.el – the mw-info-describe-user, mw-info-describe-page
commands; and the (as of yet undocumented) mw-info-describe-1
function, also used by mw-auth-log-in;
• mw-auth.el – mw-auth-log-in, which authenticates the user on
the given (via mw-buffer-endpoint-uri) MediaWiki instance;
• vc-mw.el – (very incomplete) MediaWiki vc.el support; provides
just enough internals for C-x v v, C-x v l, and M-x vc-ediff;
• mw-eww.el – mw-eww-preview to preview the current buffer (as
rendered via the MediaWiki API ‘parse’ call) in the associated
EWW buffer; at the very least, it will require the patch from
http://debbugs.gnu.org/16211; (I have only tested it with my
own private version of EWW as of yet, however.)
The package comes with a “Quick-start guide” for its README.
The Russian version is also available from [3]. (The page also
served as a test for this code.)
[3] https://ru.wikibooks.org/wiki/?curid=14719
Bugs
The known deficiencies are as follows (in no particular order.)
• The interface does not provide any kind of ‘mediawiki-mode’.
It may be possible to re-use mediawiki-mode from [2].
(Personally, I just use fundamental-mode for now myself.)
• The mw-buffer-endpoint-uri variable is /not/ declared “safe.”
The use of vc.el facilities may result in unexpected API
calls, so it makes sense to leave it to the user as to what
specific MediaWiki API endpoint URIs to consider “trusted.”
There may also be a customizable list of “trusted” URIs, also
usable for the mw-buffer-associate-endpoint completion (should
there be one.)
• The mw-auth-log-in command currently writes the password to
the *MediaWiki* buffer in the plain, which is intended mainly
as a debugging aid. The user should take care to kill the
buffer when not needed.
• The code which is intended to obtain edit tokens may be broken
(it may be related to some recent MediaWiki changes.) If the
regular vc.el facilities fail to get a suitable edit token,
try evaluating (M-:) the following form in the page’s buffer:
(mw-api-call mw-buffer-endpoint-uri
"query" '(("meta" . "tokens") ("type" . "csrf")))
(The README suggest another form, which, however, gets the
token /as already seen/ in the MediaWiki responses. It does
not actually /request/ the token from MediaWiki.)
• After a new MediaWiki page has been created via vc.el, it’s
necessary to re-run M-x mw-buffer-associate-page to update the
respective buffer-local variables.
• There’s ought to be a function suitable for find-file-hook
that will associate the buffer with the page title (or page
identifier) derived from the filename.
• See README; also check the code itself for the FIXME:
comments.
--
FSF associate member #7257 np. Returning – Jami Sieber … 3013 B6A0 230E 334A
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Sun, 12 Oct 2014 04:48:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 18687 <at> debbugs.gnu.org (full text, mbox):
> I hereby request that my MW modular MediaWiki interface for
> Emacs [1] be reviewed for inclusion into Emacs.
I'd welcome it in GNU ELPA.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Sun, 12 Oct 2014 10:21:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 18687 <at> debbugs.gnu.org (full text, mbox):
>>>>> Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
[Cc: only to the lists.]
>> I hereby request that my MW modular MediaWiki interface for Emacs
>> [1] be reviewed for inclusion into Emacs.
> I'd welcome it in GNU ELPA.
Well, I guess it won’t do any harm, although I’d like to note
that the code is already available from a package.el-compatible
repository; say:
(add-to-list 'package-archives
'("(any-name-here)" . "http://am-1.org/~ivan/packages-el/"))
Now, there’s a technicality: is GNU ELPA considered a part of
GNU Emacs? I’ve checked a few files, and it seems that it is.
If not, however, I guess I’d have to file one another copyright
assignment paper.
--
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Mon, 13 Oct 2014 17:23:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 18687 <at> debbugs.gnu.org (full text, mbox):
Ivan Shmakov writes:
> The interface is inspired by the mediawiki.el [2] module by Mark
> A. Hershberger et al, but /should not/ contain any actual code
> from there,
Even if it does, I have copyright assignment on file with the FSF, so at
least that is not an issue.
Mark.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Tue, 14 Oct 2014 18:41:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 18687 <at> debbugs.gnu.org (full text, mbox):
> Now, there’s a technicality: is GNU ELPA considered a part of
> GNU Emacs? I’ve checked a few files, and it seems that it is.
For copyright assignments purposes, yes we do consider the two as one
and the same.
> If not, however, I guess I’d have to file one another copyright
> assignment paper.
No need,
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Tue, 14 Oct 2014 20:06:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 18687 <at> debbugs.gnu.org (full text, mbox):
>>>>> Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
>> Now, there’s a technicality: is GNU ELPA considered a part of
>> GNU Emacs? I’ve checked a few files, and it seems that it is.
> For copyright assignments purposes, yes we do consider the two as one
> and the same.
ACK, thanks for the clarification.
I’ve got ideas, and also proof-of-concept code, resolving some
of the issues mentioned in my original report (not to mention a
very basic but working ‘nnmw’ MediaWiki backend for Gnus.)
I hope to polish these over the course of the next few days and
release version 0.2 of the package, which I then request to be
added to GNU ELPA.
[…]
--
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Tue, 14 Oct 2014 23:52:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 18687 <at> debbugs.gnu.org (full text, mbox):
> I hope to polish these over the course of the next few days and
> release version 0.2 of the package, which I then request to be
> added to GNU ELPA.
GNU ELPA is built from a Git repository where development is intended
to happen. So the move does not have to coincide with a release.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Tue, 21 Oct 2014 16:34:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 18687 <at> debbugs.gnu.org (full text, mbox):
>> I hope to polish these over the course of the next few days and
>> release version 0.2 of the package, which I then request to be
>> added to GNU ELPA.
> GNU ELPA is built from a Git repository where development is intended
> to happen. So the move does not have to coincide with a release.
So, how should we go about it?
Do you still want to wait, or can we add it now?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Wed, 22 Oct 2014 21:37:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 18687 <at> debbugs.gnu.org (full text, mbox):
>>>>> Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
>>> I hope to polish these over the course of the next few days and
>>> release version 0.2 of the package, which I then request to be
>>> added to GNU ELPA.
(It took longer than I expected.)
>> GNU ELPA is built from a Git repository where development is
>> intended to happen. So the move does not have to coincide with a
>> release.
> So, how should we go about it? Do you still want to wait, or can we
> add it now?
The Git repository for the project is now available from [1–2].
Unless I’ll find something particularly wrong about it (and thus
decide to rewrite the history) by, say, Friday 20:00 UTC, I
guess it may be cloned as a GNU ELPA Git repository branch.
Assuming that I won’t be trying to get the ‘nnmw’ MediaWiki Gnus
backend to work, I hope to release 0.2 shortly thereafter.
What are the current development practices for ELPA, BTW? For
instance, would it be possible for me to rearrange the order of
the changes made by the ELPA maintainers while importing into my
own repository, or to cherry-pick, etc.?
[1] https://am-1.org/~ivan/archives/git/mw-el-2014.git
[2] https://am-1.org/~ivan/archives/git/gitweb.cgi?p=mw-el-2014.git
--
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Fri, 24 Oct 2014 18:56:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 18687 <at> debbugs.gnu.org (full text, mbox):
>>>>> Ivan Shmakov <ivan <at> siamics.net> writes:
> The Git repository for the project is now available from [1–2].
> Unless I’ll find something particularly wrong about it (and thus
> decide to rewrite the history) by, say, Friday 20:00 UTC, I guess it
> may be cloned as a GNU ELPA Git repository branch.
Virtually the only issue I was able to spot is the following
misleading Git comment:
commit 6bc8dff81ac633455ca7589a1d8f54b0f257d74c
Fixed: do not signal an error if ‘url-http-response-status’ is non-numeric.
mw-api.el (mw-api-response-check-http): Fixed: do not signal an
error if ‘url-http-response-status’ is non-numeric.
Considering the change itself, it should rather read:
mw-api.el (mw-api-response-check-http): Fixed: produce a less
cryptic error message if ‘url-http-response-status’ is non-numeric.
The ChangeLog (once I’ll add one) will use the latter form.
I have no reasons to delay this any further, and hereby ask for
the package to be reviewed and, if deemed GNUworthy, accepted
into GNU ELPA.
TIA.
[…]
> [1] https://am-1.org/~ivan/archives/git/mw-el-2014.git
> [2] https://am-1.org/~ivan/archives/git/gitweb.cgi?p=mw-el-2014.git
--
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Wed, 31 Dec 2014 12:14:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 18687 <at> debbugs.gnu.org (full text, mbox):
I kept improving the code throughout late October, late November
to early December, and then from December, 26…
And by now, as one might guess, – the vc-mw.el code has hardly
any readability left.
So, I’ve started cleaning up the resulting shameful mess.
Which includes moving a fair share of code from (my private
version of) vc-mw.el, as well as the “tokens” support bit from
mw-api.el, into the new mw-xapi.el module. Along the way,
I also hope to publish fixes for the few bugs which I was able
to spot in the code as available from [1, 2].
Also to note that I use this interface on more or less daily
basis (see [3]), so even though I’m lazy to publish the changes,
– rest assured that the code gets a whole lot of my attention.
(Not that the HTTP server logs indicate that anyone’s
interested, but still…)
[1] https://am-1.org/~ivan/archives/git/mw-el-2014.git
[2] https://am-1.org/~ivan/archives/git/gitweb.cgi?p=mw-el-2014.git
[3] https://tools.wmflabs.org/pirsquared/guc/?user=Ivan_Shmakov
Below is the summary of the features already implemented (but
yet to be made public) since the last published revision, in
roughly the order of decreasing “user visibility.”
• Fixed ‘vc-mw-buffer-page-state’ to support the new (as of
2014-11-20) two-argument interface in, – bringing back the
vc-mw.el compatibility with Emacs 25. (Support for the
Emacs 24 three-argument interface is retained.)
• Added support for vc-dir, vc-diff, and vc-revert operations.
• Adapted ‘mw-eww-preview’ to the ‘eww-display-html’
“multi-buffer” support added on 2014-11-10.
• New ‘vc-mw-revision-query-alist’ customizable variable,
allowing for an empty “continuation cookie” to be added to all
the vc-mw.el queries in order to silence a warning emitted by
the recent MediaWiki versions. And it allows for the set of
entries shown by vc-print-log to be customized, too, – to the
extent allowed by the remote MediaWiki instance.
• New ‘mw-buffer’, ‘mw-api’, and the package’s top-level ‘mw’
customization groups, allowing for easier customization of the
respective variables.
• The state determination code (vc-mw-buffer-page-state) will
now use SHA-1 digests of the revisions, either as returned by
the MediaWiki endpoint (including after running vc-print-log),
or as computed by vc-mw.el itself. (Prior to this change,
vc-mw.el had to retrieve the full content of the page to
discern the needs-update vs. needs-merge and update vs. edited
states.) Either way, the digests will be cached.
• Support for token types other than ‘csrf’ and ‘edit’.
• A few further fixes to vc-mw.el and mw-eww.el.
The features just planned are as follows.
• Associate buffer with a revision by its (cached) SHA-1.
Makes it possible to recover the state after, say, erasing the
desktop file.
• Customizable queries for mw-buffer.el, mw-eww.el, and
mw-info.el facilities, – also providing a way to get rid of
certain MediaWiki warnings.
• Asynchronous operation, – especially for vc-dir and
mw-buffer-try-file-name (try using vc-dir on a directory
holding some 768+ individual MediaWiki page files! or
restoring a desktop file listing all of them, anyway), but
also possibly for vc-print-log.
--
FSF associate member #7257 np. Conclusion — Apocalyptica 3013 B6A0 230E 334A
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Thu, 01 Jan 2015 16:07:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 18687 <at> debbugs.gnu.org (full text, mbox):
Any reason you haven't installed it in GNU ELPA yet?
Anything I can help with to do that?
Stefan
>>>>> "Ivan" == Ivan Shmakov <ivan <at> siamics.net> writes:
> I kept improving the code throughout late October, late November
> to early December, and then from December, 26…
> And by now, as one might guess, – the vc-mw.el code has hardly
> any readability left.
> So, I’ve started cleaning up the resulting shameful mess.
> Which includes moving a fair share of code from (my private
> version of) vc-mw.el, as well as the “tokens” support bit from
> mw-api.el, into the new mw-xapi.el module. Along the way,
> I also hope to publish fixes for the few bugs which I was able
> to spot in the code as available from [1, 2].
> Also to note that I use this interface on more or less daily
> basis (see [3]), so even though I’m lazy to publish the changes,
> – rest assured that the code gets a whole lot of my attention.
> (Not that the HTTP server logs indicate that anyone’s
> interested, but still…)
> [1] https://am-1.org/~ivan/archives/git/mw-el-2014.git
> [2] https://am-1.org/~ivan/archives/git/gitweb.cgi?p=mw-el-2014.git
> [3] https://tools.wmflabs.org/pirsquared/guc/?user=Ivan_Shmakov
> Below is the summary of the features already implemented (but
> yet to be made public) since the last published revision, in
> roughly the order of decreasing “user visibility.”
> • Fixed ‘vc-mw-buffer-page-state’ to support the new (as of
> 2014-11-20) two-argument interface in, – bringing back the
> vc-mw.el compatibility with Emacs 25. (Support for the
> Emacs 24 three-argument interface is retained.)
> • Added support for vc-dir, vc-diff, and vc-revert operations.
> • Adapted ‘mw-eww-preview’ to the ‘eww-display-html’
> “multi-buffer” support added on 2014-11-10.
> • New ‘vc-mw-revision-query-alist’ customizable variable,
> allowing for an empty “continuation cookie” to be added to all
> the vc-mw.el queries in order to silence a warning emitted by
> the recent MediaWiki versions. And it allows for the set of
> entries shown by vc-print-log to be customized, too, – to the
> extent allowed by the remote MediaWiki instance.
> • New ‘mw-buffer’, ‘mw-api’, and the package’s top-level ‘mw’
> customization groups, allowing for easier customization of the
> respective variables.
> • The state determination code (vc-mw-buffer-page-state) will
> now use SHA-1 digests of the revisions, either as returned by
> the MediaWiki endpoint (including after running vc-print-log),
> or as computed by vc-mw.el itself. (Prior to this change,
> vc-mw.el had to retrieve the full content of the page to
> discern the needs-update vs. needs-merge and update vs. edited
> states.) Either way, the digests will be cached.
> • Support for token types other than ‘csrf’ and ‘edit’.
> • A few further fixes to vc-mw.el and mw-eww.el.
> The features just planned are as follows.
> • Associate buffer with a revision by its (cached) SHA-1.
> Makes it possible to recover the state after, say, erasing the
> desktop file.
> • Customizable queries for mw-buffer.el, mw-eww.el, and
> mw-info.el facilities, – also providing a way to get rid of
> certain MediaWiki warnings.
> • Asynchronous operation, – especially for vc-dir and
> mw-buffer-try-file-name (try using vc-dir on a directory
> holding some 768+ individual MediaWiki page files! or
> restoring a desktop file listing all of them, anyway), but
> also possibly for vc-print-log.
> --
> FSF associate member #7257 np. Conclusion — Apocalyptica 3013 B6A0 230E 334A
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Thu, 01 Jan 2015 16:41:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 18687 <at> debbugs.gnu.org (full text, mbox):
>>>>> Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
[…]
> Any reason you haven't installed it in GNU ELPA yet? Anything I can
> help with to do that?
It was my understanding that someone with commit rights there
should clone my Git repository into a new GNU ELPA branch.
If so, – feel free to just do it. If not, – how do I proceed?
--
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Thu, 01 Jan 2015 21:04:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 18687 <at> debbugs.gnu.org (full text, mbox):
The following fixes to the code are now available from the usual
location [1, 2], in the fixes-x54a46898 branch.
4f203 Fixed type handling in ‘vc-mw-unprefix-revision’,
‘vc-mw-buffer-state’.
2eaba Use the new ‘eww-data’ variable and the fifth argument to
‘eww-display-html’.
21410 Support new two-argument call interface to ‘vc-mw-checkin’.
89180 Allow requesting for a specific revision in
‘mw-buffer-page-query’.
The first one eliminates some failure modes from the vc-mw.el
code, first and foremost the handling of nil value for
mw-buffer-page-revision (as in: when starting a new page.)
The latter two provide compatibility with the current versions
of eww.el and vc.el, respectively.
The last one extends the mw-buffer-page-query interface as
necessary for the yet to be published vc-mw.el changes.
[1] https://am-1.org/~ivan/archives/git/mw-el-2014.git
[2] https://am-1.org/~ivan/archives/git/gitweb.cgi?p=mw-el-2014.git
--
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Fri, 23 Jan 2015 14:44:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 18687 <at> debbugs.gnu.org (full text, mbox):
>>>>> Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
[…]
> Any reason you haven't installed it in GNU ELPA yet? Anything I can
> help with to do that?
ISTR that the importing of a new package as a GNU ELPA
Git branch was earlier referred to as “tricky”; is there any
guide on that I could use?
As for the reason, I guess I now have one: as new versions are
packaged as soon as the Version: header changes in the tree, I
guess I’d rather rewrite my Git history to accommodate for that.
(Oh, and the -pkg.el file is autogenerated, too!…)
--
FSF associate member #7257 Change of Heart — Bruce Dickinson B6A0 230E 334A
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Fri, 20 Feb 2015 07:10:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 18687 <at> debbugs.gnu.org (full text, mbox):
Some of the changes to the code are now went public [1, 2].
(Note the s/2014/2015/ year change in the URIs.)
[1] https://am-1.org/~ivan/archives/git/mw-el-2015.git
[2] https://am-1.org/~ivan/archives/git/gitweb.cgi?p=mw-el-2015.git
There, I’ve decided to rewind ‘master’ by three revisions (back
to 05d33edc); then put one of them (with the commit message
edited for better correctness), as well as 4 revisions formerly
of ‘fixes-x54a46898’ (see [3]), and 8 more fresh ones, to the
new ‘exp-x54e65706’ branch.
One of the changes (17ebb542) introduces the “top-level” mw.el
file, which provides a ‘defgroup’, and is required by GNU ELPA.
I hope someone could review if I’ve done this part correctly.
[3] news:87sifu43io.fsf <at> violet.siamics.net
http://debbugs.gnu.org/18687#msg44
This still leaves some code I’d like to add before pushing the
Git history to GNU ELPA, but I feel I’m roughly halfway of what
I’ve planned for 0.2.
A summary of the changes is as follows.
2fd573e0 New ‘mw-info-princ-alist’ and ‘mw-info-princ-voa’ functions.
The latter generalizes the former ‘vc-mw-print-revisions’.
6d740471 New ‘vc-mw-revision-query-alist’ customizable variable.
This one allows for an empty “continuation cookie” to be
added to all the vc-mw.el queries in order to silence a
warning emitted by newer MediaWiki versions. Also, it
allows for the set of entries shown by vc-print-log to be
customized, – to the extent supported by the remote
MediaWiki instance.
76b50f8c Fixed token logic in ‘vc-mw-buffer-page-info’ and
‘vc-mw-find-revision’.
Now the tokens will be correctly requested whenever the
remote is queried, /except/ for the log (IOW,
‘vc-mw-print-log’.)
b3a39473 New ‘mw-xapi-adjoin-token-request’ function.
bf8a70ce Promote several variables to customizable status.
Namely: ‘mw-api-response-hook’ (which is also marked for
autoloading, as a hook variable with a non-nil default
value), ‘mw-buffer-associate-page-hook’,
‘mw-buffer-endpoint-safe-hook’,
‘mw-buffer-try-file-name-hook’.
215e4a07 Split token handling into new mw-xapi.el off mw-api.el.
Which means that ‘mw-xapi-token’ is the new name for
‘mw-api-token’. Also introduces ‘mw-api-response-hook’.
21f8d096 Bump the version to 0.2 and update copyright years.
This does /not/ include mw.el, as updating that would
(I presume) trigger a release on GNU ELPA.
17ebb542 New mw.el replaces mw-pkg.el, anticipating the forthcoming
GNU ELPA inclusion.
Also introduces ‘mw-buffer’, ‘mw-api’, and the package’s
top-level ‘mw’ customization groups.
--
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Fri, 20 Feb 2015 17:15:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 18687 <at> debbugs.gnu.org (full text, mbox):
> ISTR that the importing of a new package as a GNU ELPA
> Git branch was earlier referred to as “tricky”; is there any
> guide on that I could use?
Either use "git subtree add ..." in the master branch of elpa.git or push
it as a new branch named `externals/<pkg>' in elpa.git.
Then adjust the `externals-list' file in the master branch of elpa.git.
> As for the reason, I guess I now have one: as new versions are
> packaged as soon as the Version: header changes in the tree, I
> guess I’d rather rewrite my Git history to accommodate for that.
The package-release machinery doesn't really pay attention to the
metadata, so if the HEAD has a "Version: 0" no package will be produced,
even if earlier revisions had "Version: <foo>".
So it doesn't require any history rewriting.
> (Oh, and the -pkg.el file is autogenerated, too!…)
Indeed.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Fri, 20 Feb 2015 18:31:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 18687 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>>>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> ISTR that the importing of a new package as a GNU ELPA Git branch
>> was earlier referred to as “tricky”; is there any guide on that I
>> could use?
> Either use "git subtree add ..." in the master branch of elpa.git or
> push it as a new branch named `externals/<pkg>' in elpa.git. Then
> adjust the `externals-list' file in the master branch of elpa.git.
IOW, with the patch MIMEd?
>> As for the reason, I guess I now have one: as new versions are
>> packaged as soon as the Version: header changes in the tree, I guess
>> I’d rather rewrite my Git history to accommodate for that.
> The package-release machinery doesn't really pay attention to the
> metadata, so if the HEAD has a "Version: 0" no package will be
> produced, even if earlier revisions had "Version: <foo>". So it
> doesn't require any history rewriting.
… Not to mention that there was no mw.el file to begin with.
Nevertheless, I’ve fixed a somewhat inaccurate wording in one of
the commit messages; combined the “version bump” change with the
addition of copyright notice to README and the “yearly update”
of the already present copyright notices; and get rid of a
misleading README change (which, among other things, documented
a change in behavior not yet actually made at that time.)
Now I’ve found some flaws in the topmost commit on the new
exp-x54e65706 branch, and intend to amend it shortly…
[…]
--
FSF associate member #7257 np. Eyes of Fire — Rainbow … 3013 B6A0 230E 334A
[Message part 2 (text/diff, inline)]
--- a/externals-list
+++ b/externals-list
@@ -36,6 +36,7 @@
("gnorb" :subtree "https://github.com/girzel/gnorb")
("ioccur" :subtree "https://github.com/thierryvolpiatto/ioccur.git")
("js2-mode" :subtree "https://github.com/mooz/js2-mode.git")
+ ("mw" :external "https://am-1.org/~ivan/archives/git/mw-el-2015.git")
("pabbrev" :external "https://github.com/phillord/pabbrev.git")
;;FIXME:("org" :external ??) ;; Need to introduce snapshots!!
("rudel" :external nil) ;; Was bzr::bzr://rudel.bzr.sourceforge.net/bzrroot/rudel/trunk
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Fri, 20 Feb 2015 19:53:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 18687 <at> debbugs.gnu.org (full text, mbox):
>> Either use "git subtree add ..." in the master branch of elpa.git or
>> push it as a new branch named `externals/<pkg>' in elpa.git. Then
>> adjust the `externals-list' file in the master branch of elpa.git.
> IOW, with the patch MIMEd?
If you add it as an externals/<pkg> branch, then yes, that looks right.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Sat, 29 Feb 2020 18:41:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 18687 <at> debbugs.gnu.org (full text, mbox):
Hi Ivan,
Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
>> I hereby request that my MW modular MediaWiki interface for
>> Emacs [1] be reviewed for inclusion into Emacs.
>
> I'd welcome it in GNU ELPA.
The last update here was five years ago as far as I can tell. What is
the current status of this? I note that the links to the repositories
provided in the bug report are dead.[1]
If we want to go ahead and include it in ELPA, we would need a new
link to the repository. Please let us know what you think.
Best regards,
Stefan Kangas
Footnotes:
[1] http://am-1.org/~ivan/packages-el/
https://am-1.org/~ivan/archives/git/mw-el-2014.git
https://am-1.org/~ivan/archives/git/gitweb.cgi?p=mw-el-2014.git
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Sat, 29 Feb 2020 19:56:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 18687 <at> debbugs.gnu.org (full text, mbox):
>>>>> On 2020-02-29 19:39:51 +0100, Stefan Kangas wrote:
>>>>> Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
>>> I hereby request that my MW modular MediaWiki interface for Emacs
>>> [1] be reviewed for inclusion into Emacs.
>> I’d welcome it in GNU ELPA.
> The last update here was five years ago as far as I can tell. What is
> the current status of this?
About the same: other commitments crept in and I’ve mostly
abandoned the code c. 2015. There’re probably a handful of
undocumented (as in: uncommitted) changes made in 2015‒2016,
but unlikely anything beyond that.
Obviously, the code may be somewhat out of date with the Emacs
facilities it relies upon – as well as MediaWiki API itself.
For one thing, the ‘login’ action it uses to authenticate user
against the wiki is no longer supported “as of MediaWiki 1.27” [2].
[2] http://mediawiki.org/wiki/API:Login
> I note that the links to the repositories provided in the bug report
> are dead. [1]
> If we want to go ahead and include it in ELPA, we would need a new
> link to the repository. Please let us know what you think.
> Footnotes:
> [1] http://am-1.org/~ivan/packages-el/
> https://am-1.org/~ivan/archives/git/mw-el-2014.git
> https://am-1.org/~ivan/archives/git/gitweb.cgi?p=mw-el-2014.git
I’ve re-uploaded the .tar file and the Git repository to the
following URIs, respectively.
http://am-1.org/~ivan/packages-el/
http://am-1.org/~ivan/archives/git/mw-el-2014.git/
--
FSF associate member #7257 http://am-1.org/~ivan/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Sun, 01 Mar 2020 01:39:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 18687 <at> debbugs.gnu.org (full text, mbox):
Ivan Shmakov <ivan <at> siamics.net> writes:
> > The last update here was five years ago as far as I can tell. What is
> > the current status of this?
>
> About the same: other commitments crept in and I’ve mostly
> abandoned the code c. 2015. There’re probably a handful of
> undocumented (as in: uncommitted) changes made in 2015‒2016,
> but unlikely anything beyond that.
Thank you for your prompt reply. Does the above mean that you have
lost interest in maintaining this code?
> Obviously, the code may be somewhat out of date with the Emacs
> facilities it relies upon – as well as MediaWiki API itself.
> For one thing, the ‘login’ action it uses to authenticate user
> against the wiki is no longer supported “as of MediaWiki 1.27” [2].
>
> [2] http://mediawiki.org/wiki/API:Login
Do you still think that this is relevant to include in ELPA? I'm not
at all familiar with Mediawiki or what this would be used for.
> I’ve re-uploaded the .tar file and the Git repository to the
> following URIs, respectively.
>
> http://am-1.org/~ivan/packages-el/
> http://am-1.org/~ivan/archives/git/mw-el-2014.git/
Thank you.
Best regards,
Stefan Kangas
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Mon, 02 Mar 2020 20:31:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 18687 <at> debbugs.gnu.org (full text, mbox):
> Do you still think that this is relevant to include in ELPA? I'm not
> at all familiar with Mediawiki or what this would be used for.
I'm not sure about mw.el, but Emacs could benefit from a client of the
MediaWiki API. My own mediawiki-el could (it has some bugs that need to
be address, and it needs to be updated for the Login API) be used to
edit MediaWiki sites (including Wikipedia) from within emacs.
There are Org Export methods that allow you to transform org files into
Wikitext and, using the MW API, you could use the export to set up
MediaWiki as a readable copy of your org files. Or, you could edit MW
pages using the Org syntax in emacs, using the MW API to publish them to
the wiki.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Sun, 08 Mar 2020 17:53:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 18687 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/x-markdown, inline)]
>> http://am-1.org/~ivan/packages-el/
>> http://am-1.org/~ivan/archives/git/mw-el-2014.git/
Thanks.
If the code might still be useful for future developments, I could add
it as an `externals/mw` branch in elpa.git but since it uses an outdated
API it wouldn't be worthwhile to release an actual GNU ELPA package for
it (i.e. I'd set the "Version:" to 0 to prevent building a package).
How does it compare to the current `mediawiki-el`?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Wed, 11 Mar 2020 01:32:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 18687 <at> debbugs.gnu.org (full text, mbox):
"Mark A. Hershberger" <mah <at> everybody.org> writes:
> I'm not sure about mw.el, but Emacs could benefit from a client of the
> MediaWiki API. My own mediawiki-el could (it has some bugs that need to
> be address, and it needs to be updated for the Login API) be used to
> edit MediaWiki sites (including Wikipedia) from within emacs.
Interesting. If you would like to submit your package to GNU ELPA, I
would suggest fixing the outstanding bugs you mention and sending it
to emacs-devel.
> There are Org Export methods that allow you to transform org files into
> Wikitext and, using the MW API, you could use the export to set up
> MediaWiki as a readable copy of your org files. Or, you could edit MW
> pages using the Org syntax in emacs, using the MW API to publish them to
> the wiki.
Thanks for the description. I almost never edit mediawiki pages, but
it sure sounds better to edit them in Emacs than in the web browser.
Best regards,
Stefan Kangas
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Tue, 04 Aug 2020 16:07:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 18687 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>> http://am-1.org/~ivan/packages-el/
>>> http://am-1.org/~ivan/archives/git/mw-el-2014.git/
>
> Thanks.
>
> If the code might still be useful for future developments, I could add
> it as an `externals/mw` branch in elpa.git but since it uses an outdated
> API it wouldn't be worthwhile to release an actual GNU ELPA package for
> it (i.e. I'd set the "Version:" to 0 to prevent building a package).
>
> How does it compare to the current `mediawiki-el`?
No update within 21 weeks. Does that mean that this should be closed, or
is there anything more to do here?
Best regards,
Stefan Kangas
Reply sent
to
Stefan Kangas <stefan <at> marxist.se>:
You have taken responsibility.
(Tue, 04 Aug 2020 16:49:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Ivan Shmakov <ivan <at> siamics.net>:
bug acknowledged by developer.
(Tue, 04 Aug 2020 16:49:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 18687-done <at> debbugs.gnu.org (full text, mbox):
Mark A. Hershberger <mah <at> nichework.com> writes:
> > No update within 21 weeks. Does that mean that this should be closed, or
> > is there anything more to do here?
>
> I think this should be closed. I'll submit mediawiki.el since I've recently been working on it again.
Good news! Closing the bug now then.
Best regards,
Stefan Kangas
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18687; Package
emacs.
(Tue, 04 Aug 2020 17:02:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 18687 <at> debbugs.gnu.org (full text, mbox):
> No update within 21 weeks. Does that mean that this should be closed, or
> is there anything more to do here?
I think this should be closed. I'll submit mediawiki.el since I've recently been working on it again.
Mark.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Wed, 02 Sep 2020 11:24:13 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 79 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.