forked from emacs-ess/ESS
-
Notifications
You must be signed in to change notification settings - Fork 0
/
TODO
1325 lines (987 loc) · 48.8 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
-*- indented-text -*-
$Revision: 4.13 $
The original TODO list (nothing fixed there yet):
===========================================================
The following things need to be fixed. In a very rough order of priority.
* (DS) M-RET in *S* doesn't work properly with multi-line inputs.
* (DS) Typing C-c C-d in an S-mode buffer can read the wrong file
(apparently the wrong value of S-directory is used.)
* (DS) Maybe S-eval-region should do S-view-at-bottom, too
* (DS) It would be nice to interpret a nil value of S-directory as the
default directory.
* (DS) Add a predicate to control when S-object-list is dumped. It would
be nice to dump this only if an assignment has taken place or the
search list has changed.
* (DS) C-u -1 C-c C-x C-c C-o produces odd results
* (DS) Automate inferior-S-send-input to delay sending to the S process
until a complete command has been typed. (I.e. when presented with
an incomplete command, RET behaves like LFD). If this is done,
multi-line commands will always get into the history as one entry.
* (DS) The menus need finetuning, and a binding to a keyboard key.
* (DS) Need to decide on a sensible policy on csh-like history references.
At the moment, expanding such references is only possible from the
menu.
* (DS) Need a keystroke to kill an edit buffer *and* the associated file.
* (DS) Need a function to copy an object to a new object *and* copy
it's source file to a new source file, modifying the target of
the assignment.
* (DS) Debugging support, through trace() and tprint()
* (DS) Modify S-beginning-of-function so that, with arg n, will move out
n layers of nested functions. Wiht C-u arg, move to outermost
function definition
* (DS) Rewrite the S-command and S-eval-visibly functions to use
transaction queues (so that we can really have S running in the
background) This is a big job.
=============================================================
Here is the new set (a start for S-mode 5.0).
NOTE: Not all of these are clean OR are even consistent.
--------------------------------------------
* (KH) Fix indentation for "{" in the GNU style...
Kurt> * What I also find frustrating is that the GNU style does
Kurt> not get the indentation of `{' in:
Kurt> fun <- function(x, y, z) {
Kurt> right (in fact, the results of hitting TAB on the second
Kurt> line seem to vary). But it is not important.
* (KH) It may be worth while replacing
("^[>+]" . font-lock-keyword-face)
in R-inf-font-lock-keywords by
("^[RS]?[>+]" . font-lock-keyword-face)
(or perhaps something even better assuming the coexistence of processes
called R, S, S<something> on a system with the corresponding prompts.
(MM) Yes, add "S4" to this list to get something like
("^[RS]?[1-9.]?[>+]" . font-lock-keyword-face)
is not quite correct, since it includes ".3>" buth should rather
"R0.50>".
* (KH) In R at least, asking for deletion of a file after loading it with C-c
C-l does not make sense.
(MM) Yes! -- this has been a real pain, especially when the file was
version-controlled, it sometimes has just been deleted w/o asking !
* (KH) Also, there is no support for an Emacs-specific startup file. This is
not really important right now, I think, but anything based on comint
and term should support that.
(Tony, if you look at my R-inf.el, you'll notice that some effort goes
into doing the right thing with output from startup args and files.)
* (KH) The function S-complete-object-name() in S-inf.el currently
returns
(or (comint-dynamic-simple-complete pattern components) 'none)
with the comment `always return a non-nil value to prevent history
expansions'. Do you have an idea what that means?
Is there any good reason to break the Emacs/Comint convention that a
completer should return a non-nil value only if it did successfully
complete?
The specific reason why I ask is the following:
S-inf does
(setq comint-dynamic-complete-functions
'(S-complete-filename
S-complete-object-name
comint-replace-by-expanded-history))
I don't care about the last and prefer
(setq comint-dynamic-complete-functions
'(S-complete-object-name
comint-dynamic-complete-filename))
Note the reversed order of filename and object name completions. I
think it makes more sense that way, because if I have the file
`anthony.dat' in my current dir and do
anthony <- read.table("anthony.dat")
then typing `ant TAB' at the R prompt should complete to `anthony'
as an object name, as I can always force the filename in the current
dir by `./ant TAB'.
However, as S-complete-object-name() always returns a non-nil value,
the comint file name completion simply does not happen (well
... that's at least what I think is the case ... but then also, what
is the point to have comint-replace-by-expanded-history() in the
list of completers, when it definitely will never be called
... hmmm.)
Please let me know what you think. My suggestion would be to simply
change the last 2 lines of the code for S-complete-object-name() to
(comint-dynamic-simple-complete pattern components))))
and set comint-dynamic-complete-functions as I do :-)
Well ... what I said was not quite right, as S-complete-object-name
also tries to do something about `./ant RET'. In any case, please
let me know what you think.
* (AJR) Need an AUTOCONF for configuring Makefile, etc...
* (AJR) Move S-extras into the mainstream distribution files and as an
S-site example.
* (KH) So, need a "create-debian" entry in the Makefile.
* (KH) MINOR REMARK: Currently, we have American and English spelling
together. If we want to change this, please add it to the TODO list.
* (KH) MINOR REMARK: Some of the doc strings are not o.k. (first
sentence longer than one line ). We eventually need to fix this,
but perhaps not for 4.9.
* (KH) Btw, why not have `M-x vista' too?
* (KH) MAJOR REMARK I:
The code for getting the `right' history file does not work. E.g.,
when I start R and XLS in the same directory, they both use
.Rhistory.
For a possible solution, see the novel below.
* (KH) MAJOR REMARK II:
The code
(condition-case ()
(load S-object-name-db-file)
(error
(message "%s does not exist. Consider running S-create-object-name-db."
S-object-name-db-file)
(ding)
(sit-for 1)))
in S.el causes several problems.
First, it produces an error in the byte-compilation process. I
noticed that you put an empty S-namedb.el in the distribution, but
that does not help if `nil' is not in the default load path
(because then the current directory is not searched), which I think
is the default.
Second, there should obviously be different namedb for R and S.
(What I really mean is that the setting of S-object-name-db must be
a function of the implementation [have we officially decided on
using `dialect'?] used. Hence, the right thing most likely is to
execute the code not when loading S.el, but when it is clear which
process is started (assuming we have different namedb's for each
dialect).
This could probably be as late as before inferior-S-mode-hook, but I am
not sure.
(Note: currently this is not a problem for me, because I only have R,
but what does Martin do?)
* (KH) NOVEL:
So I spent several hours yesterday trying to figure out the right way of
solving our problems with local variables, in particular because Martin
explicitly asked me to do (only to find that the next morning Tony had
already done something about it ...).
I think it is important to distinguish two kinds of variables that need
to be taken care of.
** One group is those variables which need to be known when the inferior
process is started (i.e., before the process and hence also its buffer
exist).
Such variables are
*) dialect (currently transmitted through S-proc-prefix)
*) program name (`R' might be on the load path)
*) program args (such as for `-v 10' for R)
*) program startup file (currently unused)
*) program history file (???)
** The other group consists of those which are not needed for startup,
but need to have the right buffer-local values in the interaction
buffer, such as
inferior-S-help-command
inferior-S-objects-command
etc.
The problem we have is that there is NO WAY of passing non-global
values to buffer-local variables in Emacs. Something like
(defun R ()
(let ((inferior-S-var value))
(inferior-S)))
does not set inferior-S-var to value in the interaction buffer if it is
local there. (Sort of static scoping.)
There are several possible solutions:
** Keep manipulating the global name space using setq-default, as b4
did. Of course, this is terrible, because it overrides defaults.
** Have one function which does something like
(cond
((eq S-dialect "R")
(setq ...))
((eq S-dialect "S4")
(setq ...))
(t
(ERROR)))
after calling make-local-variable() on the relevant variables, and wrap
the code into a function.
To add a dialect, users would need to to this in there inferior-S-mode
hook, or to advise/change this function.
** Have a list similar to S-style-alist with settings for the variables,
and a function which sets them. This is similar to the above, but keeps
the code for the function and the variables separate.
** Have a dialect specific hook, e.g.
inferior-S-<dialect>-mode-hook
** Keep manupulating a non-dialect-specific hook in the global name
space. This is what we currently do, and not `optimal' for the same
reason that using setq-default was not: If we think of inferior-S as
user function and S and R as simple wrappers, then calling these should
not modify the behavior of the generic function.
I think the KEY to a clean solution lies in the observation that there
is really only ONE variable needed in both steps (i.e., cranking up the
process and setting local variables in the interaction buffer), and that
is the information about the CURRENT DIALECT (which I think is currently
kept in `S-proc-prefix'. We need to ensure that this variable has the
right local value to be able to run a specific hook (or a simpler hook
as explained above), and that it starts the right process in the right
buffer etc.
To get that, we could either create a global variable, KEEP IT GLOBAL,
use let() in the wrappers, and assign to a local variable afterwards, or
(and I think this is the right thing to do) PASS THE DIALECT INFORMATION
AS AN ARGUMENT. I.e., we would have
(defun inferior-S (&optional dialect n)
...
[NOTE: I am not sure about the optional `n', and whether this is used.
I think that users might want to have
(defun R (&optional n) ...)
(defun S (&optional n) ...)
and we are safe to give inferior-S the interface we want because it is a
NEW function anyway. We could also have it prompt for all relevant
variables if given a prefix ...]
and have
(defun R (&optional n)
(interactive)
(inferior-S "R" n))
Now the function inferior-S has the information it needs. It can figure
out the `right' startup settings (history file, program name and args)
based on the dialect information in the generic pre-run hook and perhaps
a dialect-specific pre-run-hook, and PASS THE DIALECT INFORMATION ON to
the function S-multi() [or whatever it will be called]. I.e., it could
be
(defun S-multi (name &optional buffer dialect) ...)
S-multi can now do
(make-local-variable 'S-dialect)
(setq S-dialect (or dialect S-default-dialect))
and go on with the buffer-specific settings, again using the dialect
information as described above.
[Yes, there should be a default dialect which is used when inferior-S is
used directly. Perhaps naming would be better with global S-dialect and
inferior-S-dialect as the local one ...]
* (MM) My WISH:
I'm using ess-eval-region and friends very often.
If the region has leading TAB, I think the readline feature of R,
does a huge 'completion ...'
which can completely destray the whole evaluation.
((Try C-c C-f from within a function that has a bit of indentation,
and therefore leading TABS (unless you 'untabified' it).
))
Yes, I'll have to 'untabify' things before I send it to *R*, but it's a
pain, anyway.
One could do 'untabify' in ess-eval-region & ess-eval-visibly
in ess-inf.el.
But actually this is not quite correct,
since I may have real TABs in a string
nchar(" ") #-> 1 because it has one TAB
which should not be converted to spaces.
Hence my wish:
Write a function 'untabify-leading-white-space'
and apply it to the regions in ess-eval-region and ..-visibly.
* (RMH)
5. ess-s3-d.el
63 ;;(if (string= ess-version-running "S3")
This comment seems inconsistent with ess-version-running. I think it should be
;;(if (string= ess-version-running "S+3")
7. ess-object-name-db-file
ess.el line 775. Why is this EVIL? A nuisance I understand, but EVIL?
Does the database get built automatically when ess-mode is installed?
That would be the right thing to do. Then individual users wouldn't need
to know about it all.
10 ess.el lines 254-270
This is one of the things I put in my site-start.el. I think this is
too complicated. I think that when item 2 of this note is corrected (that is
run the ess-pre-run-hook before the things that depend on it) then the nil
value will work as advertised and the comment beginning with the word
" Alternatively," will become completely unnecessary.
(defvar ess-directory (file-name-as-directory (getenv "HOME"))
"*The directory ess is run from. It must end in a slash.
Provided as a default if ess-ask-for-ess-directory is non-nil.
A nil value means use the current buffer's default directory.
Buffer-local: in process buffers, this contains the directory ess was
run from.")
;; You can put something like:
;; (setq ess-directory (file-name-as-directory (concat (getenv "HOME") "/ess/")))
;; in your ~/.emacs file and ess will always start up in your ~/ess directory.
;; Or you can say:
;; (setq ess-directory nil)
;; in your ~/.emacs file and ess will always start up in your current buffer's
;; default directory.
[[[[ delete
;; Alternatively, you can get ess to start up in the current buffer's directory
;; by putting this in your .emacs
;; (setq ess-pre-run-hook '((lambda () (setq ess-directory default-directory))))
;; Better (more correct) version:
;; (defun ajr:ess-set-directory ()
;; "Set ess-directory to current directory."
;; (setq ess-directory default-directory))
;; (add-hook 'ess-pre-run-hook 'ajr:ess-set-directory)
]]]]
* (RMH) From smode.cmt (from the S4 package):
<-- AJR: some of these HAVE been done. -->
e. Problem
Working data will be in /usr/people/rmh/.Data
> !pwd
/disk5/rmh/smode
>
Reason:
.Data has not yet been created in /disk5/rmh/smode
Solution:
quit S, mkdir .Data, start again
Recommendation 1. Tell users in README to create .Data first.
Recommendation 2. Tell users in README about Info item
- User Option: S-directory
I for one always want the current buffer's working directory.
g. Question:
S-help does the following:
(S-command (format inferior-S-help-command object) tbuffer)
which seems to going through more work than is often necessary. When the
.Cat.Help subdirectory exists, why not just M-x find-file the help file?
2. S3, Splus 3.3, S4
e. S-inf-font-lock-keywords
In inferior-S-mode the expressions below are in the indicated faces:
> tmp <- 1:3 # > is in font-lock-keyword-face
# rest is font-lock-variable-name-face
tmp <- 1:3 # <- is in font-lock-reference-face
# rest is in default
I don't understand why.
>From the definitions in S-inf.el, I expected that there would be
no dependence on the presence or absence of the leading prompt ">".
In particular, I anticipated that <- would be in font-lock-reference-face
with or without the prompt.
f. S-inf-font-lock-keywords
I recommend adding several keywords to S-inf-font-lock-keywords
for S3 and Splus 3.3 as noted in the attached s3.el and splus.el.
g. Interesting glitch
While fixing C-c C-l for S4, I found the following:
>From the *scratch* buffer, both the commands
(S-command "source(\"junk.s\")\n" (get-buffer "*S-errors*"))
(S-command "source(\"junk.s\")\n")
work correctly when junk.s is ok.
The first one puts an error message in "*S-errors*" when junk.s has a
problem. But the second one loses the error message. I chose not to
investigate this further, since S-load-file uses the first form, and I
doubt any person would consider using the second.
3. S4 changes
a. S-mode.el [C-c C-l S-load-file]
;;; The S4 requires the fixes to
; S-dump-error-re
; S-parse-errors
; S-prompt-wait
;;; in my s4.el in order to respond correctly to syntax errors
;;; during S-load-file.
;;; Without these changes the system will freeze.
;;; (^G will clear the freeze, and ^XB *S-errors* will
;;; display the error message).
b. S.el and S-site.el
The variable S-version-running, defined in S.el, with the option to
revise in S-site.el, needs to be redefined to identify version 4.
Some of the items coded by S-version-running differ in Version 4.
b1. S-inf.el
(setq inferior-S-search-list-command "searchPaths()\n")
;;; This variable needs to depend on S-version-running.
;;; the function inferior-S-search-list-command should probably use
;;; inferior-S-search-list-command, but it actually has "search()\n"
;;; hard-wired in.
;;; inferior-S-objects-command is the same for version 4 as for version 3
b2. S.el
;;; inferior-S-help-command
;;; inferior-S-search-list-command
;;; S-dump-error-re
Add a new line
;;; inferior-S-objects-command
b3. S-help.el
;;; S-submit-bug-report needs to know about version 4 for a bug report
;;; to be useful.
c. Other changes in s4.el respond to changes in S4:
.Help is now __Help
Errors are now Problems
"Dumped" messages now become offers to Debug
Additional keywords should be fontified
d. I have placed S-namedb.el in $SHOME in my s4.el file. On further
reflection it should probably be in the $SHOME/library/emacs/
directory. Question, does it make sense for S-namedb.el to be
distributed in $SHOME/library/emacs as part of binary.*.tar.gz ?
* (RMH)
Rather than have the site installer change the name of the directory,
it should be possible to find it out automatically. Here is the
relevant code from my spread.frame package. It assumes the user
started up spread.frames by typing
M-x load-file "/path/name"
It then finds the directory associated with that path and goes from
there. Some similar trick should be doable when the user does a
M-x load-library "name"
(defun find-spread-frame-directory nil
"Locate directory in which spread.frame functions are stored."
(list-command-history)
(set-buffer "*Command History*")
(goto-char (point-min))
(search-forward "(load-file ") )
(goto-char (1+ (match-end 0)))
(setq beg (point))
(end-of-line)
(search-backward "/")
(goto-char (match-end 0))
(setq spread-frame-directory
(expand-file-name (buffer-substring beg (point))))
(kill-buffer "*Command History*"))
* ([email protected] (David Nelson))
Transcript mode is delightful, with one possible improvement. Quite
often, when I'm in the middle of a session, I'd like to insert a
comment in the transcript, preferably with a distinctive type face
like those provided by "font lock". Is there an easy way to do this
that I'm just missing?
(RMH's thought):
I'm writing to you rather than directly to [email protected]
(David Nelson) because I'm not sure how to tell him to do the
following fix in .emacs or S-site.el because of the local variable
issue or if it even is the right fix.
I think the permanent answer should be for you to add the lines
(make-local-variable 'comment-start)
(setq comment-start "#")
(make-local-variable 'comment-start-skip)
(setq comment-start-skip "#+ *")
copied from S-mode.el to the files S-trans.el and S-inf.el (4.8
notation). But when I tried it out with M-x eval-expression in the
*S* buffer it didn't have the effect I anticipated.
I can't figure out the intent or meaning of the line
("^\\*\\*\\\*.*\\*\\*\\*\\s *$" . font-lock-comment-face) ; S-mode msg
from S-inf.el and S-trans.el
* (KH, 010897) Can we combine the inferior-ess font-lock-patterns for prompt
and input into one regexp? I.e., use
("^\\([a-zA-Z0-9 ]*[>+]\\)\\(.*$\\)"
(1 font-lock-keyword-face) ; prompt
(2 font-lock-variable-name-face keep t)) ; input
* (KH, 010897) Perhaps one could have an option to install the Info
files gzipped (as is default for e.g. Debian GNU/Linux).
* (RMH bad behavior)
I loaded ess-site from *shell* in directory ~/
Then I M-x S from that buffer. It asked me about starting S in ~/
The with in *shell* I cd /disk05/rmh and M-x S from *shell* again.
I think it should have attempted to start S from /disk05/rmh, but instead it
again asked me about starting S in ~/
* (AJR/RMH) make sure that font-lock stuff is properly set. (look into
file order, for example).
* (AJR) Kurt> * When first starting R and then XLS, we have
Kurt> ess-history-file's value is ".Rhistory" Local in
Kurt> buffer *R*; global value is ".XLShistory"
Kurt> Why is there a non-nil global value?
> Because of the nature of buffer-local variables. It doesn't really
> matter, since I'm ALWAYS ignoring the global value (at least that is
> my intent).
* (MM) Date: Fri, 22 Aug 1997 09:11:25 +0200
>>>>> "Kurt" == Kurt Hornik <[email protected]> writes:
>> * Questions: 1. I don't understand why ess-customize-alist is not
>> buffer-local (This definition is from ess-vars.el.): (defvar
>> ess-customize-alist nil "Variable settings to use for proper
>> behavior. Not buffer local!") ;;(make-variable-buffer-local
>> 'ess-customize-alist) ;;(setq-default ess-customize-alist nil)
Kurt> Personally, I think that most of the (make-variable-buffer-local
Kurt> ...) and (setq-default ...) will have to be replaced eventually
Kurt> by making the variables local when needed and passing them not in
Kurt> the global environment but rather as explicit arguments to the
Kurt> caller functions.
Kurt> E.g.,
Kurt> (ess-start-process NAME BUF FILE ARGS ALIST)
This is cleaner from a programming point of view,
however is n't this much less CPU efficient ??
>> 3. Should ess-proc-prefix be renamed to ess-language? I glanced at
>> the result of 'grep ess-proc-prefix *.el' and don't immediately see
>> a problem.
Kurt> Yes, good idea. Could we then have
Kurt> ess-language ess-dialect
Yes, this looks like the thing to aim at !!
Together with what Kurt wrote in the last e-mail's PS:
Kurt>>> PS. We should decide on a scheme for languages (S, XLS, ...)
Kurt>>> and what we call ``dialects'' (for S: S3, S4, S+, ..., R).
Kurt>>> This would allow us to have a general mechanism for dealing
Kurt>>> with the above, such as
Kurt>>>
Kurt>>> * In the caller function (M-x S, M-x R, ...) set language and
Kurt>>> dialect.
Kurt>>>
Kurt>>> * Then, we don't explicitly have to assign all variables which
Kurt>>> should be local (such as font-lock-keywords) anyway, but could
Kurt>>> figure them out by
Kurt>>>
Kurt>>> looking for <language>-font-lock-keywords looking for
Kurt>>> <language>-<dialect>-font-lock-keywords
Kurt>>>
Kurt>>> Hooks could be organized similarly
Kurt>>> ... (ess-inf-S-S4-mode-hook?)
* (RMH 31 Jul 1997 07:22:10 -0400 or earlier)
* what it doesn't do 1. The effect of the second line is to prevent
* font-lock information from happening on input lines. The prompt
* is highlighted, the rest of the line is not. The effect is to
* cancel the usefulness of syntax highlighting on user-typed
* commands. Syntax marking is only in effect when the system types
* a function back to us.
2. I can't figure out what the ess-mode msg line is doing.
("^\\*\\*\\\*.*\\*\\*\\*\\s *$" . font-lock-comment-face) ; ess-mode msg
3. comments (beginning with #) are syntactically ignored by
highlighting. In ess-mode, comments are not picked up with this
table (actually ess-mode-font-lock-keywords). They are picked up by
ess-mode-syntax-table on line 733 of ess-vars.el.
4. what are the < > characters doing in this line:
("\\<\\(TRUE\\|FALSE\\|T\\|F\\|NA\\|NULL\\|Inf\\|NaN\\)\\>"
. font-lock-type-face) ; keywords
* open questions
1. I think I want ess-mode-font-lock-keywords to be effective in
inferior-ess and in ess-transcript. That means to the user, the <-
and function and T and F will be highlighted as commands are typed
in.
2. That means to the ess-mode designer that the line
("^[a-zA-Z0-9 ]*[>+]\\(.*$\\)"
(1 font-lock-variable-name-face keep t)) ; input
is deleted from inferior-ess-font-lock-keywords.
3. Further it means that inferior-ess-font-lock-keywords should be
defined by adding additional definitions to
ess-mode-font-lock-keywords.
* harder questions
1. these keywords are hardwired. They should probably be put into
the *-customize-alist. In particular, S4 uses different keywords
for errors (problems) and so forth. It also uses different keywords
for the Help file (__Help instead of .Help). These are functional
differences, not just cosmetic differences where the font would be
wrong. See the comments in ess-s4-d.el (based on my original s4.el).
(just noticed, the current ess-s4-d.el has two ending pages.) It is
easy to make ess-mode work for S4 by overriding all the differences
(which is how s4.el works). It is harder to do it cleanly so the
same emacs session can be used for S4 and S3. Lots of currently
hardwired variables need to be moved to the *-customize-alist first.
xlispstat is quite differently structured, so I am sure that the
keywords and highlighting here will be either irrelevant or harmful
if applied directly. customization is needed for that generality as
well.
* comments
I'm confused? I've always gotten comment highlighting in
inferior-ess/S-mode. Or do you mean that it's not done in the right
place?
correct, it is not done where you think it is done (right place or
not). It is done by ess-mode-syntax-table for inferior and
transcript mode. It is not done at all for ess-mode. The font-lock
settings seems to be irrelevant.
* logic
Richard> 4. what are the < > characters doing in this line:
Richard> ("\\<\\(TRUE\\|FALSE\\|T\\|F\\|NA\\|NULL\\|Inf\\|NaN\\)\\>"
Richard> . font-lock-type-face) ; keywords
using the typeface for the inequalities, for boolean statements/tests.
Not so. The < > do not appear in font-lock-type-face.
* Hmm... I think that was the font that was to be used for the prompt.
Not so. The previous line is used for the prompt. This line seems
to be used to suppress font-lock control for all characters
following the prompt. Note that the (1 ...) is in the position
normally taken by the "." . I assume the keep makes it stay that
way for the rest of the line. I haven't bothered to read font.el to
figure this out.
* *Buffer List*
. text.st 0 ESS Transcript /disk05/rmh/text.st
test.r 0 ESS[R] /disk05/rmh/test.r
test.s 0 ESS[S] /disk05/rmh/test.s
* *S4* 236 Inf-ESS
Note that the *.r and *.s files include the [R] and [S]. The
inferior processes do not include the ess-version-running, I wish
they would. The corresponding modelines are
(ESS Transcript [] Font)
(ESS[R] [none] Font)
(ESS[S] [none] Font)
(Inf-ESS [S4]: run Font)
I don't know the original intent of the [] and [none], but I would
love to see the name of the buffer to which ^C^N is sending stuff.
* ^C^N goes to the wrong inferior process.
I opened test.r in the same directory as *R* and sent a line. It
went to the *S* buffer in a different directory and running the
wrong program. There needs to be a way for the system to ask me
which process to use. Also, it's default guessing system should
have guessed *R* based on the file name test.r.
* hooks
in ess-vars.el, line 317 and following, some of the hooks are
initialized to '() and others to nil. Is there a difference?
* ess-source-modes in ess-vars.el line 382
Is this obsolete now that auto-mode-alist has the suffix information?
* (AJR, via MM, RMH, DB): distinguish between files of dumped objects
and files of loading objects.
* (RMH/AJR)
Richard> essl-sas.el
Richard> SAS-log-mode
Richard> As present, SAS-log-mode doesn't do anything but be
Richard> human-readable. My intent in basing it on
Richard> ess-transcript-mode rather than on fundamental-mode is
Richard> that when sas-clean-region and related functions are
Richard> figured out, then the log file can be used to re-enter
Richard> commands back to *SAS:1*. We will look for all numbered
Richard> lines between a
Richard> 34 PROC abcd;
Richard> ...
Richard> 38 run;
Richard> pair, sas-clean-region them and send them over to
Richard> *SAS:1*. This is NOT an exercise for 5.0. But because
Richard> it is intended, I feel (weakly, not strongly) that it
Richard> would be better to base SAS-log-mode on
Richard> ess-transcript-mode. This plan should be formally
Richard> entered into the TODO list.
I would agree with this. I'd also like to make sure that we have a
means of easily going between linked buffers. Added into the TODO
list.
Richard> While we are entering things in the TODO list, I would
Richard> like to consider setting up *SAS:n* as a unix pipe,
Richard> rather than as a unix buffer/file. I don't know how to
Richard> tell emacs to do that. The idea is to mimic the behavior
Richard> of the SAS edit window where, once the Submit menu item
Richard> has been clicked, the window is emptied.
No, I think that using as a buffer would be better (especially for
debugging any weird problems). Hiding it, though, will be desirable.
Richard> I can also see a case for leaving the *SAS:n* buffer as a
Richard> buffer. We should consider making it read-only to force
Richard> the user to do all thinking in the ex123.sas buffer. The
Richard> only reason I can currently think of for letting the user
Richard> write directly in the *SAS:n* buffer is to enter the
Richard> commands
Richard> stop;
Richard> or
Richard> endsas;
Richard> I can't think of any reason to save the *SAS:n* buffer
Richard> and would like to know if there is any way to prevent the
Richard> user from saving it.
and not even that, since that should be the result of C-c C-q, so
that we get a nice, uniform means of exiting.
(RS1) I don't believe the sas-log-mode suggestions were ever implemented.
In fact, sas-log-mode is not a default option anymore since there
are so many different applications that create .log files.
Instead, a few changes were made to sas-mode based on requests for syntax
highlighting of the .log. This feature can be toggled on and off
by F10. This temporarily turns on sas-mode for .log files so you will
not experience permanent extension collisions with other .log file
generating applications. Also, performance may be an issue.
Extremely long .log files (particularly those generated by macros
that involve alot of code-generation) can be extremely time-consuming
to fontify and lazy-locking is usually not an option due to the
complexity of the SAS regular expressions. Fast-locking may help a
bit, but font-locking of several minutes is not unheard of.
Also, the font-lock code was re-written to properly highlight either
a .sas or a .log file. See ess-sas-run-make-regexp below.
(RS2) Rich re-did sas-log-mode to use the font-locking from ESS[SAS] and
it seems to be working. The only caveat is that I found that
fast-lock is very slow for big .logs and I switched to lazy-lock
and it is much faster, however, I have problems toggling; usually,
after I turn it on, I can't turn it off; but, that's not so bad
with lazy-lock. Also, a new function creates transcript from
your .log, ess-sas-transcript
* (KH) Font-lock needs to be more intelligent about recognizing
reserved words in non-reserved contexts (such as in "strings").
(RS1) If this was a SAS problem, then problem has been fixed.
To turn on the new functionality,
(setq ess-sas-run-make-regexp nil)
(RS2) This is now the default and most known issues have been addressed;
even hanging then statements!
* (AJR) SAS indenting needs to be fixed.
(RS) I don't know if this was fixed, but I haven't had any problems
with indenting recently.
* (AJR) SAS fontlocking of comments needs to be fixed.
(RS) I believe this is done. We made a few changes, but the biggest
problem was that Emacs 19.34 was misbehaving.
See ess-sas-run-make-regexp above.
* (KH) explicit statement:
I have only one remark (one of my usual ones). I'd like to be able to
pass command line arguments to the inferior process when it is started.
This is currently not supported, and poses some difficulties with an
interactive prompt mechanism. (Also rules out my suggestion of using
C-u to force prompting for command line args.)
Hmm ... Perhaps we should have a variable (ess-inf-always-prompt-...)
to get around this problem?
* (RMH - SAS)
graphics are possible in two ways:
a. proc gplot; plot a*b / vpos=25;
b. goptions device=psfile;
filename gsasfile 'temp.ps';
and then use ghostview from another *shell* buffer.
autoexec.sas defines the departmental printers and turns off
overprinting. My autoexec.sas file is:
libname gdevice0 '/home/public/stat/gdevice0' ;
options noovp;
* (RMH - SAS) I have another proposal for font-lock in SAS-mode. I
think it will be easy, but I would like discussion first. My new
proposal is that
proc whatever
data myfile
%macro macname
and maybe a few others (including both the keyword and name of the
dataset or proc) be in font-lock-function-name-face
%include will be in font-lock-reference-face
Any other FIRST word in a statement will be in
font-lock-keyword-face
My reasoning is that the current laundry list is too long, and still
misses many keywords. The structure of the SAS language is
essentially keyword and arguments, so let's follow that.
(RS) Essentially done. The following statements are in
font-lock-reference-face: macro statements, PROC ...,
DATA, RUN, ENDSAS, and QUIT.
See ess-sas-run-make-regexp above.
* (Tobias Laatsch - SAS)
There seem to be some problems fontifying SAS Comments in ESS 5.0
Pre1. (I'm running xemacs 20.2 on AIX .)
Currently I recognized following problems:
1) Multi-line-comments are not fontified. (open comment "/*", some
lines of code, close comment "*/")
2) When typing / , " or ' in a comment-area, ESS fontifies the
whole line as normal code instead of comment.
3) Typing a '* in a comment-area fontifies the rest of the line as
string.
(RS) Fixed for /* */ style comments which are now handled by grammar
only. * ; and %* ; are still broken since they can't be
specified by grammar.
* (AJR)
Richard> I think of S-transcript-mode as identical to
Richard> inferior-S-mode except that the transmission is to the
Richard> same buffer in inferior-S-mode and to a different buffer
Richard> in transcript-mdoe. So I expect ^M (enter) to behave
Richard> normally for lines that begin with "> command" and "+
Richard> continuation".
Which is what my proposal does (send command, move to next prompt).
What needs to be modified is that currently, it moves to any next
prompt, including "+ ", rather than just to the next primary prompt --
it is smart enough to strip the "+ " as well from the whole command,
and collect the rest of the command line.
Richard> I haven't tried eval-region commands from either *S* or
Richard> from a filename.st. I think both ^C^N and ^C^R should
Richard> make sense and work if the region is valid input. Both
Richard> modes should strip leading ">" and "+" characters. I
Richard> think that a region which is a subset of a line, or which
Richard> doesn't begin with the standard prompt sequences, should
Richard> send it over literally.
So, C-c C-r would only send lines beginning with
inferior-ess-primary-prompt (up to the last consecutive
inferior-ess-secondary-prompt), strip off the prompt, and ignore lines
which do not begin with prompts. Does this sound correct
(for C-c C-r)?
C-c C-n should be correct (comint-next-prompt).
* (KH/AJR)
I see. This is what the "help(\"%s\")\n" does.
Well, we have the following problem. The `new' interface to help()
I created is
help(topic, package = .package(), library = .lib.loc)
This allows you to get help on a topic (R object, ie fun or var or
whatever else is documented) in a package without loading it, via