bug#18687: mw 0.1: modular MediaWiki interface for Emacs

bug#18687: mw 0.1: modular MediaWiki interface for Emacs

[Ivan Shmakov]

Package:  emacs
Severity: wishlist
X-Debbugs-Cc: mediawiki-el@lists.everybody.org, tim@tim-landscheidt.de, mah@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

bug#18687: mw 0.1: modular MediaWiki interface for Emacs

[Stefan Monnier]

> 	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

bug#18687: mw 0.1: modular MediaWiki interface for Emacs

[Ivan Shmakov]

>>>>> Stefan Monnier <monnier@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

bug#18687: mw 0.1: modular MediaWiki interface for Emacs

[Stefan Monnier]

> 	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

bug#18687: mw 0.1: modular MediaWiki interface for Emacs

[Ivan Shmakov]

>>>>> Stefan Monnier <monnier@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

bug#18687: mw 0.1: modular MediaWiki interface for Emacs

[Stefan Monnier]

> 	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

GNU ELPA; mw 0.1: modular MediaWiki interface for Emacs

[Ivan Shmakov]

>>>>> Stefan Monnier <monnier@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.

 > 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.

	Speaking of the GNU ELPA Git repository, – it seems to be a
	monolithic one (that is: no submodules are used.)  Curiously, is
	there a BCP on maintaining a package in a separate repository
	/and/ keeping its history mirrored in the GNU ELPA one?

	(FWIW, I’d certainly prefer having a repository of my own to
	keep the history of the MW package alone.)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: GNU ELPA; mw 0.1: modular MediaWiki interface for Emacs

[Nic Ferrier]

Ivan Shmakov <ivan@siamics.net> writes:

>>>>>> Stefan Monnier <monnier@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.
>
>  > 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.
>
> 	Speaking of the GNU ELPA Git repository, – it seems to be a
> 	monolithic one (that is: no submodules are used.)  Curiously, is
> 	there a BCP on maintaining a package in a separate repository
> 	/and/ keeping its history mirrored in the GNU ELPA one?
>
> 	(FWIW, I’d certainly prefer having a repository of my own to
> 	keep the history of the MW package alone.)

I offered marmalade's code base for managing the elpa repository.

It's an upload based system, you just push packages in it.

The code is GPLed so there's no concerns there.

Stefan didn't understand what I meant at the time. Hopefully he does
now.


Nic

Re: GNU ELPA; mw 0.1: modular MediaWiki interface for Emacs

[Stefan Monnier]

>> Speaking of the GNU ELPA Git repository, – it seems to be a
>> monolithic one (that is: no submodules are used.)

You get to choose (we call the two options "subtree" and "external").
Auctex, rudel, w3, and a few more are installed as "externals",
i.e. similar to Git submodules (tho hand-managed).

The "external" ones are stored as branches in the same repository
(e.g. the externals/auctex branch).

>> Curiously, is there a BCP on maintaining a package in a separate
>> repository /and/ keeping its history mirrored in the GNU ELPA one?

You can host a mirror elsewhere if you want.  But the elpa repository is
not read-only, so you'll need to pay attention to commits performed
there to keep the two trees in sync.

>> (FWIW, I’d certainly prefer having a repository of my own to
>> keep the history of the MW package alone.)

If you install your package as an "external", then the history is of
course kept separate.

> I offered marmalade's code base for managing the elpa repository.
> It's an upload based system, you just push packages in it.
> The code is GPLed so there's no concerns there.
> Stefan didn't understand what I meant at the time.  Hopefully he does
> now.

Now I understand you suggest we use Marmalade's scripts to manage the
GNU ELPA archive, but I still don't know what that means concretely.

The fact that we have a local storage of the source and VCS history
(with write access so that any Emacs maintainer can install fixes) is an
important design choice.  Would that easily fit into Marmalade's
code base?  How does Marmalade track commits to send them back to the
respective package's maintainer?


        Stefan

Re: GNU ELPA; mw 0.1: modular MediaWiki interface for Emacs

[Ivan Shmakov]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:

 >>> Speaking of the GNU ELPA Git repository, – it seems to be a
 >>> monolithic one (that is: no submodules are used.)

 > You get to choose (we call the two options "subtree" and "external").
 > Auctex, rudel, w3, and a few more are installed as "externals",
 > i. e. similar to Git submodules (tho hand-managed).

 > The "external" ones are stored as branches in the same repository
 > (e. g. the externals/auctex branch).

	Despite Git allowing for this (apparently), I tend to consider
	having several root revisions in a single repository somewhat
	confusing.  But I’ve got the idea.

	Why aren’t these managed as Git submodules, BTW?

 >>> Curiously, is there a BCP on maintaining a package in a separate
 >>> repository /and/ keeping its history mirrored in the GNU ELPA one?

 > You can host a mirror elsewhere if you want.  But the elpa repository
 > is not read-only, so you'll need to pay attention to commits
 > performed there to keep the two trees in sync.

	ACK, thanks for clarifying this up.

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: GNU ELPA; mw 0.1: modular MediaWiki interface for Emacs

[Stefan Monnier]

> 	Why aren’t these managed as Git submodules, BTW?

Can't remember.  I did look at them, but they didn't seem to provide
much functionality.  I guess it's mostly a case of NIH.  Tho maybe it
was because submodules can only refer to particular revisions, whereas
we want a reference to "the HEAD".

So should I add your mw as an "external" package?


        Stefan

Re: GNU ELPA; mw 0.1: modular MediaWiki interface for Emacs

[Nic Ferrier]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> Now I understand you suggest we use Marmalade's scripts to manage the
> GNU ELPA archive, but I still don't know what that means concretely.
>
> The fact that we have a local storage of the source and VCS history
> (with write access so that any Emacs maintainer can install fixes) is an
> important design choice.  Would that easily fit into Marmalade's
> code base?  How does Marmalade track commits to send them back to the
> respective package's maintainer?

It doesn't. You just upload the resulting package.

Hence avoiding the problem of managing the commits. The author does
that.


Nic

Re: GNU ELPA; mw 0.1: modular MediaWiki interface for Emacs

[Stefan Monnier]

>> Now I understand you suggest we use Marmalade's scripts to manage the
>> GNU ELPA archive, but I still don't know what that means concretely.
>> 
>> The fact that we have a local storage of the source and VCS history
>> (with write access so that any Emacs maintainer can install fixes) is an
>> important design choice.  Would that easily fit into Marmalade's
>> code base?  How does Marmalade track commits to send them back to the
>> respective package's maintainer?
> It doesn't. You just upload the resulting package.

Right, so it doesn't provide the features we need :-(


        Stefan

bug#18687: mw 0.1: modular MediaWiki interface for Emacs

[Stefan Monnier]

>> 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

bug#18687: mw 0.1: modular MediaWiki interface for Emacs

[Ivan Shmakov]

>>>>> Stefan Monnier <monnier@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

bug#18687: mw 0.1: modular MediaWiki interface for Emacs

[Ivan Shmakov]

>>>>> Ivan Shmakov <ivan@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

bug#18687: mw: modular MediaWiki interface for Emacs

[Ivan Shmakov]

	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

bug#18687: mw: modular MediaWiki interface for Emacs

[Stefan Monnier]

Any reason you haven't installed it in GNU ELPA yet?
Anything I can help with to do that?


        Stefan


>>>>> "Ivan" == Ivan Shmakov <ivan@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

bug#18687: mw: modular MediaWiki interface for Emacs

[Ivan Shmakov]

>>>>> Stefan Monnier <monnier@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

bug#18687: mw: modular MediaWiki interface for Emacs

[Ivan Shmakov]

>>>>> Stefan Monnier <monnier@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

a few questions on GNU ELPA

[Ivan Shmakov]

	Reading elpa/README left me with a few unanswered questions.

	First of all, – when the package is of the multi-file variety,
	would the “release machinery” be somehow offended should
	I import the pre-release history /without/ the respective
	PKG/PKG.el file, – used (AIUI) for its Version: metadata field?
	(I’ll then push that file in a separate “release” commit.)

	Now, that same file is going to have a dozen lines of code
	(excluding comments) at most (that is: mainly the ‘defgroup’ and
	‘provide’ forms.)  Should I use the GPL3+ notice for that file
	(as the rest of the code uses), or would the simple
	all-permissive license [1] be also acceptable?

	Also regarding the release machinery, do I understand it
	correctly that there’s currently no way to maintain several
	(say, “development” and “stable”) branches in GNU ELPA?

	TIA.

[1] https://gnu.org/software/texinfo/manual/texinfo/html_node/All_002dpermissive-Copying-License.html

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: a few questions on GNU ELPA

[Stefan Monnier]

> 	Reading elpa/README left me with a few unanswered questions.
> 	First of all, – when the package is of the multi-file variety,
> 	would the “release machinery” be somehow offended should
> 	I import the pre-release history /without/ the respective
> 	PKG/PKG.el file, – used (AIUI) for its Version: metadata field?
> 	(I’ll then push that file in a separate “release” commit.)

If the <pkg>.el file is missing from the HEAD revision, the nightly
deployment scripts may complain (to me), but if it's just missing in
some previous revision, that's of no consequence.

> 	Now, that same file is going to have a dozen lines of code
> 	(excluding comments) at most (that is: mainly the ‘defgroup’ and
> 	‘provide’ forms.)  Should I use the GPL3+ notice for that file
> 	(as the rest of the code uses), or would the simple
> 	all-permissive license [1] be also acceptable?

For auctex.el I just used the standard GPL3 notice.  Saved me some
valuable thinking ;-)

> 	Also regarding the release machinery, do I understand it
> 	correctly that there’s currently no way to maintain several
> 	(say, “development” and “stable”) branches in GNU ELPA?

That's right.  Of course, you can keep a "development" branch somewhere
in elpa.git if you want, but the GNU ELPA deployment scripts won't know
anything about it.


        Stefan

Re: a few questions on GNU ELPA

[Ivan Shmakov]

>>>>> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

 >> Reading elpa/README left me with a few unanswered questions.  First
 >> of all, – when the package is of the multi-file variety, would the
 >> “release machinery” be somehow offended should I import the
 >> pre-release history /without/ the respective PKG/PKG.el file, – used
 >> (AIUI) for its Version: metadata field?  (I’ll then push that file
 >> in a separate “release” commit.)

 > If the <pkg>.el file is missing from the HEAD revision, the nightly
 > deployment scripts may complain (to me), but if it's just missing in
 > some previous revision, that's of no consequence.

	ACK, thanks.

 >> Now, that same file is going to have a dozen lines of code
 >> (excluding comments) at most (that is: mainly the ‘defgroup’ and
 >> ‘provide’ forms.)  Should I use the GPL3+ notice for that file (as
 >> the rest of the code uses), or would the simple all-permissive
 >> license [1] be also acceptable?

 > For auctex.el I just used the standard GPL3 notice.  Saved me some
 > valuable thinking ;-)

	I believe that claiming GPLv3+ over a file which is probably not
	copyrightable in the first place is somewhat misleading.

	Furthermore, given that Emacs itself has files bearing that same
	notice (see leim/MISC-DIC/cangjie-table.cns, for instance, and
	also a few more also under leim/), I guess it will do no harm to
	have a trivial .el so licensed in GNU ELPA.  Or will it?

 >> Also regarding the release machinery, do I understand it correctly
 >> that there’s currently no way to maintain several (say,
 >> “development” and “stable”) branches in GNU ELPA?

 > That's right.  Of course, you can keep a "development" branch
 > somewhere in elpa.git if you want, but the GNU ELPA deployment
 > scripts won't know anything about it.

	ACK, thanks.

	BTW, as the resulting .tar file is going to differ to the one
	I’ve previously made available, does it make sense to use
	something like 0.1.1 for the GNU ELPA version, so to avoid the
	availability of two /different/ mw-0.1.tar files?  (I’d rather
	use something like 0.1-elpa instead, but that isn’t going to be
	accepted by version-to-list.)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: a few questions on GNU ELPA

[Stefan Monnier]

> 	have a trivial .el so licensed in GNU ELPA.  Or will it?

As I said: use a standard GPLv3 blurb and move on.  It's not worth
spending time on this.

> 	BTW, as the resulting .tar file is going to differ to the one
> 	I’ve previously made available, does it make sense to use
> 	something like 0.1.1 for the GNU ELPA version, so to avoid the
> 	availability of two /different/ mw-0.1.tar files?

Sounds fine, yes.


        Stefan

bug#18687: mw: modular MediaWiki interface for Emacs

[Stefan Monnier]

> 	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

bug#18687: mw: modular MediaWiki interface for Emacs

[Ivan Shmakov]

[-- Attachment #1: Type: text/plain, Size: 1617 bytes --]

>>>>> Stefan Monnier <monnier@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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/diff, Size: 573 bytes --]

--- 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

bug#18687: mw: modular MediaWiki interface for Emacs

[Stefan Monnier]

>> 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

bug#18687: mw: modular MediaWiki interface for Emacs

[Ivan Shmakov]

	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

bug#18687: mw: modular MediaWiki interface for Emacs

[Ivan Shmakov]

	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@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

bug#18687: mw 0.1: modular MediaWiki interface for Emacs

[Stefan Kangas]

Hi Ivan,

Stefan Monnier <monnier@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

bug#18687: mw 0.1: modular MediaWiki interface for Emacs

[Ivan Shmakov]

>>>>> On 2020-02-29 19:39:51 +0100, Stefan Kangas wrote:
>>>>> Stefan Monnier <monnier@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/

bug#18687: mw 0.1: modular MediaWiki interface for Emacs

[Stefan Kangas]

Ivan Shmakov <ivan@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

bug#18687: mw 0.1: modular MediaWiki interface for Emacs

[Stefan Monnier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/x-markdown; coding=UTF-8, Size: 461 bytes --]

>> 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

bug#18687: mw 0.1: modular MediaWiki interface for Emacs

[Stefan Kangas]

Stefan Monnier <monnier@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

bug#18687: mw 0.1: modular MediaWiki interface for Emacs

[Mark A. Hershberger]

> 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#18687: mw 0.1: modular MediaWiki interface for Emacs

[Stefan Kangas]

Mark A. Hershberger <mah@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

bug#18687: mw 0.1: modular MediaWiki interface for Emacs

[Mark A. Hershberger]

> 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.

bug#18687: mw 0.1: modular MediaWiki interface for Emacs

[Stefan Kangas]

"Mark A. Hershberger" <mah@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

bug#18687: mw 0.1: modular MediaWiki interface for Emacs

[Mark A. Hershberger]

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.