Re: Problem with CC mode hooks and font-locking

Re: Problem with CC mode hooks and font-locking

[Van L]

> I am now at the point of not liking 
> what this is doing because, as Eli said, 
> all coloring has been disabled. 
> I did like seeing the colors in buffers like 
> the output of "grep”.

What you can do to fine tune the coloring is by 

#+NAME: fix--sh-heredoc-color-is-unreadable
#+BEGIN_COMMENT

1. M-x list-faces-display RET
   - alt :: C-u C-x =
     - apply to the offending unreadable character
2. sh-heredoc
   - example :: default coloring is unreadable for me
     - when M-x set-background-color is Gray
3. M-x customize RET
4. search for sh-heredoc and change it

#+END_COMMENT

Re: Problem with CC mode hooks and font-locking

[Van L]

> I have no clue what your 4 steps do

No probs. 

That note there helps with 
interactively choosing colors in the 
font-locking contextualization of 
text in the various modes.

I had been ignoring colored text
I was unable to read for ages
until I figured that out.

Where is Emacs Lisp taught ?

[Jean-Christophe Helary]

I'm trying to gather information about Emacs Lisp and specifically about where it is taught (bootcamps/universities, etc.)

Has anybody information on that?

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Where is Emacs Lisp taught ?

[Emanuel Berg]

Jean-Christophe Helary wrote:

> I'm trying to gather information about Emacs
> Lisp and specifically about where it is taught
> (bootcamps/universities, etc.)
>
> Has anybody information on that?

I don't think that Emacs Lisp in particular is
thought anywhere, but Lisp is thought at
universities around the world, sometimes as
part of courses in "functional programming",
where other languages might be included as
well, e.g. Haskell and Erlang (perhaps
sometimes SML).

I did such a course at UU in 2013-02-01 - it
was called "Advanced Functional Programming".

The Lisp wasn't Elisp tho but CL with the
SBCL compiler.

And I think it is better to teach CL than
Elisp, in all honesty...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Where is Emacs Lisp taught ?

[Garreau, Alexandre]

On 2018-10-24 at 18:02, Emanuel Berg wrote:
> Jean-Christophe Helary wrote:
>
>> I'm trying to gather information about Emacs
>> Lisp and specifically about where it is taught
>> (bootcamps/universities, etc.)
>>
>> Has anybody information on that?
>
> I don't think that Emacs Lisp in particular is
> thought anywhere, but Lisp is thought at
> universities around the world, sometimes as
> part of courses in "functional programming",
> where other languages might be included as
> well, e.g. Haskell and Erlang (perhaps
> sometimes SML).

Until then I heard they teached scheme from college 2nd year in the
capital of the region (racket I guess, unless it’s mit-scheme), and
everywhere else afaik it’s OCaml in France (maybe nationalism?).

> And I think it is better to teach CL than Elisp, in all honesty...

I am not sure.  Elisp is often to be considered a bad language, but it
has the somewhat rare and paradoxal double advantage (peculiar to lisp,
but more extreme here) of both having a simple and naive implementation,
and yet being quite high level and extremely close to I/O.  It also is
quite much used (I bet its usage proportion is comparable to CL and
scheme united).

Those are obvious advantages when learning programming, and are main
reasons why so far I saw stupidities such as using javascript, (damn)
VisualBasic, or python, taught to students for learning programming:
easy GUI, very imperative style, ability to do more or less functional
stuff.

But in reality, what is important is not GUI, but easy access to I/O (so
to easily develop concrete software that will solve concrete problems so
to better discover how programming is useful), and usage potential:
elisp, unlike scheme so far, has many interesting and powerful libraries
for interacting with the internet, files, keyboard, screen, and these
are extremely easy to use, compared to SDL C programming, VB GUI
programming, GTK interface usage, or even shellscripts sometimes.

I believe, especially in first year, what is important is give to
students what will make them want to pursue their studies, and, if they
fail or stop them, to keep programming stuff.  So they need an
environment regularly giving them interesting practical problems, and
making them easy to solve.  In this respect, unless using some bad
language such as python or javascript, differently bad languages such as
elisp and bash are going to be way more useful and simple to learn and
not to forgot.

I’d like to see some course introduce “emacs macros”, then some lisp
config, then progressively teach people how to program without them even
knowing it, like I saw it happened to some people before (like first
Gosling Emacs user, beside Gosling himself, iirc).  It would be cool.
We need more programming literacy in general population.

Re: Where is Emacs Lisp taught ?

[Gene]

On Wednesday, November 14, 2018 at 6:28:06 PM UTC-5, Drew Adams wrote:
> To come back to the question about learning programming
> through Emacs and Emacs Lisp, I happened to reread this 
> RMS article today:
> 
> "EMACS: The Extensible, Customizable Display Editor"
> This paper was written by Richard Stallman in 1981 and
> delivered in the ACM Conference on Text Processing.[1]

<snip>

> Educators have found display programming to be very suited for 
> children experimenting with programming, for just this reason (see LOGO).

`Display programming'?
Really?

Now we know why the venerable Richard Stallman's name was not listed as a co-author of Turtle Geometry.

ref: https://duckduckgo.com/?q=Turtle+Geometry+(book)

I see no movement of either Scratch or Snap! to promote either the translation or re-presentaion of their pixel-based `display' 
 -- as in `display programming' --
 into `cell based' -- EG `text' -- `display programming'.

Yet emacs does support SVG, which, like logo, is a Vector-based form of `display' which most of us would call `graphics';
so it would seem that SVG *might* be used to represent the line segments produced by turtle graphics via Logo, Scratch, and Snap!.

ref: https://duckduckgo.com/?q=emacs+SVG

Through this search I just discovered the possibility of SVG graphics being inlined in org-mode files is some cases, depending on the OS emacs is running atop.

https://emacs.stackexchange.com/questions/17545/inline-svgs-in-org-mode

`Display Programming' ... humpf!

G




> 
> ----
> [1] https://www.gnu.org/software/emacs/emacs-paper.html
> [2] https://www.gnu.org/software/emacs/emacs-paper.html#SEC29

Java-mode Debug question ?

[Francis Belliveau]

I am running emacs Version 26.1 (9.0) on OSX 10.13.6
I know that I downloaded and installed this earlier this year and have not used Java-mode, or c-mode, with this version until today.

When I try entering Java-mode I get an error indicating that there is a problem, with a key-map.  This happens with c-mode also.  Clearly there is something wrong with the install, but I have no clue where to look for the problem.

Setting debug-on-error provides the following information:

Debugger entered--Lisp error: (wrong-type-argument keymapp nil)
  define-key(nil "\003\005" c-macro-expand)
  autoload-do-load((autoload "cc-mode" 889279 t nil) java-mode)
  command-execute(java-mode record)
  execute-extended-command(nil "java-mode" "java-mode")
  funcall-interactively(execute-extended-command nil "java-mode" "java-mode")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

Any help will be appreciated.

Thanks,
Fran

Re: Java-mode Debug question ?

[Eli Zaretskii]

> From: Francis Belliveau <f.belliveau@comcast.net>
> Date: Sat, 17 Nov 2018 12:39:34 -0500
> 
> I am running emacs Version 26.1 (9.0) on OSX 10.13.6
> I know that I downloaded and installed this earlier this year and have not used Java-mode, or c-mode, with this version until today.
> 
> When I try entering Java-mode I get an error indicating that there is a problem, with a key-map.  This happens with c-mode also.  Clearly there is something wrong with the install, but I have no clue where to look for the problem.
> 
> Setting debug-on-error provides the following information:
> 
> Debugger entered--Lisp error: (wrong-type-argument keymapp nil)
>   define-key(nil "\003\005" c-macro-expand)
>   autoload-do-load((autoload "cc-mode" 889279 t nil) java-mode)
>   command-execute(java-mode record)
>   execute-extended-command(nil "java-mode" "java-mode")
>   funcall-interactively(execute-extended-command nil "java-mode" "java-mode")
>   call-interactively(execute-extended-command nil nil)
>   command-execute(execute-extended-command)
> 
> Any help will be appreciated.

Does "M-x list-load-path-shadows RET" give any clue?

Problem with CC mode hooks and font-locking

[Francis Belliveau]

I know that I am likely in the minority, but I find all those colors in my code distracting so I wish to turn it all off.
The documentation says how to turn it on, but that is the default and my attempts to turn it off have met with failure.

First, I am running a pre-built download of emacs Version 26.1 (9.0) on OS-X Version 10.13.6

My first attempt was to place  the line
(global-font-lock-mode nil)
in my .emacs file.  That did not work.

Then I placed it into my c-initialization-hook function.
At first, that seemed to work for a .h file, but not a .cpp, or .java, file.  What is strange here is that both the .h and .cpp claim to be running "C++ mode".
However, it seems to function differently depending on the order that files are loaded.  The first file opened (.h, .cpp or .java) is not colored, but the next two are colorized.

At this point I am confused since this should not be a toggling function call, and it should only be getting called once any way.

I had also placed it into the various "load each time" hooks with funny results that could have also been due to the order that I was loading files.

The documentation seems to indicate that just putting it in my .emacs file should be all that is necessary to take effect globally, but since it does not seem to work that way I am asking what is the correct mechanism to turn this off?

Your help will be greatly appreciated.
Fran

Re: Problem with CC mode hooks and font-locking

[Stefan Monnier]

> My first attempt was to place  the line
> (global-font-lock-mode nil)
> in my .emacs file.  That did not work.

Of course not: a nil argument turns it on, as the docstring says.  Try

    (global-font-lock-mode -1)

But personally I don't like colors either but kept font-lock:
I simply changed the faces to use bold/grey/italics instead of colors.


        Stefan

Re: Problem with CC mode hooks and font-locking

[Francis Belliveau]

First: Thank you Stefan for your answer.

I will endeavor to rerun my experiments and document the results in a more scientific manner.

To be clear, what I am trying to do is eliminate the colors being applied to text in all my files.  My understanding from the documentation is that if I add (global-font-lock-mode -1) to my .emacs file before I load any modes, the effects should be globally disabled.  Therefore, "failure" in this case is when various portions of my text is being shown in different colors.

I am not sure that it matters, but for clarity, my .emacs setup opens up with the window split vertically so that I can see two buffers simultaneously.
For the experiments below, I always open the application from my dock so that no file is loaded.  Then I usually open my .emacs file first, in the left half, then the code files in order on the right.  Where I open another file first, it is done in the left side and the others on the right.

1. Placing this in my .emacs file does not seem to have any effect.  Lisp, C++ and Java modes all show text in lots of colors.

2. Removed it from main .emacs and placed it in my 'c-initialization-hook' produces the following curious effects:
  a) Load .emacs shows Lisp mode with lots of colors
  b) Load foo.h shows C++ mode with lots of colors, but the colors are gone from the .emacs text
  c) Load foo.cpp shows C++ mode all in black
  d) Load foo.java shows Java mode all in black

  Curious about the .h file being colorized, but loading it eliminated the colors from the .emacs buffer.
  I switched between these 4 buffers in the the two sides and the coloring stayed firm with the buffer contents as expected.

  I restarted emacs without any .emacs changes and loaded the files in different order.
  - .emacs, foo.cpp, foo.java, foo.h
    Same effects, Lisp shows colors that go away when the first C++ file (foo.cpp) is loaded with lots of colors and all others are in black.
  - .emacs, foo.java, foo.h, foo.cpp
    Same effects, Lisp shows colors that go away when the first file (foo.java) is loaded with lots of colors and all others are in black.
  - foo.h, .emacs, foo.cpp, foo.java
    This time foo.h is colored, and remains that way.  All others are black.
  - foo.java, .emacs, foo.h, foo.cpp
  - foo.cpp, foo.h, foo.java, .emacs
    Both of these tests showed the first file remained all colored, and the others all black.

  3. Put it back into the main .emacs code, and left it in the 'c-initialization-hook'.
  - .emacs, foo.h, foo.cpp, foo.java
  This produced the same results as in 2 that .emacs first showed itself all colored and then turned black when foo.h was loaded and shown all colored.  The other files were also all black.

I do not understand why there is any "file load order" dependency, or why the first CC mode file seems to "rob" the Lisp mode buffer of its color.  I use the term "rob" with tongue-in-cheek.

The order of things in my .emacs file is:

;; disable all colorization stuff
(global-font-lock-mode -1)

(defun my-load-once-code-hook ()
    "My function to load when a code-mode is initialized the first time"
    (progn
      ;-(setq flb-dbg-val '1)
      (global-font-lock-mode -1)
      ;-(setq c-basic-offset my-tab-width)
      ;-(my-require 'sce)
      ;-(if c-mode-base-map
      ;-    (define-key c-mode-base-map "\C-m" 'c-newline))
      ;-(flb)
    ))

;; set all the load-once stuff for coding
(add-hook 'c-initialization-hook 'my-load-once-code-hook)

;;;;;;;;
I expect that this is more than enough for you all to digest for now.
My obvious next step would be to move on and place this in a 'c-mode-common-hook' but I wonder if I should remove the other two uses first?
Does anybody have any other ideas?

Thanks for taking the time for reading all this.  I will appreciate any help I can get with chasing down the reason for this.

Fran

Re: Problem with CC mode hooks and font-locking

[Eli Zaretskii]

> From: Francis Belliveau <f.belliveau@comcast.net>
> Date: Fri, 30 Nov 2018 16:50:23 -0500
> 
> To be clear, what I am trying to do is eliminate the colors being applied to text in all my files.  My understanding from the documentation is that if I add (global-font-lock-mode -1) to my .emacs file before I load any modes, the effects should be globally disabled.  Therefore, "failure" in this case is when various portions of my text is being shown in different colors.
> 
> I am not sure that it matters, but for clarity, my .emacs setup opens up with the window split vertically so that I can see two buffers simultaneously.
> For the experiments below, I always open the application from my dock so that no file is loaded.  Then I usually open my .emacs file first, in the left half, then the code files in order on the right.  Where I open another file first, it is done in the left side and the others on the right.

Maybe the above does matters, as I'm not on macOS, so maybe there's
something macOS specific involved here; in particular, I have no idea
what does "opening application from my dock" mean.

> 1. Placing this in my .emacs file does not seem to have any effect.  Lisp, C++ and Java modes all show text in lots of colors.

Just doing this one thing, i.e. having a .emacs that says only

  (global-font-lock-mode -1)

disables colors in both Lisp (including *scratch* buffer and any Lisp
file I visit) and C/Java files I visited.

Do you have anything else in your .emacs in addition to that single
line?  If so, perhaps those other things are the culprit.  What
happens if you leave just the above single line in your .emacs, and
then restart Emacs?

> 2. Removed it from main .emacs and placed it in my 'c-initialization-hook' produces the following curious effects:

This is definitely not the right thing to do, so let's disregard what
you get when you do this.  (c-initialization-hook is only relevant to
C-like languages, which is not what you want.  And if you do anything
from that hook, you should only change local values,
i.e. font-lock-mode and not global-font-lock-mode; the latter is a
global mode, so it is inappropriate to turn it on or off from a mode
hook.)

> I do not understand why there is any "file load order" dependency

Because you are changing a global setting from a hook that is called
when the first C-like file is visited.

Re: Problem with CC mode hooks and font-locking

[Francis Belliveau]

Thank you Eli, I found found the problem hidden elsewhere that was toggling things.  Understanding is everything.
By the way "Starting from the dock" is the same a clicking an icon on the desktop.  It just starts the application without any arguments.

I am now at the point of not liking what this is doing because, as Eli said, all coloring has been disabled.  I did like seeing the colors in buffers like the output of "grep".

So I removed the statement from my .emacs file and placed (font-lock-mode -1) in my  'c-initialization-hook' with the intention of only disabling colors in my coding modes.
That seems to disable it for only the first file loaded, but not the others.  As Eli suggested, this does not have any effect on Lisp mode; that buffer is always colored.  My guess here is that placing it there does not step on the defaults for all future mode initializations like I would have expected.

So I moved if to my 'c-mode-common-hook' and that did the trick.

Thanks to all who read through my details.  I hope that it will help others to understand these things.

Fran


> On Dec 1, 2018, at 02:55, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Francis Belliveau <f.belliveau@comcast.net>
>> Date: Fri, 30 Nov 2018 16:50:23 -0500
>> 
>> To be clear, what I am trying to do is eliminate the colors being applied to text in all my files.  My understanding from the documentation is that if I add (global-font-lock-mode -1) to my .emacs file before I load any modes, the effects should be globally disabled.  Therefore, "failure" in this case is when various portions of my text is being shown in different colors.
>> 
>> I am not sure that it matters, but for clarity, my .emacs setup opens up with the window split vertically so that I can see two buffers simultaneously.
>> For the experiments below, I always open the application from my dock so that no file is loaded.  Then I usually open my .emacs file first, in the left half, then the code files in order on the right.  Where I open another file first, it is done in the left side and the others on the right.
> 
> Maybe the above does matters, as I'm not on macOS, so maybe there's
> something macOS specific involved here; in particular, I have no idea
> what does "opening application from my dock" mean.
> 
>> 1. Placing this in my .emacs file does not seem to have any effect.  Lisp, C++ and Java modes all show text in lots of colors.
> 
> Just doing this one thing, i.e. having a .emacs that says only
> 
>  (global-font-lock-mode -1)
> 
> disables colors in both Lisp (including *scratch* buffer and any Lisp
> file I visit) and C/Java files I visited.
> 
> Do you have anything else in your .emacs in addition to that single
> line?  If so, perhaps those other things are the culprit.  What
> happens if you leave just the above single line in your .emacs, and
> then restart Emacs?
> 
>> 2. Removed it from main .emacs and placed it in my 'c-initialization-hook' produces the following curious effects:
> 
> This is definitely not the right thing to do, so let's disregard what
> you get when you do this.  (c-initialization-hook is only relevant to
> C-like languages, which is not what you want.  And if you do anything
> from that hook, you should only change local values,
> i.e. font-lock-mode and not global-font-lock-mode; the latter is a
> global mode, so it is inappropriate to turn it on or off from a mode
> hook.)
> 
>> I do not understand why there is any "file load order" dependency
> 
> Because you are changing a global setting from a hook that is called
> when the first C-like file is visited.
>