Re: [ESS] [OT] Enabled a hook and no longer find which
On Mon, 2 Aug 2021 17:35:09 -0500 Dirk Eddelbuettel via ESS-help wrote: > On 2 August 2021 at 17:20, Dirk Eddelbuettel via ESS-help wrote: > | > | On 2 August 2021 at 23:56, Stephen Berman wrote: > | | Did you also try the more direct alternative of grepping simply for > | | "GPATH", "GTAGS", "GRTAGS"? Presumably whatever function updates these > | | files has to refer to them, either directly by name or indirectly by a > | | variable or function that in turn refers to them directly or indirectly. > | | So it should be possible to find the update function by inspecting all > | | code that uses these file names (directly or indirectly). > | > | They are only written by a tool named gtags which is a binary that comes > with > | GNU global. I even tried to be craft and 'shadow' /usr/bin/gtags with a > | (name-name) shell script leaving a timestamp in /tmp before calling > | /usr/bin/gtags but that left no traces either. > | > | But in one of the instrumented repos, as soon as I updated files src/ the > | files GTAGS and GRTAGS. It works so magically I feel tempted to use the > | trick for other purposes but I no longer know the trick . > > Sorry, missed one part of your question here: so yes, no trace of either > gtags or GPATH or GTAGS or GRTAGS in any of the few .el files in my ~ (and as > an elisp noob I would not write anywhere else). So still a puzzle. Maybe you could use gdb with a breakpoint on a suitable function (or just main()) in gtags.c (assuming you have the source) and try stepping through the call chain. Steve Berman __ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help
Re: [ESS] [OT] Enabled a hook and no longer find which
On Fri, 30 Jul 2021 12:56:11 -0500 Dirk Eddelbuettel via ESS-help wrote: > tl;dr: I enabled an action 'on save' and I no longer find where :-/ > > > Longer story: I settled upon GNU global and ggtags at some point for a > (mostly multilingual) system of tags in R and C++ (and some more). So a few > of source directories have these (ugly names) files GPATH, GTAGS, GRTAGS. > And at one point I became too clever by half and somehow enabled updating of > these files for at least some repos. But I no longer remember _how_ I did > that and can, for the life of me, find any trace in my .emacs (and, older > story, .elisp/*el) file(s). [...] On Fri, 30 Jul 2021 21:39:00 -0500 Dirk Eddelbuettel via ESS-help wrote: > On 30 July 2021 at 17:27, Tyler Smith via ESS-help wrote: > | Maybe check the values of before-save-hook and after-save-hook while > | visiting one of the files this problem applies to? You might find a function > | name you can grep for in your config. > > Yes hooks had come to mind and I tried 'C-h v' and 'C-h f' for a few > variables and functions. Still no smoking gun. Did you also try the more direct alternative of grepping simply for "GPATH", "GTAGS", "GRTAGS"? Presumably whatever function updates these files has to refer to them, either directly by name or indirectly by a variable or function that in turn refers to them directly or indirectly. So it should be possible to find the update function by inspecting all code that uses these file names (directly or indirectly). Steve Berman __ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help
[ESS] Broken parsing from compilation output in inferior-ess-r-mode
I have (define-key inferior-ess-r-mode-map "_" #'ess-insert-assign) in my init file. After installing R on a new system and starting ESS (built from the Github repo at commit e21ce9b260ff2ae0f162624ae3888c60bca3ae55) I called install.packages() and after that, typing `_' only inserted that character instead of `<-'. I tracked the problem down to certain lines of the compilation output from the install.packages() invocation. In particular, this line from the compilation output of nlopt: sed 's/\"/\\"/g' ./nlopt_optimize.m | sed 's,^% ,\",;s,^%,\",;s,$,\\n\" \\,' >> nlopt_optimize_usage.h With point at the third to last `"' in this line, (nth 3 (syntax-ppss (point))) returns nil, but with point at any later position in the buffer (nth 3 (syntax-ppss (point))) returns 34. If I insert `"' at the end of the above line, that corrects the subsequent buffer parsing, until the following line later in the output of nlopt: - have your system administrator add LIBDIR to `/etc/ld.so.conf' With point at ``' (nth 3 (syntax-ppss (point))) returns nil, but with point at any later position (until the end of the buffer) (nth 3 (syntax-ppss (point))) returns 96. If I insert ``' at the end of the above line (after `''), this again corrects the buffer parsing, now for the rest of the buffer. I can reproduce these observations in inferior-ess-r-mode in a fresh R session without actual compilation output from install.packages() simply by inserting the above lines into the buffer. However, in a buffer in ess-r-mode inserting the above sed line does not corrupt the parsing but inserting the second line does. Can anyone here replicate this? I'm not sure if this is a bug in ESS or in Emacs (perhaps in comint-mode, the grandparent of inferior-ess-r-mode, or in prog-mode, the grandparent of ess-r-mode). Any ideas? Steve Berman __ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help
Re: [ESS] unexpected behavior for Emacs-27.1-1-modified-1 for two MacBooks.
On Tue, 26 Jan 2021 18:59:27 -0600 Dirk Eddelbuettel via ESS-help wrote: > On 26 January 2021 at 22:07, Stephen Berman via ESS-help wrote: > | > I. Both machines report in *Messages* > | >Package cl is deprecated > | > | The NEWS file in Emacs 27 says: > | > | ** The 'cl' package is now officially deprecated in favor of 'cl-lib'. > > I know. What I do not know is which of the packages I load tickles this. The message is triggered when the sexp `(require 'cl)' is evaluated, so searching for that sexp should find the culpable packages. (If it doesn't, you could try searching for `(load "cl.el")', which also triggers the message, but that's much less common than the `require' sexp.) Steve Berman __ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help
Re: [ESS] unexpected behavior for Emacs-27.1-1-modified-1 for two MacBooks.
On Tue, 26 Jan 2021 18:49:57 + "Richard M. Heiberger via ESS-help"
wrote:
> I just downloaded Emacs-27.1-1-modified-1 for two MacBooks.
> I have been using the previous 25.1.1 successfully on both machines.
> 1. My new MacBook Air M1, running Big Sur
> 2. My old MacBook Air mid 2012, running Catalina (it is too old for Big Sur)
>
> I have three unexpected behaviors, and they are not identical on the two
> machines.
> Has anyone seen these before? Do you have idea about what is happening?
>
> Thank you,
> Rich
>
>
> I. Both machines report in *Messages*
>Package cl is deprecated
The NEWS file in Emacs 27 says:
** The 'cl' package is now officially deprecated in favor of 'cl-lib'.
> II. When I search find-dired in
> /Applications.Emacs.app/Contents/Resources/site-lisp with the command
> I have been using for many years
> -name \*.el -exec grep 'cl-' {} ";"
> new machine:
> searches normally with instances found in each followed by the
> file's dired information. Then before stopping, it sorts all
> instances together, followed by all dired entries together.
> Essentialy useless.
> old machine:
> same as above
The NEWS file in Emacs 27 says:
*** New user option 'find-dired-refine-function'.
The default value is 'find-dired-sort-by-filename'.
So you can prevent the resorting by setting find-dired-refine-function
to nil (by setq in your init file or by `M-x customize-option').
> On both machines, when I pick one of my own directories and do a similar
> search,
> old machine:
> behaves normally but reports:
> error in process sentinel: Wrong type argument: integer-or-marker-p, nil
> new machine:
> did the useless re-sort as described above.
When I try your find-dired string in emacs-27 (and also in emacs-28) I
also get an error in process sentinel, but a different one:
"find-dired-filter: Invalid use of ‘\’ in replacement text". This
appears to be due to this change:
commit fb20043b2fec8e8aff6354ec1396fd5ba688b76b
Author: Sebastian Reuße
AuthorDate: Sat Dec 30 12:41:23 2017 +0200
Commit: Eli Zaretskii
CommitDate: Sat Dec 30 12:41:23 2017 +0200
Fix output alignment in 'find-dired' for "ls -h"
* lisp/find-dired.el (find-dired-filter): Fix alignment of
the file size column when the -h ls option is used in
'find-ls-option'. (Bug#29803)
index 3b0613b280..bf815d500d 100644
--- a/lisp/find-dired.el
+++ b/lisp/find-dired.el
@@ -295,7 +295,7 @@ find-dired-filter
(l-opt (and (consp find-ls-option)
(string-match "l" (cdr find-ls-option
(ls-regexp (concat "^ +[^ \t\r\n]+\\( +[^ \t\r\n]+\\) +"
- "[^ \t\r\n]+ +[^ \t\r\n]+\\(
+[0-9]+\\)")))
+ "[^ \t\r\n]+ +[^ \t\r\n]+\\(
+[^[:space:]]+\\)")))
(goto-char beg)
(insert string)
(goto-char beg)
When I revert this change (by replacing `^[:space:]' by `0-9' in the
above code excerpt), I don't get the error anymore. Since the error
message you got is different, it may have a different cause. In any
case, it looks like it warrents a bug report (`M-x report-emacs-bug').
> ispell behaves differently (previous ispell, not using the hunspell
> additional).
> old machine:
> it works normally
> new machine:
> ispell-check-version: /usr/local/bin/aspell exited with signal Illegal
> instruction: 4
I can't help with this one, but maybe it's also worth a bug report.
Steve Berman
__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help
