Philip Kaludercic writes: > Akib Azmain Turja writes: > >>> ;;;###autoload >>> (defun gnu-indent-region (beg end) >>> @@ -88,14 +87,15 @@ When called non-interactively, indent text between BEG and END." >>> (send-region process beg end) >>> (process-send-eof process) >>> (redisplay) >>> - (while (process-live-p process) >>> - (sleep-for 0.01)) >>> + (while (accept-process-output process nil 10)) >> >> MILLISEC argument is obsolete, I used SECONDS instead. > > Actually, this change might have been pointless. I misremembed the > warning from (elisp) Accepting Output, that said you shouldn't combine > `accept-process-output' and `process-live-p', but what you were doing > was probably harmless. > > I guess the real question is why you don't use a synchronous process? > indent usually isn't that slow. > I don't like synchronous processes, they block Emacs completely. >>> (error "GNU Indent exited with non-zero status")) >>> (save-restriction >>> (let ((inhibit-read-only t)) >>> (narrow-to-region beg end) >>> + ;; Perhaps something should be done to try an preserve >>> + ;; the point after indentation? >>> (insert-file-contents temp-file nil nil nil >>> t)))) >> >> On my computer, the point doesn't move relative to text, because the >> fifth argument to insert-file-contents is t. > > My bad then. > >>> (delete-file temp-file))) >>> @@ -108,11 +108,24 @@ When called non-interactively, indent text between BEG and END." >>> (interactive) >>> (gnu-indent-region (point-min) (point-max))) >>> >>> +;; A little suggestion >>> +;;;###autoload >>> +(defun gnu-indent-defun-or-fill (arg) >>> + "Indent current function with GNU Indent. >>> +If point is in a comment, call `fill-paragraph' instead. A >>> +prefix argument ARG is passed to `fill-paragraph'." >>> + (interactive "P") >>> + (if (nth 8 (syntax-ppss)) ;if in a comment >>> + (fill-paragraph arg) >>> + (let ((bounds (bounds-of-thing-at-point 'defun))) >>> + (if (consp bounds) >>> + (gnu-indent-region (car bounds) (cdr bounds)) >>> + (user-error "No defun at point"))))) >>> + >> >> Great idea. But would it cause problem to assign copyright if I take >> your change? (AFAIK you've completed paperwork, but in this case you're >> not contributing to FSF-copyrighted code, so is this change covered by >> your paperwork? Right now, no, you're the copyright holder. (According >> to Section 2 of copyright assignment agreement sent to me.)) > > I don't think there should be an issue, as we want to add the package to > NonGNU ELPA. If the package is later moved to GNU ELPA, then my CA > should cover it. > >>> devhelp: >>> >>> diff --git a/devhelp.el b/devhelp.el >>> index 6b3d9a1ce9..05aeb1e18e 100644 >>> --- a/devhelp.el >>> +++ b/devhelp.el >>> @@ -48,6 +48,10 @@ >>> ;; "~/.guix-profile/share/doc/" >>> ;; "~/.guix-profile/share/gtk-doc/html/")) >>> >>> +;; Do you think it makes sense to automatically detect this (if the >>> +;; user has a ~/.guix-profile directory) and make the changes to the >>> +;; default value? >>> + >> >> Yes, it makes sense. But I didn't find any way to detected the >> directories, except heuristics. > > What would the problem be with checking the existence of these specific > (or other well known directories)? > > (append [default value] > (and (file-exists-p "~/.guix-profile/share/doc/" > (list "~/.guix-profile/share/doc/"))) > (and (file-exists-p "~/.guix-profile/share/gtk-doc/html/") > (list "~/.guix-profile/share/gtk-doc/html/")))) > I like this approach. Thanks. >>> @@ -219,6 +224,7 @@ If a single file was opened, only show that book's table of contents." >>> See `devhelp-toc' for more details." >>> (let ((inhibit-read-only t)) >>> (erase-buffer) >>> + ;; Why not prepare the document in SXML and then use `dom-print'? >>> (insert >>> "Table of contents