Re: [ESS] unexpected behavior for Emacs-27.1-1-modified-1 for two MacBooks.
On 26 January 2021 at 18:59, 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.
This is now solved.
Jeff Mincy was kind enough to email me off-list with the hint about
(require 'loadhist)
(file-dependents (feature-file 'cl))
which did not yet "display" a solution leading me to google for 'loadhist
file-depedents' which lead me to
https://www.emacswiki.org/emacs/LibraryDependencies
where I learned about variable 'load-history. Which had lots of lines (many
of course with cl-lib) but in particular one pair with
("/usr/share/emacs/site-lisp/elpa/ess-18.10.2/julia-mode.elc"
(require . cl)
and lo and behold that (old) version of julia-mode.el still has a (require
'cl) with a comment that cl-lib could not be used b/c of emacs23. So I had
edited that and now all is well.
I had of course previously grep'ed by emacs files below ~ and the elpa
directories, but what got me here is that the elpa-* meta packages under
Debian / Ubuntu install under the path above. I should file a bug with this
fellow named Dirk E. who named looks after the ESS package and get him to
update the Debian package I use on Ubuntu ...
Thanks all for the help. With this I am not fully on Emacs 27.1.
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help
Re: [ESS] Next steps [OT] Best Practices Emacs / ESS Mini-Webinars
Hello, Going back to our earlier conversation about ensuring the accessibility of Mini Webinars, I'm able to share MiR's Accessibility Workbook (attached). This is of particular interest to blind R users because the RStudio IDE is not an option for us due to its inaccessibility. Please let me know if you have any questions. Liz > On Jan 18, 2021, at 3:32 PM, Liz Hare wrote: > > Thanks for asking, Chris, Sorry it's taken me so long to answer, but I'm > working on something related that I hope will be helpful for this project. > > Accessibility best practices are kind of specific to how you want to present > the materials. I've been working on pieces of this with R Forwards > https://forwards.github.io, where our work started on accessibility of > in-person conferences > https://github.com/forwards/event_best_practices/blob/master/DRAFTEventBestPracticesDisability.md). > Relevant parts of these guidelines were adopted with UseR2020 was moved > online. > > I'm also working with MiR (https://mircommunity.com) on the accessibility of > their webinars. In the next couple of weeks, we should have pretty extensive > accessibility guidelines to share. I will let you know when that document is > released. > > Thanks again, > Liz > > > >> On Jan 2, 2021, at 5:22 AM, Chris Wallace wrote: >> >> Hi Liz, perhaps your input before decisions about form are taken would be >> useful. Are there some general principles docs we should refer to? C >> >> http://chr1swallace.github.io >> On 30 Dec 2020, at 14:49, Liz Hare via ESS-help >> wrote: >> Hi, all, >> >> As you decide what form these materials will take, hit me up for tips and >> questions about how to make them accessible to R users with disabilities. >> >> Liz >> >> On Dec 30, 2020, at 9:38 AM, Dirk Eddelbuettel via ESS-help >> wrote: >> >> >> On 30 December 2020 at 17:27, Greg Minshall wrote: >> | i've never been involved in a multi-user gitlab/github thing (i'm pretty >> | much a loner), so i don't know how collaboration works best. but, it >> | might make sense to start all in the same repo. in ignorance, maybe >> | Dirk would be in charge of creating subdirectories, and delegating >> | editing authority to one or more of us for that subdirectory? (either >> | using some git*-provided controls, or by mutual agreement.) >> >> I suggest to bounce the question back to the group as someone a little >> involved with a few multi-user / multi-contributor repos: having an org and >> indedependent repos therein may be better. Also makes it easy for a few of >> us to "own" the org and share it. >> >> | and, maybe a section at the end of collabedit: name/initials/topic >> | volunteering? i'll start. >> >> Yes please, an excellent suggestion. >> >> Dirk >> >> -- >> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org >> >> >> ESS-help@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/ess-help >> >> >> ESS-help@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/ess-help > __ 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.
For completeness:
I decided to stay with aspell. simply because that (60.6 from 2014) is what I
had been using,.
I downloaded hombrew and had it install the newer aspell 60.8 (2019).
Just four lines and now M-x ispell works.
/bin/bash -c "$(curl -fsSL
https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
/usr/local/bin/brew update
/usr/local/bin/brew install aspell
/usr/local/bin/brew link --overwrite aspell
From: ESS-help on behalf of Richard M.
Heiberger via ESS-help
Sent: Tuesday, January 26, 2021 8:38 PM
To: Stephen Berman; Richard M. Heiberger via ESS-help
Subject: Re: [ESS] unexpected behavior for Emacs-27.1-1-modified-1 for two
MacBooks.
Thank you Stephen.
The two emacs repairs (find-dired-refine-function and find-dired-filter) you
sent worked for me.
The aspell I pushed a bit farther. In 2015 I replaced the aspell (dated 2009)
in /usr/local/bin with something from homebrew.
I remember no details. When I installed the new M1, the Apple installation
process automatically copied everything from the old machine,
including the homebrew aspell and my subdirectory containing the 2009 files.
If there had been an Apple M1 aspell, it was overridden. Based on Vincent
Goulet's notes, there might
not have been one, and in any case he recommends hunspell. I will address the
spelling problem soon, but not today.
Rich
From: Stephen Berman
Sent: Tuesday, January 26, 2021 4:07 PM
To: Richard M. Heiberger via ESS-help
Cc: Richard M. Heiberger
Subject: Re: 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
Re: [ESS] unexpected behavior for Emacs-27.1-1-modified-1 for two MacBooks.
Regarding cl: On top of replacing (require 'cl) with (require 'cl-lib) I also needed to make a number of changes to the usage of various cl functions. Emacs would complain about unknown functions once I did (require 'cl-lib). Basically all of the cl functions were changed from XX to cl-XX for example destructuring-bind changed to cl-destructuring-bind. Once I figured this out, it didn't take too long to fix, despite all of the cl code being copied from somewhere on the net. Best, Kasper On Wed, Jan 27, 2021 at 9:54 AM Stephen Berman via ESS-help < ess-help@r-project.org> wrote: > On Tue, 26 Jan 2021 18:59:27 -0600 Dirk Eddelbuettel via ESS-help < > ess-help@r-project.org> 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 > -- Best, Kasper [[alternative HTML version deleted]] __ 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
