* "Recent" changes to compilation-mode? @ 2005-05-22 11:37 David Abrahams 2005-05-22 21:44 ` Nick Roberts [not found] ` <E1DcDnj-0000PS-Ml@fencepost.gnu.org> 0 siblings, 2 replies; 8+ messages in thread From: David Abrahams @ 2005-05-22 11:37 UTC (permalink / raw) Sometime in the past year or so compilation-mode started acting very strangely for me with a CVS-built emacs. First, if I use next-error while compilation is still going on, I will often, after a moment or two, see the point jump unpredictably in the file it takes me to. Second, next-error used to cause the error in question to scroll to the top of the *compilation* buffer's window, which made it very easy to see what was going on. Now emacs just moves that buffer's point without scrolling. Since the active point ends up in the source file's buffer where the error is, all I see change in the *compilation* buffer is that an unfilled rectangle with super-thin borders moves. It's extremely hard to see; if the window isn't going to scroll, IMO something else needs to be done (e.g. with highlighting) to emphasize the error in question. Finally, many of my carefully-constructed error regexps seem no longer to be recognized. I had been doing: (require 'compile) (setq compilation-error-regexp-alist (append '(...regexps...) compilation-error-regexp-alist)) (if (fboundp 'compilation-file-regexp-alist) ; in case of XEmacs, ; which doesn't support ; 'compilation-file-regexp-alist (setq compilation-file-regexp-alist (append '(... regexps ...) compilation-file-regexp-alist))) I note that now there appears to be a two-layer scheme with compilation-error-regexp-alist-alist that renders my old settings invalid. I can adjust what I'm doing, but discovering what to do was a struggle. Is there a way to provide a better transition experience for people who upgrade? -- Dave Abrahams Boost Consulting www.boost-consulting.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* "Recent" changes to compilation-mode? 2005-05-22 11:37 "Recent" changes to compilation-mode? David Abrahams @ 2005-05-22 21:44 ` Nick Roberts 2005-05-23 13:25 ` David Abrahams [not found] ` <E1DcDnj-0000PS-Ml@fencepost.gnu.org> 1 sibling, 1 reply; 8+ messages in thread From: Nick Roberts @ 2005-05-22 21:44 UTC (permalink / raw) Cc: emacs-devel > Second, next-error used to cause the error in question to scroll to > the top of the *compilation* buffer's window, which made it very easy > to see what was going on. Now emacs just moves that buffer's point > without scrolling. Since the active point ends up in the source > file's buffer where the error is, all I see change in the > *compilation* buffer is that an unfilled rectangle with super-thin > borders moves. It's extremely hard to see; if the window isn't going > to scroll, IMO something else needs to be done (e.g. with > highlighting) to emphasize the error in question. When there is a fringe present, the default was changed to not scroll because the arrow points to the current error and errors immediately above the current one remain visible. When there is no fringe, the current error scrolls to the top of the *compilation* buffer's window. So you should either see an arrow or scrolling. If you don't, you need to give your configuration. M-x report-emacs-bug, also on the menu bar plus the value of fringe-mode and/or window-fringes is a good start. Nick P.S To always scroll to the top: (setq compilation-context-lines 0) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "Recent" changes to compilation-mode? 2005-05-22 21:44 ` Nick Roberts @ 2005-05-23 13:25 ` David Abrahams 2005-05-25 16:55 ` Juri Linkov 0 siblings, 1 reply; 8+ messages in thread From: David Abrahams @ 2005-05-23 13:25 UTC (permalink / raw) Cc: emacs-devel Nick Roberts <nickrob@snap.net.nz> writes: > > Second, next-error used to cause the error in question to scroll to > > the top of the *compilation* buffer's window, which made it very easy > > to see what was going on. Now emacs just moves that buffer's point > > without scrolling. Since the active point ends up in the source > > file's buffer where the error is, all I see change in the > > *compilation* buffer is that an unfilled rectangle with super-thin > > borders moves. It's extremely hard to see; if the window isn't going > > to scroll, IMO something else needs to be done (e.g. with > > highlighting) to emphasize the error in question. > > > When there is a fringe present, the default was changed to not scroll > because the arrow points to the current error and errors immediately > above the current one remain visible. > > When there is no fringe, the current error scrolls to the top of the > *compilation* buffer's window. > > So you should either see an arrow or scrolling. If you don't, you need > to give your configuration. M-x report-emacs-bug, also on the menu bar > plus the value of fringe-mode and/or window-fringes is a good start. Yeah, there's a tiny arrow there. The problem is that the diagnostics typically span several lines and are often quite dense, and the arrow isn't quite enough to help me distinguish the boundaries of the diagnostic being indicated by the arrow. Would it be possible to add some kind of highlighting to the current error, similar to what I get when hovering the mouse over it? > P.S To always scroll to the top: (setq compilation-context-lines 0) Ah, that will be a big help, thanks. Not quite as good as highlighting, but not bad. -- Dave Abrahams Boost Consulting www.boost-consulting.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "Recent" changes to compilation-mode? 2005-05-23 13:25 ` David Abrahams @ 2005-05-25 16:55 ` Juri Linkov 0 siblings, 0 replies; 8+ messages in thread From: Juri Linkov @ 2005-05-25 16:55 UTC (permalink / raw) Cc: nickrob, emacs-devel > Yeah, there's a tiny arrow there. The problem is that the diagnostics > typically span several lines and are often quite dense, and the arrow > isn't quite enough to help me distinguish the boundaries of the > diagnostic being indicated by the arrow. Would it be possible to add > some kind of highlighting to the current error, similar to what I get > when hovering the mouse over it? Recently I proposed a patch that does exactly what you want, i.e. highlights the whole current error message with a special user option. You can get the patch here: http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg00561.html This patch is too good for the coming release. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <E1DcDnj-0000PS-Ml@fencepost.gnu.org>]
* Re: "Recent" changes to compilation-mode? [not found] ` <E1DcDnj-0000PS-Ml@fencepost.gnu.org> @ 2005-06-01 16:54 ` David Abrahams 2005-06-03 8:02 ` Richard Stallman [not found] ` <uhdgi10hu.fsf@boost-consulting.com> 1 sibling, 1 reply; 8+ messages in thread From: David Abrahams @ 2005-06-01 16:54 UTC (permalink / raw) Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 77 bytes --] RMS: sorry for the duplicate; I had forgotten to send to the list as well. [-- Attachment #2.1: Type: text/plain, Size: 4605 bytes --] Richard Stallman <rms@gnu.org> writes: > Sometime in the past year or so compilation-mode started acting very > strangely for me with a CVS-built emacs. First, if I use next-error > while compilation is still going on, I will often, after a moment or > two, see the point jump unpredictably in the file it takes me to. > > Have you figured out any more about this? Well, I haven't figured out much new, but it still happens. I haven't rebuilt Emacs since I first reported the problem, of course. Here's some more detail. I have a compilation that produces the enclosed errors. It's recompiling the same file and issuing errors twice for it in this case because it's a bootstrap process, but I'm positive that I've seen the behavior when errors only appear once. If I hit `f4' (bound to compilation-next-error for me) once, it goes to the first error in the indicated source window. Then when the 2nd batch of errors show up in the compilation window, the point in the open source window moves to the very last error in that window, without any help from me. The point in the *compilation* buffer remains where it was. If I repeat the above process, but issue a build command that repeats 6 times, and then I hit `f4' *again* during compilation, the point moves to the 2nd error in the source window and then after only a very brief pause, jumps to the final error. I haven't yet adjusted my compilation-error-regexp-alists to the new scheme, so it's possible that has somethign to do with it. > I note that now there appears to be a two-layer scheme with > compilation-error-regexp-alist-alist that renders my old settings > invalid. I can adjust what I'm doing, but discovering what to do was > a struggle. Is there a way to provide a better transition experience > for people who upgrade? > > Can you tell us any more about where the difficulty was? Well, my usual experience of being able to browse compilation errors just stopped working, and I had to dig through the docs for compilation-next-error to find out that the whole world was different. It would have been nicer if the system had detected that I was using the old variables and given me a warning about the change and pointed me at the new docs, or better yet had done the translation automatically for me. It would also have been nicer if the new docs included a transition guide. Here's what my current (old) .emacs says about this stuff: ;; ;; Customize regular expressions which match compilation error messages ;; ;; Make sure we have a definition of compilation-error-regexp-alist before ;; modifying it (require 'compile) (setq compilation-error-regexp-alist (append '( ("\\s-*#\\s-*line\\s-+\\([0-9]+\\)\\s-+\"\\([a-zA-Z]?:?[^\":\n]+\\)\"" 2 1) ;; This expression can be used to match error messages from Jam ("\"?\\([a-zA-Z]?:?[^\":\n]+\\)\"?:[ ]+[Ll]ine[ ]+\\([0-9]+\\)" 1 2) ;; matches some gcc error output ("\\(\\( \\)\\|\\(In file included \\)\\)from \"?\\([a-zA-Z]?:?[^\":\n]+\\)\"?:\\([0-9]+\\)" 4 5) ;; matches some vc7 error output (" +\\(\\([a-zA-Z]:\\)?[^:( \n]+\\)(\\([0-9]+\\)):.*'.*" 1 3) ;; This expression matches metrowerks command-line tool output. We just ;; pick up the line number, since the file name is handled below ("\\(### mw[^\n]+\n\\)?# +\\([0-9]+\\):" nil 2) (" \\(\\([a-zA-Z]:\\)?[^:(\t\n]+\\)(\\([0-9]+\\)) \ : see " 1 3) (".*at\\s-+[Ll]ine\\s-+\\([0-9]+\\)\\s-+of\\s-+\"\\([a-zA-Z]?:?[^\":\n]+\\)\"" 2 1) ; Python backtraces include these ("^[ \t]*File \"\\([a-zA-Z]?:?[^\":\n]+\\)\",[ \t]+[Ll]ine[ \t]+\\([0-9]+\\).*" 1 2) ;; These are "helpfully" supplied when Boost.Build testing prints a backtrace ("^[ \t]*\\(at\\|from\\)[ \t]+line[ \t]+\\([0-9]+\\)[ \t]+of[ \t]+\"?\\([a-zA-Z]?:?[^\":\n(]+\\).*" 3 2) ) compilation-error-regexp-alist)) (if (boundp 'compilation-file-regexp-alist) (setq compilation-file-regexp-alist (append '( ;; This expression matches metrowerks command-line tool output, which ;; only displays the filename once for multiple errors ("### mw[^\n]+\n# *In: \"?\\([a-zA-Z]?:?[^\":\n]+\\)\"?$" 1) ("### mw[^\n]+\n# *File: \"?\\([a-zA-Z]?:?[^\":\n]+\\)\"?$" 1) ("^(\\(.*\.tex\\)\\|\\(.*tex\.cfg\\)\nLaTeX2e" 1) ) compilation-file-regexp-alist))) [-- Attachment #2.2: error.log --] [-- Type: text/plain, Size: 2984 bytes --] -*- mode: compilation; default-directory: "c:/boost/tools/build/jam_src/" -*- build Setting environment for using Microsoft Visual Studio .NET 2003 tools. (If you have another version of Visual Studio or Visual C++ installed and wish to use its tools from the command line, run vcvars32.bat for that version.) ### ### Using 'vc7' toolset. ### c:\boost\tools\build\jam_src>rd /S /Q bootstrap c:\boost\tools\build\jam_src>md bootstrap c:\boost\tools\build\jam_src>cl /nologo /GZ /Zi /MLd -DNT -DYYDEBUG kernel32.lib advapi32.lib /Febootstrap\jam0 command.c compile.c execnt.c execunix.c execvms.c expand.c filent.c fileos2.c fileunix.c filevms.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c w32_getreg.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c command.c compile.c execnt.c execnt.c(160) : warning C4090: 'function' : different 'const' qualifiers execnt.c(171) : warning C4090: '=' : different 'const' qualifiers execnt.c(181) : warning C4090: '=' : different 'const' qualifiers execunix.c execvms.c expand.c filent.c fileos2.c fileunix.c filevms.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c Generating Code... Compiling... newstr.c option.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c w32_getreg.c native.c Generating Code... Compiling... set.c path.c regex.c property-set.c sequence.c order.c Generating Code... c:\boost\tools\build\jam_src>.\bootstrap\jam0 -f build.jam --toolset=vc7 "--toolset-root=C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\\..\..\VC7\ " clean ...found 1 target... ...updating 1 target... [DELETE] clean ...updated 1 target... c:\boost\tools\build\jam_src>.\bootstrap\jam0 -f build.jam --toolset=vc7 "--toolset-root=C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\\..\..\VC7\ " ...found 44 targets... ...updating 1 target... [COMPILE] bin.ntx86\bjam.exe command.c compile.c expand.c glob.c hash.c hcache.c headers.c hdrmacro.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c regexp.c rules.c scan.c Generating Code... Compiling... search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c set.c path.c regex.c property-set.c sequence.c order.c execnt.c execnt.c(160) : warning C4090: 'function' : different 'const' qualifiers execnt.c(171) : warning C4090: '=' : different 'const' qualifiers execnt.c(181) : warning C4090: '=' : different 'const' qualifiers filent.c pathunix.c Generating Code... Compiling... w32_getreg.c Generating Code... ...updated 1 target... Compilation finished at Wed Jun 01 12:47:44 [-- Attachment #2.3: Type: text/plain, Size: 61 bytes --] -- Dave Abrahams Boost Consulting www.boost-consulting.com [-- Attachment #3: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "Recent" changes to compilation-mode? 2005-06-01 16:54 ` David Abrahams @ 2005-06-03 8:02 ` Richard Stallman 0 siblings, 0 replies; 8+ messages in thread From: Richard Stallman @ 2005-06-03 8:02 UTC (permalink / raw) Cc: emacs-devel Well, my usual experience of being able to browse compilation errors just stopped working, and I had to dig through the docs for compilation-next-error to find out that the whole world was different. It would have been nicer if the system had detected that I was using the old variables and given me a warning about the change and pointed me at the new docs, or better yet had done the translation automatically for me. I agree that something like this would be good. I think something like this could be implemented as a superficial change that would not alter the existing code, and thus would be safe. Unfortunately I don't have time to do it myself. Could someone please study this and implement such a transition aid? ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <uhdgi10hu.fsf@boost-consulting.com>]
[parent not found: <E1DdjNA-0005OT-Sv@fencepost.gnu.org>]
* Re: "Recent" changes to compilation-mode? [not found] ` <E1DdjNA-0005OT-Sv@fencepost.gnu.org> @ 2005-06-02 12:15 ` David Abrahams 2005-06-03 10:33 ` Richard Stallman 0 siblings, 1 reply; 8+ messages in thread From: David Abrahams @ 2005-06-02 12:15 UTC (permalink / raw) Richard Stallman <rms@gnu.org> writes: > If I repeat the above process, but issue a build command that repeats > 6 times, and then I hit `f4' *again* during compilation, the point > moves to the 2nd error in the source window and then after only a very > brief pause, jumps to the final error. > > Is this result repeatable? Yes. > If so, it should be possible to narrow down > what code is doing this, just by inserting statements like > > (push (list 'place-5 (window-start)) debug-list) > > in various places. (Set debug-list to nil first.) Sorry, you're well beyond the scope of my understanding of how to debug emacs. I'm happy to try whatever you like, but I think I need some more guidance, e.g. a. Some examples of those various places b. How to see the results of my changes c. How to understand those results -- Dave Abrahams Boost Consulting www.boost-consulting.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "Recent" changes to compilation-mode? 2005-06-02 12:15 ` David Abrahams @ 2005-06-03 10:33 ` Richard Stallman 0 siblings, 0 replies; 8+ messages in thread From: Richard Stallman @ 2005-06-03 10:33 UTC (permalink / raw) Cc: emacs-devel > (push (list 'place-5 (window-start)) debug-list) > > in various places. (Set debug-list to nil first.) Sorry, you're well beyond the scope of my understanding of how to debug emacs. I'm happy to try whatever you like, but I think I need some more guidance, e.g. I am too overloaded to do this job just now. Can someone else please give David this help? ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2005-06-03 10:33 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-05-22 11:37 "Recent" changes to compilation-mode? David Abrahams 2005-05-22 21:44 ` Nick Roberts 2005-05-23 13:25 ` David Abrahams 2005-05-25 16:55 ` Juri Linkov [not found] ` <E1DcDnj-0000PS-Ml@fencepost.gnu.org> 2005-06-01 16:54 ` David Abrahams 2005-06-03 8:02 ` Richard Stallman [not found] ` <uhdgi10hu.fsf@boost-consulting.com> [not found] ` <E1DdjNA-0005OT-Sv@fencepost.gnu.org> 2005-06-02 12:15 ` David Abrahams 2005-06-03 10:33 ` Richard Stallman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.