Re: compilation-forget-errors still used by tex-mode.el

Re: compilation-forget-errors still used by tex-mode.el

[Stefan Monnier]

>> Indeed.  But that's also how it worked in Emacs-21.3.
>> I'm only trying to fix the *new* bugs for now.

> It worked in 20.7, using tex-start-tex-marker.  My own hack uses that
> as well and so I didn't notice that it was lost in 21.3.

Aaaaaahhhhhh!  Thanks!
Looking back at the changelog of tex-mode.el, I see that I'm the one who
botched this (due to my lack of knowledge of first-error).

So that brings us back to:

>>>>> "Daniel" == Daniel Pfeiffer <dapfy@t-online.de> writes:
> Miles Bader <miles@lsi.nec.co.jp> skribis:
>> When I do `M-x compile RET', type make, and get a bunch of errors, and
>> then try `M-x next-error', it doesn't work, and instead just says
>> `Moved past last error'.
>> 
>> If I go to the *compilation* buffer, and use `C-c C-c' on an error
>> line, then that succeeds, and subsequent uses of `next-error' also work
>> properly.

> Aha, that's a consequence of scrolling along with the output as it pours in,
> unless you move the cursor.  The (point) in the *compilation* buffer serves as
> the indication where the 'current' error is.  The next one will be found from
> there onwards.  Four possibilities:

So as Markus has reminded us, in Emacs-20.7 tex-mode correctly handled
`first-error' in that it brought compile.el back to the first error of the
last TeX run rather than the first error in the buffer.

So we need:
- point (of course).
- "current error" (the current code uses point for that, but the old code
  had a separate notion for this, represented by a mix of
  compilation-parsing-end and compilation-old-error-list).
- "beginning of errors" (to reset "current error" when we call
  `first-error').

> - not scroll along but stay at the beginning (not so nice)

Not an option for comint buffers.

> - keep a marker to the next position (strange to not find the next error
>   where the cursor is, though)

That's the old way.  It's actually not so strange in practice.
And it allows the user to move around in the *compile* buffer without
losing track of the "current error" (I'm not sure how important this is,
but I suspect that some people rely on this on a regular basis).

> - remember (or check) that we haven't visited an error from this buffer,
>   and only in that case jump to the beginning

But we have to define what is meant by "have visited an error already" for
buffers where several commands might be executed.

> - generally wrap around to the begining if any errors were skipped, and
>   only signal this error if none are left (seems the most useful and
>   consistent solution :-)

This indeed seems like an option, although I'm not sure whether people would
find it helpful or annoying.  If it's not too much coding, it might be
worth trying it out.
In that case the "beginning of errors" could be encoded by marking all
previous errors as visited.

To be honest the idea of annotating every error with a `visited' flag
doesn't sound too great.

My current patch basically reproduces the behavior of the old code:
it re-introduces `compilation-parsing-end' and uses it as the "current
error" marker.  While I think that using a marker is the best option and
that re-introducing `compilation-parsing-end' for compatibility purposes is
right as well, I'm not convinced that merging the two is such a hot idea.
We should maybe just introduce a new `compilation-current-error' marker
instead and keep `compilation-parsing-end' for compatibility only.


        Stefan

Re: compilation-forget-errors still used by tex-mode.el

[Kim F. Storm]

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

> > - keep a marker to the next position (strange to not find the next error
> >   where the cursor is, though)
> 
> That's the old way.  It's actually not so strange in practice.
> And it allows the user to move around in the *compile* buffer without
> losing track of the "current error" (I'm not sure how important this is,
> but I suspect that some people rely on this on a regular basis).

Sometimes it would be nice if next error followed the cursor, other times not.
Problem is to say when you want one or the other behaviour.

There should be commands for both, e.g. C-x ` (next-error) takes next
error independently of point, while some other command (I'd prefer
RET, but that's another, old, discussion) takes you to the error on the
current line (or next error following it (and moves next-error marker
accordingly).

> 
> > - generally wrap around to the begining if any errors were skipped, and
> >   only signal this error if none are left (seems the most useful and
> >   consistent solution :-)
> 
> This indeed seems like an option, although I'm not sure whether people would
> find it helpful or annoying.  

So it should be an option.  It should be off in basic compilation
buffers, but for some modes, it might be quite useful.  

F.ex. in grep, where you could jump to specific occurrences first
(e.g. to fix a declaration or prototype), and then go through the rest
afterwards (to fix uses).


>                               If it's not too much coding, it might be
> worth trying it out.
> In that case the "beginning of errors" could be encoded by marking all
> previous errors as visited.
> 
> To be honest the idea of annotating every error with a `visited' flag
> doesn't sound too great.

As I said, it might be useful, but there should definitely be some
way to turn it off (or clear the visited flags).

> 
> My current patch basically reproduces the behavior of the old code:
> it re-introduces `compilation-parsing-end' and uses it as the "current
> error" marker.  While I think that using a marker is the best option and
> that re-introducing `compilation-parsing-end' for compatibility purposes is
> right as well, I'm not convinced that merging the two is such a hot idea.
> We should maybe just introduce a new `compilation-current-error' marker
> instead and keep `compilation-parsing-end' for compatibility only.

And add compilation-current-error to overlay-arrow-variable-list :-)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: compilation-forget-errors still used by tex-mode.el

[Stefan Monnier]

> There should be commands for both, e.g. C-x ` (next-error) takes next
> error independently of point, while some other command (I'd prefer
> RET, but that's another, old, discussion) takes you to the error on the
> current line (or next error following it (and moves next-error marker
> accordingly).

There's already M-RET (or something like that: compilation-goto-error,
together with the mouse version compilation-mouse-goto-error).

>> My current patch basically reproduces the behavior of the old code:
>> it re-introduces `compilation-parsing-end' and uses it as the "current
>> error" marker.  While I think that using a marker is the best option and
>> that re-introducing `compilation-parsing-end' for compatibility purposes is
>> right as well, I'm not convinced that merging the two is such a hot idea.
>> We should maybe just introduce a new `compilation-current-error' marker
>> instead and keep `compilation-parsing-end' for compatibility only.

> And add compilation-current-error to overlay-arrow-variable-list :-)

Now there's an idea.


        Stefan

Re: compilation-forget-errors still used by tex-mode.el

[Miles Bader]

On Fri, Mar 19, 2004 at 09:25:39AM -0500, Stefan Monnier wrote:
> > There should be commands for both, e.g. C-x ` (next-error) takes next
> > error independently of point, while some other command (I'd prefer
> > RET, but that's another, old, discussion) takes you to the error on the
> > current line (or next error following it (and moves next-error marker
> > accordingly).
> 
> There's already M-RET (or something like that: compilation-goto-error,
> together with the mouse version compilation-mouse-goto-error).

There's certainly `C-c C-c', which is what I always use...

-Miles
-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

Re: compilation-forget-errors still used by tex-mode.el

[Markus Rost]

As for ideas:  What about having for tex compilation parses an option
like

(defcustom tex-plus-error-parse-level nil
  "*If non-nil, consider also over/underfull hbox messages as errors.
This enables you to jump to the corresponding source locations."
  :type 'boolean
  :group 'tex-run)

I once wrote a corresponding hack and use it a lot.

It seems however that one can't use it directly with the new
compile.el and I don't have the time to adjust it.  In case someone is
interested, I append here the file containing the code.


===File ~/emacs/lisp/emacs-21/tex-plus.el===================
(let ((l0 (car ispell-tex-skip-alists))
      (l1 (cadr ispell-tex-skip-alists)))
  (add-to-list 'l0 '("\\\\\\(eq\\)?ref" ispell-tex-arg-end))
  (add-to-list 'l0 '("\\\\label" ispell-tex-arg-end))
  (add-to-list 'l0 '("[^\\]%.*$"))
  (add-to-list 'l1 '("gather\\*?" . "\\\\end[ \t\n]*{[ \t\n]*gather\\*?[ \t\n]*}") t)
  (add-to-list 'l1 '("align\\*?" . "\\\\end[ \t\n]*{[ \t\n]*align\\*?[ \t\n]*}") t)
  (setcar ispell-tex-skip-alists l0)
  (setcar (cdr ispell-tex-skip-alists) l1))

(require 'tex-mode)

(if (string-lessp emacs-version "21.3.49")
    (defvar tex-compile-commands nil))

(defvar tex-compile-commands-0 tex-compile-commands
  "The original value of `tex-compile-commands'
Used in combination with `tex-compile-commands-1'
Don't set this variable yourself.")

(defcustom tex-compile-commands-1 nil
  "List of additional commands for `tex-compile'.
Prepended to `tex-compile-commands-0' to set `tex-compile-commands'.
Set this variable with customize.
See `tex-compile-commands' for the syntax."
  :type '(repeat (list
		  (radio  :tag "Commands"
			  string sexp)
		  (choice :tag "Input File"
			  (string :tag "String")
			  (const :tag "TeX files of the document" t)
			  (const :tag "Don't know" nil))
		  (choice :tag "Output File"
			  (string :tag "String")
			  (const :tag "No Output File" nil))))
  :set (lambda (symbol value)
	 (set-default symbol value)
	 (setq tex-compile-commands
	       (append value (copy-sequence tex-compile-commands-0))))
  :group 'tex-run)

;;; Customize the tex-shell.
;; I want it to use HISTFILE=~/.bash/.bash1_history

(defcustom tex-shell-hook nil
  "Hook for `tex-shell'."
  :type 'hook
  :group 'tex-run)

(defcustom tex-shell-file-name nil
  "*If non-nil, the shell file name to run in the subshell used to run TeX.
See also `tex-shell-arg-list'."
  :type '(choice (const :tag "None" nil)
		 string)
  :group 'tex-run)

(defcustom tex-shell-arg-list nil
  "*Alist of options passed to subshell used to run TeX.
See also `tex-shell-file-name'."
  :type '(repeat :tag "Option list" string)
  :group 'tex-run)

(defun tex-start-shell ()
  (with-current-buffer
      (apply 'make-comint
       "tex-shell"
       (or tex-shell-file-name explicit-shell-file-name
	   (getenv "ESHELL") (getenv "SHELL") "/bin/sh")
       nil (or tex-shell-arg-list '("-i")))
    (let ((proc (get-process "tex-shell")))
      (set-process-sentinel proc 'tex-shell-sentinel)
      (process-kill-without-query proc)
      (tex-shell)
      (while (zerop (buffer-size))
	(sleep-for 1)))))

;;; My error parsing.

(defadvice tex-send-tex-command (after tex-plus-compilation activate)
  (when (tex-shell-running)
    (with-current-buffer (process-buffer (tex-shell-running))
    (setq compilation-parse-errors-function
	  'tex-plus-compilation-parse-errors)
    ;; Clean up.
    (let ((buffer-undo-list t)
	  (inhibit-read-only t)
	  deactivate-mark)
      ;; Remove the text-properties added by
      ;; tex-plus-compilation-parse-errors.
      (if compilation-old-error-list
	  (remove-text-properties (point-min) (point-max)
				  '(syntax-table nil)))))))

(defvar tex-plus-start-tex-marker nil
  "Marker pointing after last TeX-running command in the TeX shell buffer.")

(defcustom tex-plus-error-parse-level nil
  "*If non-nil, consider also over/underfull hbox messages as errors.
This enables you to jump to the corresponding source locations."
  :type 'boolean
  :group 'tex-run)

;;; Error Parsing
(easy-mmode-defsyntax
 tex-plus-error-parse-syntax-table
 '((?\{ . "_")
   (?\} . "_")
   (?\[ . "_")
   (?\] . "_")
   (?\" . "_"))
 "A syntax table used by `tex-plus-compilation-parse-errors'.

Only \"(\" and \")\" are seen by backward-list.")

(easy-mmode-defsyntax
 tex-plus-error-skip-syntax-table
 '((?\( . "_")
   (?\) . "_")
   (?\{ . "_")
   (?\} . "_")
   (?\[ . "_")
   (?\] . "_")
   (?\" . "_"))
 "A syntax table used by `tex-plus-compilation-parse-errors'.

No characters are seen by backward-list.")

(defun tex-plus-compilation-parse-errors (limit-search find-at-least)
  "Parse the current buffer as TeX error messages.
See the variable `compilation-parse-errors-function' for the interface it uses.

This function parses only the last TeX compilation.

A special parsing routine is necessary, since TeX does not put file
names and line numbers on the same line as for the error messages."
  (require 'thingatpt)
  (setq compilation-error-list nil)
  (message "Parsing error messages...")
  (let (;; First a kind of buffer-save-state.
	(buffer-undo-list t) (inhibit-read-only t) deactivate-mark

	;; Dir may have changed.
	(default-directory
	  (file-name-directory (buffer-file-name tex-last-buffer-texed)))

	;; We use syntax-table text-properties.
	(parse-sexp-lookup-properties t)

	;; To restore it later.
	(err-buf (current-buffer))

	;; We need a table with only "(" and ")" seen by backward-list.
;; 	(tex-plus-error-parse-syntax-table
;; 	 (let ((table (copy-syntax-table)))
;; 	   (modify-syntax-entry ?\{ "_" table)
;; 	   (modify-syntax-entry ?\} "_" table)
;; 	   (modify-syntax-entry ?\[ "_" table)
;; 	   (modify-syntax-entry ?\] "_" table)
;; 	   (modify-syntax-entry ?\" "_" table)
;; 	   table))

	;; We need a table with no characters seen by backward-list.
;; 	(tex-plus-error-skip-syntax-table
;; 	 (let ((table (copy-syntax-table)))
;; 	   (modify-syntax-entry ?\( "_" table)
;; 	   (modify-syntax-entry ?\) "_" table)
;; 	   (modify-syntax-entry ?\{ "_" table)
;; 	   (modify-syntax-entry ?\} "_" table)
;; 	   (modify-syntax-entry ?\[ "_" table)
;; 	   (modify-syntax-entry ?\] "_" table)
;; 	   (modify-syntax-entry ?\" "_" table)
;; 	   table))

	;; We freeze point-max here to care about a running tex
	;; process.
	(current-point-max (point-max)) output-finished

	;; The variables to play with.
	(num-errors-found 0) parsing-end
	last-error last-linenum
	error-msg error-type error-start error-end error-text
	linenum filename error-source)

    ;; Do we reparse or parse the first time?
    (when (eq (marker-position compilation-parsing-end) 1)
      ;; If `compilation-forget-errors' would run a hook, that should
      ;; go there.  What about a compilation-forget-errors-function?
      (if (and (markerp tex-plus-start-tex-marker)
	       (eq (current-buffer) (marker-buffer tex-plus-start-tex-marker)))
	  (set-marker compilation-parsing-end tex-plus-start-tex-marker))
      (remove-text-properties (point-min) (point-max) '(syntax-table nil)))
    (goto-char compilation-parsing-end)

    ;; Is the tex run finished?
    (save-excursion
      (if (setq output-finished
		(re-search-forward
		 "^Transcript written on " nil t))
	  ;;  Then limit the parse to its output.
	  (setq current-point-max output-finished)))

    ;; Parse messages.

    ;; To determine the error file we use backward-list with
    ;; syntax-table tex-plus-error-parse-syntax-table.  The messages may
    ;; contain characters "(" and ")" which irritate the scanning.
    ;; Therefore the messages receive the syntax-table text-property
    ;; tex-plus-error-skip-syntax-table.

    ;; There are basically two types of messages:  (I) true tex errors
    ;; and (II) messages about overfull hboxes and similar things.

    ;; If the user option `tex-plus-error-parse-level' is nil, type (II)
    ;; errors are neglected by default for
    ;; `compilation-error-list'. Otherwise they are treated in the
    ;; same way as type (I) errors.

    (catch 'parsing-end
      (while t

	(unless
	    (re-search-forward
	     ;; A regexp for all relevant messages.
	     ;; It is probably incomplete.
	     "^\\(! \\|\\(Over\\|Under\\)full \\\\.*lines? \\([0-9]+\\)\\)"
	     current-point-max t)
	  ;; No more messages: exit.
	  (setq parsing-end current-point-max)
	  (throw 'parsing-end nil))

	(goto-char (match-beginning 0))
	(setq error-msg (point-marker))
	(setq error-start error-msg)

	(cond
	 ((looking-at "^! Emergency stop\\.")
	  ;; A special case:  We are at the end.
	  (setq parsing-end current-point-max)
	  (throw 'parsing-end nil))
	 ((looking-at "^! ")
	  ;; It is a type (I) error.
	  (setq error-type t)
	  ;; In a "Runaway argument?", the error lines start before the
	  ;; error message "! Paragraph ended..."
	  (if (looking-at "^! Paragraph ended before .* was complete.$")
	      (save-excursion
		(forward-line -2)
		(if (looking-at "^Runaway argument\\?\n ")
		    (setq error-start (point-marker)))))
	  (unless (re-search-forward
		   "^l\\.\\([0-9]+\\) \\(\\.\\.\\.\\)?\\(.*\\)$"
		   current-point-max t)
	    ;; The output is not finished: forget this error and exit.
	    (setq parsing-end error-msg)
	    (throw 'parsing-end nil))
	  ;; Find the end of this error.
	  (goto-char (match-end 0))
	  (forward-line)
	  (end-of-line)
	  (setq error-end (point))
	  ;; Get line number and text for searching the source.
	  (setq linenum (string-to-int (match-string 1)))
	  (setq error-text (regexp-quote (match-string 3))))

	 ((looking-at "^\\(Over\\|Under\\)full \\\\.*lines? \\([0-9]*\\)")
	  ;; It is a type (II) error.
	  (setq error-type tex-plus-error-parse-level)
	  ;; Find the end of this error.  Code in parts stolen from
	  ;; TeX-warning in tex-buf.el from AUC TeX.
	  (forward-line)
	  (end-of-line)
	  (while (or (equal (current-column) 79)
		     (save-excursion
		       (forward-line)
		       (save-match-data
			 ;; perhaps incomplete or/and incorrect.
			 ;; Maybe just exclude all lines with a \
			 ;; (except for "^! " lines)?
			 (looking-at "\\( \\\\\\|.*\\[\\]\\)"))))
	    (forward-line)
	    (end-of-line))
	  (setq error-end (point))
	  (when (>= error-end current-point-max)
	    ;; Output of this error is probably not finished:
	    ;; forget this error and exit.
	    (setq parsing-end error-msg)
	    (throw 'parsing-end nil))
	  ;; Get the line number of the source.
	  (setq linenum (string-to-int (match-string 2)))
	  ;; Getting the error-text is too hard.
	  ;; It is anyway not interesting if `tex-plus-error-parse-level' is nil.
	  (setq error-text nil)))

	;; Put appropriate syntax around the message.
	(add-text-properties
	 error-start error-end
	 (list 'syntax-table tex-plus-error-skip-syntax-table))

	(when error-type
	  ;; Search for and in the source.
	  (goto-char error-start)
	  (save-excursion
	    (with-syntax-table tex-plus-error-parse-syntax-table
	      (if (or (null last-error)
		      (save-restriction
			  (narrow-to-region (car last-error) (point))
			  (condition-case ()
			      (while (not (bobp)) (backward-list 1))
			    (error t))))
		    ;; Have to scan for the file.
		    (progn
		      (backward-up-list 1)
		      (skip-syntax-forward "(_")
		      (setq filename (thing-at-point 'filename))
		      (if (or (= 0 (length filename))
			      (not (file-exists-p filename)))
			  ;; We failed, but continue the parse.
			  ;; Here we could also give up with (error ...)
			  (message "Couldn't guess source file for error %s"
				   error-msg))
		      (if (equal filename (concat tex-zap-file ".tex"))
			  (set-buffer tex-last-buffer-texed)
			(set-buffer (find-file-noselect filename)))
		      (save-restriction
			(widen)
			(goto-line linenum)
			(or (null error-text)
			    (re-search-forward error-text nil t)
			    (re-search-backward error-text nil t))
			(setq error-source (point-marker))))
		  ;; No new file.
		  (set-buffer (marker-buffer (cdr last-error)))
		  (goto-char (cdr last-error))
		  (forward-line (- linenum last-linenum))
		  ;; First try a forward search for the error text,
		  ;; then a backward search limited by the last error
		  ;; in this file, if it exists.
		  (or (null error-text)
		      (re-search-forward error-text nil t)
		      (re-search-backward error-text (cdr last-error) t))
		  (setq error-source (point-marker)))
		(set-buffer err-buf)))

	  ;; Have we found more than enough errors?  Yes, if we are
	  ;; beyond the requirements, if there is a previous error,
	  ;; and if the following is true:  The error is in a new file
	  ;; or we have parsed already 50 errors.

	  ;; The limit 50 is a heuristic.  It avoids a long parse if
	  ;; something really bad happened with the tex run and one
	  ;; just wants to jump to the first few errors.

	  ;; Such a break should be allowed by compilation-mode:  An
	  ;; equivalent break happens once in a while when the grep
	  ;; process is running while parsing.

	  (when (and
		 (if limit-search
		     (>= error-msg limit-search) t)
		 (if find-at-least
		     (>= num-errors-found find-at-least) t)
		 compilation-error-list
		 (or (not (eq (marker-buffer error-source)
			      (marker-buffer (cdr last-error))))
		     (>= num-errors-found 50)))
	    ;; We forget this error and exit.
	    (setq parsing-end error-msg)
	    (throw 'parsing-end nil))

	  ;; Put it on the list and prepare for the next error.
	  (setq last-error (cons error-msg error-source)
		compilation-error-list (nconc compilation-error-list
					      (list last-error))
		num-errors-found (1+ num-errors-found)
		last-linenum linenum
		parsing-end error-end)

	  (if (>= num-errors-found 10)
	      (message "Parsing error messages...[%s]"
		       (+ num-errors-found
			  (length compilation-old-error-list)))))

	;; Go to the end of message and continue the loop.
	(goto-char error-end)))

    ;; Set `compilation-parsing-end' only here, in case of an error
    ;; while parsing.
    (if (and output-finished (eq parsing-end current-point-max))
	;; All errors are parsed.  Put compilation-parsing-end at the
	;; very end of buffer, moving with insertions.  This avoids
	;; unnecessary reparsing in some situations.
	(progn (set-marker compilation-parsing-end (point-max-marker))
	       (set-marker-insertion-type compilation-parsing-end t))
      (set-marker compilation-parsing-end parsing-end)))

  (message "Parsing error messages...done"))

(provide 'tex-plus)
============================================================

Re: compilation-forget-errors still used by tex-mode.el

[Daniel Pfeiffer]

Saluton, Moin,

Markus Rost <rost@mathematik.uni-bielefeld.de> skribis:

> As for ideas:  What about having for tex compilation parses an option
> like
> 
> (defcustom tex-plus-error-parse-level nil
>   "*If non-nil, consider also over/underfull hbox messages as errors.
> This enables you to jump to the corresponding source locations."

What happens if you call TeX with -file-line-error-style in normal M-x
compile?  Is this something that would come up as a warning?

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / läramå / ucz się    Esperanto:
                              http://lernu.net/

Re: compilation-forget-errors still used by tex-mode.el

[Markus Rost]

> What happens if you call TeX with -file-line-error-style in normal M-x
> compile?

"Overfull \hbox" messages as printed usual, like

Overfull \hbox (225.80205pt too wide) in paragraph at lines 3--4

Anyway, "Overfull \hbox" messages are easy to parse, since they are
printed in one line with a simple format.

Re: compilation-forget-errors still used by tex-mode.el

[Daniel Pfeiffer]

Saluton,

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

> >> We should maybe just introduce a new `compilation-current-error' marker
> 
> > And add compilation-current-error to overlay-arrow-variable-list :-)
> 
> Now there's an idea.

overlay-arrow-variable-list seems to be a very embryonic feature.  While you
can put more than one variable into it, only the first occurence in the buffer
actually gets a little arrow in the fringe.  And even though there is a string
to
use instead on non-window frames, the feature is not even present on a
text-terminal.  And it only works at BOL, whereas error-messages are now
recognized anywhere on a line, even one behind another.

So I'll have to use my own overlay.  I'm wondering if flashing this for half a
second, like the jumped to position, is useful.  While that is more of a toy,
since the cursor lands there anyways, highlighting the message seems to be an
essential feature for some people.  If you get distracted after Cx- ` you can
easily miss this within half a second — especially if it takes a second to
fetch a remote file first.

Maybe I should combine half a second with a pre command hook?  Or leave it
until another message gets located?

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / läramå / ucz się    Esperanto:
                              http://lernu.net/

Re: compilation-forget-errors still used by tex-mode.el

[Kim F. Storm]

dapfy@t-online.de (Daniel Pfeiffer) writes:

> Saluton,
> 
> Stefan Monnier <monnier@iro.umontreal.ca> skribis:
> 
> > >> We should maybe just introduce a new `compilation-current-error' marker
> > 
> > > And add compilation-current-error to overlay-arrow-variable-list :-)
> > 
> > Now there's an idea.
> 
> overlay-arrow-variable-list seems to be a very embryonic feature.  While you
> can put more than one variable into it, only the first occurence in the buffer
> actually gets a little arrow in the fringe.  

In a compile buffer, I would think that one current error marker is enough.
Why do you need more than that?!

>                                              And even though there is a string
> to
> use instead on non-window frames, the feature is not even present on a
> text-terminal.  

It is supposed to work, so if not, that's a bug.

>                 And it only works at BOL, whereas error-messages are now
> recognized anywhere on a line, even one behind another.

Yes, ok, but you can still use it to point out the line as such.

> 
> So I'll have to use my own overlay.  I'm wondering if flashing this for half a
> second, like the jumped to position, is useful.  While that is more of a toy,
> since the cursor lands there anyways, highlighting the message seems to be an
> essential feature for some people.  If you get distracted after Cx- ` you can
> easily miss this within half a second — especially if it takes a second to
> fetch a remote file first.

If you decide to use your own overlay, I suggest that you keep the highlight
on the error message.  I don't see a need to just highlight it briefly.

In any case, the highlight will disappear when you have reached past
the last error.

> 
> Maybe I should combine half a second with a pre command hook?  Or leave it
> until another message gets located?

Leave it.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: compilation-forget-errors still used by tex-mode.el

[monnier]

> text-terminal.  And it only works at BOL, whereas error-messages are now
> recognized anywhere on a line, even one behind another.

Big deal.  All people complained about is that the error-line is not
clearly indicated now that we keep 2-lines of context because there is
nothing more than the cursor (which is going to be hollow or maybe even
completely absent) to tell you what line to look at.
So adding an arrow will address this issue just fine, methinks.

> So I'll have to use my own overlay.

I guess I can't stop you, but it doesn't seem necessary for now.


        Stefan

Re: compilation-forget-errors still used by tex-mode.el

[Daniel Pfeiffer]

Saluton,

monnier <monnier@iro.umontreal.ca> skribis:

> > text-terminal.  And it only works at BOL, whereas error-messages are now
> > recognized anywhere on a line, even one behind another.
>
> Big deal.  All people complained about is that the error-line is not
> clearly indicated now that we keep 2-lines of context because there is
> nothing more than the cursor (which is going to be hollow or maybe even
> completely absent) to tell you what line to look at.
> So adding an arrow will address this issue just fine, methinks.
>
> > So I'll have to use my own overlay.
>
> I guess I can't stop you, but it doesn't seem necessary for now.

Well, overlay-arrow-variable-list is apparently intended to be extended.  If
various commands add their own arrow-wish to this, and only the first gets
displayed, it can still be that compile's arrow doesn't appear.

And as long as this is not available on text displays it's not so good.  I was
mistaken however because I'd used the 6 months old standard emacs there.  The
only thing missing is assigning something like "-->" to overlay-arrow-string,
maybe with some face applied.

Otoh, it would be the quickest patch to make...  Since there can be only one
arrow anyway, I wouldn't worry about a new variable, simply assign something
to overlay-arrow-position.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / läramå / ucz się    Esperanto:
                              http://lernu.net/

Re: compilation-forget-errors still used by tex-mode.el

[Kim F. Storm]

dapfy@t-online.de (Daniel Pfeiffer) writes:

> Well, overlay-arrow-variable-list is apparently intended to be extended.  If
> various commands add their own arrow-wish to this, and only the first gets
> displayed, it can still be that compile's arrow doesn't appear.

My vision with overlay-arrow-variable-list was that each mode (gdb,
compile, grep, ...) would need just one arrow each, and in their "own"
buffer.  So, IMO, it doesn't really make sense to have more than one
arrow in each window.

> 
> And as long as this is not available on text displays it's not so good.  I was
> mistaken however because I'd used the 6 months old standard emacs there.  

So does it work, or not?

>                                                                           The
> only thing missing is assigning something like "-->" to overlay-arrow-string,
> maybe with some face applied.

You can assign a separate overlay arrow string to your own variable via the
overlay-arrow-string property on that variable.

> 
> Otoh, it would be the quickest patch to make...  Since there can be only one
> arrow anyway, I wouldn't worry about a new variable, simply assign something
> to overlay-arrow-position.

You should definitely make a separate variable for compile, as the
"standard" arrow is reserved for gdb.  I can easily envision running
compile and gdb simultaneously.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: compilation-forget-errors still used by tex-mode.el

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> You should definitely make a separate variable for compile, as the
> "standard" arrow is reserved for gdb.  I can easily envision running
> compile and gdb simultaneously.

Yeah, but I thought the arrow in question was in the *compilation*
buffer; why would gdb want a pointer in there?!?

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: compilation-forget-errors still used by tex-mode.el

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> storm@cua.dk (Kim F. Storm) writes:
> > You should definitely make a separate variable for compile, as the
> > "standard" arrow is reserved for gdb.  I can easily envision running
> > compile and gdb simultaneously.
> 
> Yeah, but I thought the arrow in question was in the *compilation*
> buffer; why would gdb want a pointer in there?!?

The overlay-arrow variables are global (although some modes use them
as buffer-local, but redisplay isn't really prepared for that).

So you have one variable for gdb (the default one), and define another
for compile.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: compilation-forget-errors still used by tex-mode.el

[Daniel Pfeiffer]

Saluton,

storm@cua.dk (Kim F. Storm) skribis:

> Miles Bader <miles@lsi.nec.co.jp> writes:
> 
> > storm@cua.dk (Kim F. Storm) writes:
> > And as long as this is not available on text displays it's not so good.  I
> > was mistaken however because I'd used the 6 months old standard emacs
> > there.  
> 
> So does it work, or not?

Well, not by default, only if you configure a string.  Which for the normal
user would mean: no.

> > > You should definitely make a separate variable for compile, as the
> > > "standard" arrow is reserved for gdb.  I can easily envision running
> > > compile and gdb simultaneously.
> > 
> > Yeah, but I thought the arrow in question was in the *compilation*
> > buffer; why would gdb want a pointer in there?!?
> 
> The overlay-arrow variables are global (although some modes use them
> as buffer-local, but redisplay isn't really prepared for that).

I see no problem at first sight.  I have even mixed global and local, and they
both scroll in and out of view fine.

> So you have one variable for gdb (the default one), and define another
> for compile.

If it's gdb's personal one, the list should initially be empty.  Gdb should
add one with a name indicating ownership like gdb-overlay-arrow, when it gets
called.

Otoh compile's doc has long stated:

To run more than one compilation at once, start one and rename
the \`*compilation*' buffer to some other name with
\\[rename-buffer].

So, whichever var I use, it would have to be buffer local anyways.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / läramå / ucz się    Esperanto:
                              http://lernu.net/

Re: compilation-forget-errors still used by tex-mode.el

[Stefan Monnier]

> The overlay-arrow variables are global (although some modes use them
> as buffer-local, but redisplay isn't really prepared for that).

If the redisplay only ever supports one arrow per buffer, then it would
make more sense to use a single hard-coded variable and make sure that
buffer-local values are handled correctly.

It seems that the current interface is overly general w.r.t
the implementation.


        Stefan

Re: compilation-forget-errors still used by tex-mode.el

[Kim F. Storm]

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

> > The overlay-arrow variables are global (although some modes use them
> > as buffer-local, but redisplay isn't really prepared for that).
> 
> If the redisplay only ever supports one arrow per buffer, then it would
> make more sense to use a single hard-coded variable and make sure that
> buffer-local values are handled correctly.

But for some uses (like gdb), the overlay arrow isn't tied to a single
buffer.  Making it buffer local would mean we would have to keep track
of where we put that arrow by other means, so we can remove it when
moving to a different buffer.

Supporting buffer local overlay arrows works for the most part, but
the handling of overlay arrows used to rely on global state variables;
with my latest changes, those global state variables are now
implemented as properties on each overlay arrow variable, so you can
safely have more than one arrow.

IIRC, the limitation of one overlay arrow in each buffer could easily
be lifted...  Well, I can look into that.

> 
> It seems that the current interface is overly general w.r.t
> the implementation.

Can something be too general -- if it is also simple...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk