announcing generic-edit-special for editing .html.erb
Le Wang
I got tired of partially working solutions to edit javascript/css/ruby
within HTML (mmm, mumamo, etc), and implemented "generic-edit-
special", which uses org-edit-special to edit subsections of .erb
files in the proper major-mode with all the trimmings. This means you
can use js2-mode for inlined javascript now. The down side is I have
to press C-c ' to pop to a new buffer and C-c ' again when I'm done.
But it works far more consistently than the same buffer solutions.
The project is here: https://github.com/lewang/generic-edit-special
My current workflow is to use Steve Purcell's MMM-mode setup to see
the chunks, and use generic-edit-special to do any editing.
Suggestions and bug reports welcome.
--
Le
Aleksandar Simic
Hello Le,
this sounds very interesting.
Can I bother you and ask you to post a snippet on how exactly do you
set up Rinari to work with generic-edit-special? It would speed up the
uptake/adoption of your work.
When you say that you use Steve Purcell's MMM-mode setup, is this what
you are referring to:
https://github.com/purcell/emacs.d/blob/master/init-ruby-mode.el#L34
Thanks for your work and your time,
Aleksandar
Steve Purcell
> I got tired of partially working solutions to edit javascript/css/ruby
> within HTML (mmm, mumamo, etc), and implemented "generic-edit-
> special", which uses org-edit-special to edit subsections of .erb
> files in the proper major-mode with all the trimmings. This means you
> can use js2-mode for inlined javascript now. The down side is I have
> to press C-c ' to pop to a new buffer and C-c ' again when I'm done.
> But it works far more consistently than the same buffer solutions.
>
> The project is here: https://github.com/lewang/generic-edit-special
Hey, that's great -- I look forward to trying it out. Years ago I tried
using a package called multi-mode (IIRC), which used a similar technique
based on indirect buffers, but the package was quite outdated and I
never got it to work properly.
-Steve
Rafael B. Tauil
________________________
Rafael B Tauil
UI Designer / Web developer
http://rafael.tauil.com.br
Le Wang
> Hello Le,
>
> this sounds very interesting.
>
> Can I bother you and ask you to post a snippet on how exactly do you
> set up Rinari to work with generic-edit-special? It would speed up the
> uptake/adoption of your work.
There is a snippet for rinari installation in the header.
> When you say that you use Steve Purcell's MMM-mode setup, is this what
> you are referring to:
>
> https://github.com/purcell/emacs.d/blob/master/init-ruby-mode.el#L34
point.
Le Wang
> Hey, that's great -- I look forward to trying it out. Years ago I tried
> using a package called multi-mode (IIRC), which used a similar technique
> based on indirect buffers, but the package was quite outdated and I
> never got it to work properly.
bugs to be reported.
> -Steve
Lennart Borgman
Maybe someone also want to try the support for .html.erb in nXhtml? Is
there something missing?
Le Wang
nXhtml was the first thing I tried when I started working with Rails.
Unfortunately it didn't stick. I forget what the exact reasons were,
but one that I do remember is the multi-line ruby code sections don't
indent properly, i.e. "<% {many lines} %>".
I do appreciate your work in advancing the state of Emacs, and it
would be awesome if we can get a comprehensive same-buffer solution
for editing templating languages, which is becoming more and more
common.
--
Le
Le Wang
> Hi Le Wang,
>
> Does it have requirements? I'm not using rinari.
>
> It seems to load the mode properly but I see not changes at all. :/
not required, generic-edit-special should work with any html-editing
mode, you just have to bind a key to ges/org-edit-special.
I guess I am kind of assuming you know how org-mode src blocks work.
So you have to place the point in the chunk of javascript/css/ruby you
want to edit, and invoke ges/org-edit-special. A new window will pop
up with the chunk contents in the right major-mode. When you are
editing in the new buffer, press <C-c> ' (apostrophe).
>
> Thanks,
> ________________________
> Rafael B Tauil
Lennart Borgman
How about trying to fix that problem? Is there something in your work
I can borrow? Do you want to integrate it in the indenting functions
in mumamo?
Le Wang
> How about trying to fix that problem? Is there something in your work
> I can borrow? Do you want to integrate it in the indenting functions
> in mumamo?
required cookies to get org-edit-special to work. "org-edit-special"
works really well though. The core of it is just 60 lines of code.
Unfortunately, I also don't have time to get going in nXhtml mode just
now.
Lennart Borgman
I see. Perhaps you can give me an example that I can add to the bug
database in nXhtml and test.
Dmitry Gutov
> I see. Perhaps you can give me an example that I can add to the bug
> database in nXhtml and test.
separately from the whole nXhtml package. I briefly considered trying
to do something about it (like some other people here:
https://bugs.launchpad.net/nxhtml/+bug/760018), but abandoned the idea
as soon as I saw your commit commenting policy (the lack of commit
messages, that is). You may not have lost much in me, but I'm sure
there are other possible contributors who would feel the same way.
The generic-edit-special mode looks nice, but I'll probably never use
it, for two reasons:
1) It doesn't in any way solve the main problem I have left with my
mmm-mode setup - adjustment of html elements indentation according to
the surrounding <% if %>, <% else %>, <% end %>, etc blocks, something
that rhtml-mode does successfully.
2) It breaks the simple edit-save-reload workflow: C-x C-s closes the
special buffer (and leaves the new window open, by the way). This
looks fixable, though.
Lennart Borgman
> On Feb 24, 7:39 pm, Lennart Borgman <lennart.borg...@gmail.com> wrote:
>> I see. Perhaps you can give me an example that I can add to the bug
>> database in nXhtml and test.
>
> The biggest turnoff for me personally is Mumamo being unavailable
> separately from the whole nXhtml package. I briefly considered trying
> to do something about it (like some other people here:
> https://bugs.launchpad.net/nxhtml/+bug/760018), but abandoned the idea
> as soon as I saw your commit commenting policy (the lack of commit
> messages, that is). You may not have lost much in me, but I'm sure
> there are other possible contributors who would feel the same way.
Since I have been doing everything there alone I had not felt the need
for commit messages. It would have been different if others had join.
(However the main work with mumamo has been very complicated so it has
not been easy to join!)
Instead there is a bug database and a lot of test cases.
I do not have time to do very much any more, but if there are people
willing and able to continue it would be nice. But be warned that some
low level changes too Emacs is required to go much further. (After
that the core of mumamo can be extracted to some new library that will
be much more simple to handle.)
> The generic-edit-special mode looks nice, but I'll probably never use
> it, for two reasons:
> 1) It doesn't in any way solve the main problem I have left with my
> mmm-mode setup - adjustment of html elements indentation according to
> the surrounding <% if %>, <% else %>, <% end %>, etc blocks, something
> that rhtml-mode does successfully.
There is a generic handling of indentation too. It is a surprisingly
difficult problem. If you have some simple rules for how to indent in
your special case then why not add it?
> 2) It breaks the simple edit-save-reload workflow: C-x C-s closes the
> special buffer (and leaves the new window open, by the way). This
> looks fixable, though.
I have no idea what you mean here. Can you explain?
Dmitry Gutov
wrote:
> for commit messages. It would have been different if others had join.
> (However the main work with mumamo has been very complicated so it has
> not been easy to join!)
committing policy so much, but here my main worry went like this: even
if I manage to make sense of the codebase, any following commits might
very well undo that achievement. They look complex enough.
Anyway, it's good to know that you're willing to accept some changes.
If solving the ERB indentation problem in mmm-mode turns out to be too
hard, I'll be sure to take another long look at Mumamo.
> Instead there is a bug database and a lot of test cases.
>
> I do not have time to do very much any more, but if there are people
> willing and able to continue it would be nice. But be warned that some
> low level changes too Emacs is required to go much further. (After
> that the core of mumamo can be extracted to some new library that will
> be much more simple to handle.)
of the nXhtml package? Or do you just mean some specific improvements
to the codebase/architecture?
The rest of my previous message is targeted at the package announced
in this thread, generic-edit-special. Sorry for not being more clear.
> > 1) It doesn't in any way solve the main problem I have left with my
> > mmm-mode setup - adjustment of html elements indentation according to
> > the surrounding <% if %>, <% else %>, <% end %>, etc blocks, something
> > that rhtml-mode does successfully.
>
> There is a generic handling of indentation too. It is a surprisingly
> difficult problem. If you have some simple rules for how to indent in
> your special case then why not add it?
> > 2) It breaks the simple edit-save-reload workflow: C-x C-s closes the
> > special buffer (and leaves the new window open, by the way). This
> > looks fixable, though.
>
> I have no idea what you mean here. Can you explain?
an HTML file. I make an edit, save the change, reload the page in the
browser, see if I like the result, repeat. If saving the change closes
the special buffer, I'll have to open it again and again.
Lennart Borgman
>
> Are you saying that Mumamo as it is can't be separated from the rest
> of the nXhtml package? Or do you just mean some specific improvements
> to the codebase/architecture?
Several people has asked and my answer is always the same: Yes, but I
do not have time.
And there is no big reason doing it as long as not the (quite
difficult) changes to Emacs C sources are made. Currently you can not
get a multi major package to work in Emacs. (I.e. mumamo and other
frameworks of course works most of the times, but there are troubles
you can not get around.)
>> There is a generic handling of indentation too. It is a surprisingly
>> difficult problem. If you have some simple rules for how to indent in
>> your special case then why not add it?
>
> Here I meant my own fork of mmm-mode.
Ok, that is your choice. I do not have time to do anything now. I just
pointed you to how you can do it.
>> > 2) It breaks the simple edit-save-reload workflow: C-x C-s closes the
>> > special buffer (and leaves the new window open, by the way). This
>> > looks fixable, though.
>>
>> I have no idea what you mean here. Can you explain?
>
> That's simple. Suppose I'm editing a piece of CSS or JS code inside of
> an HTML file. I make an edit, save the change, reload the page in the
> browser, see if I like the result, repeat. If saving the change closes
> the special buffer, I'll have to open it again and again.
It looks to me you are not using mumamo here, or?
Dmitry Gutov
> On Mon, Feb 27, 2012 at 09:43, Dmitry Gutov <raa...@gmail.com> wrote:
>
> > Are you saying that Mumamo as it is can't be separated from the rest
> > of the nXhtml package? Or do you just mean some specific improvements
> > to the codebase/architecture?
>
> Several people has asked and my answer is always the same: Yes, but I
> do not have time.
> And there is no big reason doing it as long as not the (quite
> difficult) changes to Emacs C sources are made.
clear up package dependencies, lower the required amount of codebase
knowledge if someone wants to contribute a fix or feature, and allow
users to install only the packages they are going to use.
What other reason could there be?
> Currently you can not
> get a multi major package to work in Emacs. (I.e. mumamo and other
> frameworks of course works most of the times, but there are troubles
> you can not get around.)
you link to the discussion(s)?
> >> There is a generic handling of indentation too. It is a surprisingly
> >> difficult problem. If you have some simple rules for how to indent in
> >> your special case then why not add it?
>
> > Here I meant my own fork of mmm-mode.
>
> Ok, that is your choice. I do not have time to do anything now. I just
> pointed you to how you can do it.
bugs.launchpad.net/nxhtml/+bug/579581), this more or less works in
Mumamo already.
> > That's simple. Suppose I'm editing a piece of CSS or JS code inside of
> > an HTML file. I make an edit, save the change, reload the page in the
> > browser, see if I like the result, repeat. If saving the change closes
> > the special buffer, I'll have to open it again and again.
>
> It looks to me you are not using mumamo here, or?
Lennart Borgman
> On Feb 27, 1:04 pm, Lennart Borgman <lennart.borg...@gmail.com> wrote:
>> On Mon, Feb 27, 2012 at 09:43, Dmitry Gutov <raa...@gmail.com> wrote:
>>
>> > Are you saying that Mumamo as it is can't be separated from the rest
>> > of the nXhtml package? Or do you just mean some specific improvements
>> > to the codebase/architecture?
>>
>> Several people has asked and my answer is always the same: Yes, but I
>> do not have time.
>
> Which of the two options are you answering 'yes' to?
Ah, sorry ;-)
It can be separated, but I do not have time to maintain it then. (And
I do not have much time now either, unfortunately.)
>> And there is no big reason doing it as long as not the (quite
>> difficult) changes to Emacs C sources are made.
>
> What do you mean, no big reason? As far as I'm concerned, it would
> clear up package dependencies, lower the required amount of codebase
> knowledge if someone wants to contribute a fix or feature, and allow
> users to install only the packages they are going to use.
> What other reason could there be?
You do not have to know more than mumamo*.el to do something with it.
>> Currently you can not
>> get a multi major package to work in Emacs. (I.e. mumamo and other
>> frameworks of course works most of the times, but there are troubles
>> you can not get around.)
>
> I'm assuming you already brought this issue up with maintainers. Could
> you link to the discussion(s)?
I have had a private discussion with Stefan Monnier about it. The
problem is essentially that the code used by font-lock can see the
whole buffer.
>> >> There is a generic handling of indentation too. It is a surprisingly
>> >> difficult problem. If you have some simple rules for how to indent in
>> >> your special case then why not add it?
>>
>> > Here I meant my own fork of mmm-mode.
>>
>> Ok, that is your choice. I do not have time to do anything now. I just
>> pointed you to how you can do it.
>
> Sure. Judging by the corresponding bug's status (https://
> bugs.launchpad.net/nxhtml/+bug/579581), this more or less works in
> Mumamo already.
I see. If something in nXhtml does not work then try the latest code
from the repository.
Does it actually work for you, or?
Dmitry Gutov
> Ah, sorry ;-)
> It can be separated, but I do not have time to maintain it then. (And
> I do not have much time now either, unfortunately.)
required, or apply patches from time to time, as long as I understand
what they do. Anyway, I don't think that "maintaining it separately"
is the real hard part.
> You do not have to know more than mumamo*.el to do something with it.
separate, then?" is a natural question to ask).
There's still an issue of seeing too many unrelated files and sifting
through unrelated changes in the commit log.
> I have had a private discussion with Stefan Monnier about it. The
> problem is essentially that the code used by font-lock can see the
> whole buffer.
several approaches different modes use in this area, and some are
pretty clever.
> > Sure. Judging by the corresponding bug's status (https://
> > bugs.launchpad.net/nxhtml/+bug/579581), this more or less works in
> > Mumamo already.
So, the feature itself (indentation adjustment) seems to work. The
indentation mechanism itself as a whole -- it has issues. Examples:
1 <a href="#" title="<%= town_description(@lot) %>" class="image">
2 <%= image_tag (@lot.photos.first ?
@lot.photos.first.image.url(:medium)
3 : '/images/no_photo.jpg'), width: 205, height: 155
%>
4 </a>
I move point to line 2, press Tab, nothing happens (good). Move to
line 3, press Tab -> the text on line 2 gets un-indented by 2 spaces
(!!), and the minibuffer says "Do not know how to indent here (both
leaving and entering sub chunks)". No idea why.
1 <td>
2 <%= unless params[:agreement_id]
3 link_to t('.other_sellers'), '#', class:
"show_other_sellers"
4 end %>
5 </td>
Tab on line 2 -> no effect (ok), tab on line 3 -> it gets un-indented
by 4 spaces (very much not-okay). Tab on line 4 -> line 2 (!!!) gets
un-indented 2 spaces. What's up with that?
1 <li>
2 <%= f.label :contact_fee %>:
3 <%= f.number_field :contact_fee, :maxlength => 6 %> рублей.
4 </li>
Tab on line 2 -> no effect; tab on line 3 -> it gets un-indented by 2
spaces.
If you can't reproduce some of those, let me know, I'll try to isolate
them.
All the examples above are handled properly by my current setup - the
unholy marriage of hacked mmm-mode and rhtml-sgml-hacks. If not for
the nature of their relationship, I'd be pretty content, actually.
Lennart Borgman
> On Feb 27, 1:50 pm, Lennart Borgman <lennart.borg...@gmail.com> wrote:
>> Ah, sorry ;-)
>> It can be separated, but I do not have time to maintain it then. (And
>> I do not have much time now either, unfortunately.)
>
> I suppose I could set up a git repo, mirror it to a bazaar one if
> required, or apply patches from time to time, as long as I understand
> what they do. Anyway, I don't think that "maintaining it separately"
> is the real hard part.
It is, partly since I also add some things to the menus.
>> You do not have to know more than mumamo*.el to do something with it.
>
> All right. It's not apparent to a newcomer, though ("Why is it not
> separate, then?" is a natural question to ask).
> There's still an issue of seeing too many unrelated files and sifting
> through unrelated changes in the commit log.
Do whatever you want. It is GPL sw. But be aware of that a big job is
merging and keeping things together (so that the user does not have
that burden unnecessary).
>> I have had a private discussion with Stefan Monnier about it. The
>> problem is essentially that the code used by font-lock can see the
>> whole buffer.
>
> I'd love to read that, with details and stuff. AFAIK, there are
> several approaches different modes use in this area, and some are
> pretty clever.
It is not much to read. I told Stefan that I think a low level change
where you can "hide" parts of a buffer from every funciton in Emacs is
the only way I can see solving the problem if we want to allow old
code to be used in multi major mode buffers. No one of us have sofar
any better suggestion. The problem is perhaps rather how to implement
it and that is difficult - at least it is far above my C fu... ;-)
I have been thinking of taking up this discussion again, but I think
the maintainers have a lot of other things to do at the moment. (In
particulary mergin the lex-branch.)
If you are interested perhaps you want to look at the C code and think about it.
If you can isolate them and make bug reports for nXhtml it would be
great. Now and then I have some time to look into them. And others can
of course also do that.