monky-status doesn't work about monky HOT 15 CLOSED

run hg root and post the result

from monky.

$ hg root
/home/cycojesus/projets/cv

from monky.

i can't guess what's going wrong.(i am the only person using it as of now)

can you run

M-x toggle-debug-on-error and post the details

from monky.

Unfortunately there is no error per-se. Only this "File name too long" in the Messages buffer.
Also I get the same behavior with
LANG=C emacs -Q

One thing I forgot to mention is that I'm running emacs 24 compiled from the latest bzr head...
EDIT: Same behavior with Emacs 23.3.1, also launched with LANG=C and -Q

from monky.

Monky is running hg with --pager=no, which is an unrecognised option in plain, unconfigured hg. Then it reads stdout from the process (the mercurial help message is sent here) and it uses that entire string as the new working directory. This leads to the "file name too long" message ;)

There are three problems:

• It's not detecting that hg exits with a nonzero exit code, and continuing with bogus stdout
• It's discarding stderr, which contains the useful error message "hg: option --pager not recognized"
• It's making assumptions about which extensions the user has enabled.

The problem here is that both (I guess) cycojesus and I don't have the "pager" extension enabled.
There are two ways to solve this: Either add the pager extension to the default options to ensure it's always enabled (and the --pager option recognised) like so: --config 'extensions.pager=' or pass the option differently, via a config variable: --config 'pager.pager=' (setting pager to an empty string seems to effectively disable it). config-options can always be set. If the module that understands the option is disabled, it doesn't matter; other modules just ignore that option.

I don't know how to solve the problem that stderr isn't shown, nor how to solve the problem of the exit status (I'm not that familiar with elisp's standard library)

PS: Why is this extension hosted in git and not in mercurial? :(

from monky.

I have no idea how the hell to attach a patch-file here (god, I can't believe Github's issue tracker sucks even more than Bitbucket's!), so I'm just going to try inlining it:

diff --git a/monky.el b/monky.el
index 76ac8cb..132706f 100644
--- a/monky.el
+++ b/monky.el
@@ -34,7 +34,7 @@
   :group 'monky
   :type 'string)
 
-(defcustom monky-hg-standard-options '("--pager=no")
+(defcustom monky-hg-standard-options '("--config" "pager.pager=")
   "Standard options when running Hg."
   :group 'monky
   :type '(repeat string))

from monky.

@sjamaan explanations make perfect sense. I'm now at home on my personal laptop on which at some point I activated the pager extension and monky works.

(@sjamaan, you're supposed to:

1. fork the project
2. make your change(s)
3. send a pull request here
   a bit much for a one-liner maybe...)

from monky.

Yeah, for that small patch that's too much work, especially with $^%&(*% Git.

Anyway, I had a look at the Emacs docs and I think I've come up with a patch for catching the errors from the hg subprocess that mostly works. It's ugly and probably really clumsy elisp code, but like I said I'm not familiar with the emacs standard library ;)

diff --git a/monky.el b/monky.el
index 76ac8cb..7c36757 100644
--- a/monky.el
+++ b/monky.el
@@ -1220,16 +1220,22 @@ before the last command."
 
 ;;; Hg utils
 
-(defun monky-hg-insert (args)
+(defun monky-hg-insert (args tempfile)
   (apply #'process-file
         monky-hg-executable
-        nil (list t nil) nil
-        (append monky-hg-standard-options args)))
+        nil (list t tempfile) nil (append monky-hg-standard-options args)))
 
 (defun monky-hg-output (args)
-  (with-output-to-string
-    (with-current-buffer standard-output
-      (monky-hg-insert args))))
+  (let ((tempfile (make-temp-name "hg-errors")))
+    (unwind-protect
+        (with-output-to-string
+          (with-current-buffer standard-output
+            (unless (eql 0 (monky-hg-insert args tempfile))
+              (error (with-temp-buffer
+                       (insert-file-contents tempfile)
+                       (replace-regexp-in-string "[\r\n]*$" ""
+                                                 (buffer-string)))))))
+      (delete-file tempfile))))
 
 (defun monky-hg-string (&rest args)
   (monky-trim-line (monky-hg-output args)))
@@ -1414,7 +1420,7 @@ before the last command."
 
 (defun monky-insert-diff (file &optional status)
   (let ((p (point)))
-    (monky-hg-insert (list "diff" file))
+    (monky-hg-output (list "diff" file))
     (if (not (eq (char-before) ?\n))
        (insert "\n"))
     (save-restriction

(updated with cleaner code)

from monky.

I wasn't able to stage any changes yet to view a diff, but I think that second hunk in the diff is probably wrong. It should still check for errors though, so maybe it should be wrapped in (with-output-to-buffer ...) or something.

from monky.

Or perhaps make hg-insert do the error checking instead of monky-hg-output, that's probably better, come to think of it...

from monky.

This change doesn't seem address the handling of errors. If for whatever reason another unrecognised switch is passed or some other error occurs, monky won't detect that and will again re-use the error report as the root directory.

See my earlier comment at #1 (comment) for a patch that should fix that.

from monky.

Of course github doesn't allow me to reopen this issue. $%^!^&

from monky.

If for whatever reason another unrecognised switch is passed or some other error occurs, monky won't detect that

if it happens for some reason, then there is problem some where in the code, not in the hg-output(which runs the hg command and returns the stdout). Handling error is a separate issue i guess.

Why is this extension hosted in git and not in mercurial? :(

I use git and github more than hg and bitbucket. The reason i wrote this mode is that i am so used to magit.

from monky.

If it happens for some reason, then there is problem some where in the code, not in the hg-output (which runs the hg command and returns the stdout).

Bugs happen, and the design of hg-output is wrong if it doesn't ever throw an error, because all information about the fact that an error occurred is lost by the time hg-output returns; at that point all you have is the stdout contents as a string. Stderr is lost.

Fail early and fail noisily; it's no shame to let hg-output raise an error if the underlying hg operation returns an error. Yes, it's the calling code that caused the error situation (or not! For example, what happens if the hg binary is missing? Or what if it's a different program than you think it is? In that case it is hg-output that caused the error), but that doesn't matter. You want to be informed of it as soon as possible.

Handling error is a separate issue i guess.

I can open another ticket if you prefer.

from monky.

Bugs happen, and the design of hg-output is wrong if it doesn't ever throw an error, because all information about the fact that an error occurred is lost by the time hg-output returns; at that point all you have is the stdout contents as a string. Stderr is lost. Fail early and fail noisily; it's no shame to let hg-output raise an error if the underlying hg operation returns an error. Yes, it's the calling code that caused the error situation (or not! For example, what happens if the hg binary is missing? Or what if it's a different program than you think it is? In that case it is hg-output that caused the error), but that doesn't matter. You want to be informed of it as soon as possible

agreed.

from monky.