Nice work! A wishlist...

oneirotekt
2005-07-15
2012-11-13
1 2 > >> (Page 1 of 2)
  • oneirotekt
    oneirotekt
    2005-07-15

    With the addition of "Find in Files" in 3.1, there are now only a few features that would make Notepad++ my perfect editor:

    - An equivalent to UltraEdit's "Reload files previously open on startup" pref.  I typically work with lots of files at once, and being able to close the editor and reopen it later without having to open the same files manually (or with NP++'s "Open All Recent Files" command, which is rather different) would be really great.

    - For XML/HTML syntax highlighting, the ability to color brackets (e.g. <element>) differently from the bracketed contents.  I work with a lot of XML, and it's very helpful to be able to distinguish syntactic elements from text.  I notice that the "=" character for attribute values is already treated in a special way.

    - When word wrap is enabled, the behavior of the HOME and END keys is a little different from most editors.  If I'm on the first or second lines of a multi-line paragraph, hitting END takes my cursor to the end of the last line in the wrapped block.  The expected behavior is that the cursor goes to the end of the (wrapped) line I'm currently on.

    - Likewise, the active line highlighting highlights the entire (wrapped) paragraph, rather than just the line I'm editing.  Expected behavior is that only a single line is highlighted.

    - Per-document word wrap settings.  If I'm working with a plain text document in one tab and a piece of code in another, I want the text to wrap to the window, but the code to remain un-wrapped.  As it is, I have to toggle it on and off each time I switch tabs.  Something similar for Line Number Margins would also be nice.

    - An equivalent to UltraEdit's "Convert Wrap to CR/LFs" feature, so that plaintext documents can easily be converted for viewing on fixed-width displays.

    - The ability to customize the toolbar by dragging and dropping buttons to and from it.  I don't really use macros, so I don't really need their buttons handy.  On the other hand, having a button for Line Number Margin etc would be nice.  I realize this is non-trivial to implement and requires a new UI element, but it would make the program much more powerful to a wider range of users.

    - Just curious, are these features the sort of thing we can expect to be add-able with the new Plugin system?:
      - Spell check
      - File compare

    If these things were fixed, you guys would have an UltraEdit/TextPad/etc killer on your hands.  Notepad++ is already a very good editor.  Keep up the good work!

     
    • Really nice Work, Don, thanks.

      If you would implement a new language ID for the spelling "New", it can translate in every language.

      Yes, this would be great, thanks.

      Hoping in next release....

      Greetings

       
    • Add docked file browser and output window like editplus for me.

       
    • A nice feature would be an analogue of TextPad's workspace feature.  I work with multiple files at once and have to keep switching from file to file.  It'd be nice to be able to launch a workspace and have all the files for that project there ready for me to use.

      I think that would be a lot more powerful than oneirotekt's first suggestion.

       
    • I second the need for a workspace of file browser pane that could be enabled disabled or hidded.  I also operate in space mode, moving around files and across directories sometimes on the fly to review other folks code.

       
    • oneirotekt
      oneirotekt
      2005-08-29

      Looks like the word wrap issues still aren't resolved in 3.2... this really is the only thing that prevents NP++ from being usable as a plain text editor for regular writing.  A real shame, because it's already a very good code editor.

       
      • Don HO
        Don HO
        2005-08-29

        > Looks like the word wrap issues still aren't resolved in 3.2...

        What's the bug? could you give me more detail?

        Don

         
    • Don HO
      Don HO
      2005-08-29

      > "Reload files previously open on startup" pref.

      It's in v3.2 (you can DL v3.2 RC) .

      > When word wrap is enabled, the behavior of the HOME
      > and END keys is a little different from most editors.

      In the text wrap mode, use Alt+HOME and Alt+END to go to respectively begin and end of line.

      > the active line highlighting highlights the entire
      > (wrapped) paragraph, rather than just the line I'm
      > editing. Expected behavior is that only a single line is highlighted.

      I prefer to the default behaviour since it reminds me that the line is wrapped.

      > An equivalent to UltraEdit's "Convert Wrap to CR/LFs" feature

      did you tried the command "split line"?

      > Just curious, are these features the sort of thing
      > we can expect to be add-able with the new Plugin system?: Spell check

      Please see :
      http://sourceforge.net/forum/forum.php?thread_id=1342616&forum_id=482781

      Don

       
    • oneirotekt
      oneirotekt
      2005-08-30

      From the first post in this thread:

      - When word wrap is enabled, the behavior of the HOME and END keys different from most editors. If I'm on the first or second lines of a multi-line paragraph, hitting END takes my cursor to the end of the last line in the wrapped block. The expected behavior is that the cursor goes to the end of the (wrapped) line I'm currently on.

      - Likewise, the active line highlighting highlights the entire (wrapped) paragraph, rather than just the line I'm editing. Expected behavior is that only a single line is highlighted.

      - Per-document word wrap settings. If I'm working with a plain text document in one tab and a piece of code in another, I want the text to wrap to the window, but the code to remain un-wrapped. As it is, I have to toggle it on and off each time I switch tabs. Something similar for Line Number Margins would also be nice.

       
      • Don HO
        Don HO
        2005-09-01

        > The expected behavior is that the cursor goes to the end
        > of the (wrapped) line I'm currently on.

        I have a different point of view about the behaviour of HOME/END key in Wrap mode : The HOME/END key should do the same thing (go to the begin or end of the line) even we are in text wrap mode. OTOH, we can use the Alt-HOME and Alt-END to reach the begin and the end of "visual" (ie. not real) line.

        > the active line highlighting highlights the entire (wrapped)
        > paragraph, rather than just the line I'm editing. Expected
        > behavior is that only a single line is highlighted.

        I don't think it's a good idea.

        > Per-document word wrap settings. If I'm working with a
        > plain text document in one tab and a piece of code in another...

        It's not a bug, but a behaviour issue : the text wrap feature stick on the view but not document.
        To do what you want, you can open  2 view to have different text wrap set, then open the files in different view according to what you want.

        Don

         
        • oneirotekt
          oneirotekt
          2005-09-01

          > The HOME/END key should do the same thing (go to the
          > begin or end of the line) even we are in text wrap mode

          Your definition of "end of the line" is different from that of every other text editor out there, then.  When a line wraps, conceptually (to the user) it goes from being a single long line to being several lines of roughly equal length.  Whether the code still considers it a single line or not is irrelevant, software should work the way the user thinks, not the way the computer prefers to think.

          For regular composing home/end is an extremely common function, something many people use once every few seconds, so shunting the functionality off to a key chord like Alt-Home will make it difficult to use.  Even the key controls on the text fields in Firefox where I'm typing this post use the home/end behavior I describe.

          A typical case in which the current behavior is undesirable is a paragraph comprised of many sentences.  If home/end take you to the beginning or end of the paragraph, the only way to navigate to the middle of it to make a change would be to use the arrow keys, which is slow and more error-prone.

          I cannot imagine changing this behavior will have much impact on the way people use NP++ for editing code.  Code is composed of single lines, and wrap is seldom if ever used.  Word wrap is primarily of use to users composing text, so the behaviors of the feature should reflect that.

          Looking at the core Scintilla editing component, I see wrap works the same way here as well, so I understand it may be non-trivial to change this.  Still, I think any editor worth its salt should be usable for writing prose as well as code, and it would be a shame for a single behavior to render it unusable as such.

           
          • Dave F
            Dave F
            2005-09-02

            >Your definition of "end of the line" is different from
            > that of every other text editor out there, then.
            Note EVERY editor, "vi" also works this way.

            > When a line wraps, conceptually (to the user) it
            > goes from being a single long line to being
            > several lines of roughly equal length.
            > Whether the code still considers it a single line
            > or not is irrelevant, software should work the way
            > the user thinks, not the way the computer
            > prefers to think.

            Not really true.  if you use this as a programmers editor, command lines, argument lines, make files, etc etc it matters very much to the user if they are on the same line or not because otherwise, the code he's writing won't work right.  So your definition of "how the user thinks" is not accurate for programming in general i would argue.  having NP++ behave like code would works well for people who are writing code.

            > I cannot imagine changing this behavior will have
            > much impact on the way people use NP++ for
            > editing code.  Code is composed of single lines,
            > and wrap is seldom if ever used.  Word wrap is
            > primarily of use to users composing text, so the
            > behaviors of the feature should reflect that.
            Could be a valid point, i generally try to avoid word wrap when writing code, i insert hard returns to make it look neater.

            >Still, I think any editor worth its salt should be
            >usable for writing prose as well as code, and it
            > would be a shame for a single behavior to render
            > it unusable as such.
            I don't know that it's really meant to be a text editor, like to write prose, documents and such.  wouldn't you more likely use microsoft word or some equivalent?  i could see you using it to write readmes and help files even for programs though, or even long comments in a program, in which case i actually can see your point.  wow did i just end up agreeing?  :-P

             
            • oneirotekt
              oneirotekt
              2005-09-02

              "it matters very much to the user if they are on the same line or not because otherwise, the code he's writing won't work right."

              This is only true if Word Wrap inserts line breaks, which of course it doesn't in NP++ or any other editor (Notepad, UltraEdit, Firefox text fields, etc)... it just spreads the line across multiple lines on the screen.  It's entirely a readability issue, albeit a huge one... having to keep hitting the horizontal scrollbar when writing a huge paragraph is obviously not workable.  So code in languages where carriage returns are syntactically significant will work just fine.

              "wouldn't you more likely use microsoft word or some equivalent?"

              I'm sure Word is fine for many people, but I find it terrible to work with.  The interface is a bloated mess, it saves stuff out in an icky binary proprietary format, and in general it's way too "heavyweight" for just writing unformatted text.

              As you point out, there are many good uses for a plain text editor, whether you write code, prose or lots of both (as I do).  NP++ is really close to being the ideal one for me.

               
              • Don HO
                Don HO
                2005-12-19

                FYI :
                In the v3.4 which is coming, the HOME & END keys in wrap text mode will act as you expect.

                Don

                 
                • oneirotekt
                  oneirotekt
                  2005-12-29

                  Fantastic, thanks for weighing the issue.

                   
        • Paulius
          Paulius
          2005-09-02

          > I have a different point of view about the behaviour of HOME/END key in Wrap mode :
          > The HOME/END key should do the same thing (go to the begin or end of the line) even
          > we are in text wrap mode. OTOH, we can use the Alt-HOME and Alt-END to reach
          > the begin and the end of "visual" (ie. not real) line.
          I totaly agree with you. But maybe you should make thos shortcuts configurable in shortcut mapper? Then people would stop whining about it... :)

           
          • I agree with theratpm: please make those shortcuts configurable...

            All the editors that I have to use jump to the end of the first 'line' of a wrapped line.
            It would be nice if I could configure the editor that I *like* to use to show the same behaviour...

             
    • A graphical file difference tool would be really nice.

       
      • Paulius
        Paulius
        2005-08-31

        I don't know... I use WinMerge for this...

         
        • TortoiseMerge is a nice choice too.

           
    • My suggestion is to add more keyboard shortcuts. E.g. I'm used to switch tabs with CTRL-PGUP/DWN from Firefox, and I miss this function in Notepad++.

      Great program! This is my favorite editor!

       
    • christina
      christina
      2005-09-04

      Thanks for the hard work! NP++ is a pleasure to use. However, the ONE important feature I'm looking for these days isn't there (yet?): I would like to be able to encode XHTML (and PHP) files as UTF-8 WITHOUT the BOM (byte order mark).  The most recent version, as it is, allows me to VIEW files in this format, but not to encode them that way.  The BOM seems to be mandatory - could it be optional, please?

      There's an excellent multilingual Unicode editor (SC UniPad), which allows me to do precisely that.  But it's plain text only, and so I've resorted to coding on NP++, then copy-pasting files to UniPad and saving them from there as I want them.  All this is very cumbersome, but so far I haven't yet found the perfect tool for me.. 

      The reason I want this is to get rid of the HTML entities in my code, have my XHTML validate, AND not cause any browser trouble.

       
      • Paulius
        Paulius
        2005-09-05

        When you have set 'Format' -> 'Encode in ANSI' and you have selected 'Format' -> 'UTF-8 without BOM' then all your Non-ANSI characters are saved in UTF-8 encoding automatically as you type.
        On the other hand, if you have ANSI document (already writen) and you want to convert it to UTF-8 (without BOM), then wou will need to use some other tool.

        Note: If you know PHP - you can write a script that converts your document from X encoding to UTF-8 without BOM - read about iconv function in PHP manual.

         
        • christina
          christina
          2005-09-05

          Many thanks for your explanations.  However, the W3 validator does not validate my XHTML file if encoded in ANSI but declared as UTF-8 .  If I use Format > Encode UTF-8, then it warns me about the BOM presence.  As to the PHP suggestion, sounds good.  My PHP skills are quite limited, but I can try and play around.  But I'm wondering whether for a dynamic site, the PHP files themselves wouldn't have to be encoded UTF-8?

           
          • Paulius
            Paulius
            2005-09-06

            Your file must be Encoded in UTF-8, but without BOM.
            PHP code is ANSI in general, but all the string constants, variables can be encoded in any possible encoding.

             
1 2 > >> (Page 1 of 2)